DSVLM 视频算法编排

把用户的自然语言视频识别需求，转换成华鲲元启 AI 平台 视频解析 -> 策略中心 -> 算法配置 的可填写配置。

不要把这当成普通 prompt 编写。页面有固定组件，先判断组件，再写条件；没有明确提交授权时只输出方案。

快速入口

| 请求形态 | 行为 | 写入 | | --- | --- | --- | | /dsvlm --config | 弹窗配置 .env，粘贴三段 DevTools cURL | .env | | /dsvlm 场景：xx --loop [N] [--save] | 场景探索或方案评审；默认 2 轮，无新增提前停 | 仅 --save 时写 loop_outputs/ | | 场景：xx --算法名 [--d:补充] | 生成新算法配置表 | 否 | | 场景：xx --算法名 --post [--d:补充] | 生成并提交新算法 | POST /s/theme/data | | /dsvlm --算法名 --update --优化需求 [--d:补充] | 读取现有算法并输出替换方案 | 否 | | /dsvlm --算法名 --update --优化需求 --post [--d:补充] | 读取详情、合并修改并保存原算法 | PUT /s/theme/data |

旧格式 --算法名称：xxx 可兜底；默认优先用 --算法名 短格式。

安全边界

只有原始用户请求里有独立 --post 才能写平台；不要推断用户想提交。
--loop 永远不上传，即使同一句里出现 --post 也只做分析。
只有用户明确要求保存时，才点击 确定 或运行写入脚本。
需求有歧义、模块不确定、英文标签不确定、业务逻辑不确定或是否保存不确定时，先问。
不要把 Authorization、Cookie、access token 写进 README、references、提交记录或回复正文。

请求解析

场景： 后到第一个 -- 前是场景需求。
第一个 -- 后是算法名，例如 --垃圾车识别。
--d:详细描述或补充 是场景或优化需求的补充，不算算法名，也不算提交授权。
推荐把补充放全文最后；需要提交时写 --post --d:补充。兼容 --d:补充 --post，但多行描述容易吞掉末尾 --post，少用。
--loop 可写 --loop N，也可在 --loop 后空一行单独写正整数；轮数不限，但每轮必须有新增价值。
/dsvlm --算法名 --update --优化需求 是更新模式：--update 前的第一个非控制参数是算法名，之后是优化需求；优化需求前多写一个 -- 时只当分隔符。
更新模式只有末尾有独立 --post，或 --post 紧挨 --d: 前面时，才修改保存旧算法。
场景：流浪猫狗测猫狗 是旧两段格式，不是新格式：不得提交，也不要把 测猫狗 当算法名。
场景：流浪猫狗 --测猫狗 只生成方案；只有 场景：流浪猫狗 --测猫狗 --post 才提交。

阅读路由

按任务只读需要的文件：

| 需要 | 读取 | | --- | --- | | 查组件、字段、解析模式、parsingId | references/platform-components.md | | 拆物体、动作、关系、状态 | references/orchestration-patterns.md | | 套真实截图沉淀案例 | references/examples.md | | 查提交、鉴权、.env | references/posting.md | | loop 场景探索和方案评审策略 | references/loop-strategy.md | | 配置 .env | scripts/setup_env_from_curl.py、scripts/configure_env_from_curl.command | | dry-run、post、读取旧算法 | scripts/post_theme_config.py |

读取已有算法并优化时，先运行：

python3 scripts/post_theme_config.py --theme-data-page --theme-label '算法名'
python3 scripts/post_theme_config.py --theme-data-detail '算法id'

页面字段

路径：视频解析 -> 策略中心 -> 算法配置 -> 新增/修改

| 字段 | 说明 | | --- | --- | | 算法 | 算法名称 | | 思维条件 N | 组件和填写内容 | | 解析模式 | 通用、深度、深度串行 | | 预警等级 | 一级、二级、三级预警 | | 启用区域框 | 是否只检测画面指定区域 | | 排序 | 默认自动 | | 添加到门户 | 用户指定或重点展示类算法才开 | | 对接编码 | 用户指定才填 | | 备注 | 简短说明 |

新增算法流程

判断任务类型：对象、属性、动作、状态、关系、缺失、文字，还是复杂场景。
把抽象标签拆成摄像头可见证据，不要直接写 违规、异常、贴广告。
先找可见锚点：人、车、门、手、纸张、刀、棍、头盔、水域、护栏、表情、服饰等；能稳定套框的锚点优先用 目标理解 / 多模态目标理解，目标标签默认写英文。
再写语义复核：手是否拉门、骑手是否未戴头盔、人是否持械/推搡/翻越、车辆是否载人等，用 内容理解 或 深度内容理解 判断动作、关系和状态；细动作或高误报行为可同时用普通正向思维和正向深度思维双校验。
反向排除默认放在主证据之后；高误报场景可前置窄反向排除作为过滤门槛，但只排除明确正常或画面不可判定的情况，例如看不到头、看不清脸、正常交谈、制服工作人员持刀具。
判断逻辑：共同成立用默认 AND；任一独立分支成立才加 逻辑理解 / 或者，并把每个分支完整展开。
场景风险类任务先写真实场景门槛，再写最强、最可见的危险判据；场景门槛不稳时，可用 深度内容理解 / 正向深度思维1 补一条。
选解析模式：简单锚点可用 通用模式，整图事件和复杂语义用 深度解析模式，多锚点局部交互可用 深度串行解析。
输出固定字段：算法、解析模式、预警等级、启用区域框、排序、思维条件、备注。
做生成前自检，再回复用户。

修改已有算法流程

触发格式：

/dsvlm --算法名 --update --优化需求

处理流程：

先只读现有算法列表：python3 scripts/post_theme_config.py --theme-data-page --theme-label '算法名'。
找不到同名算法时，直接说明未找到；不要凭空重建成“已有算法”。
找到后，用算法 id 读详情：python3 scripts/post_theme_config.py --theme-data-detail 'id'。
以详情为原版本，只改用户指出的误报、漏报或新增约束；误报优先追加或改写反向排除，不要整套重写。
没有独立 --post 时只给替换方案；有独立 --post 时，用 --agent-output - --user-request '原始请求' 提交。
update 模式保存时走 PUT /s/theme/data，脚本会查同名算法、读取旧详情、只替换输出表里的字段，不新建同名算法。

示例：/dsvlm --识别火情 --update --灯光总是误测为火情，需要优化，应先读取 识别火情，再补充排除稳定灯光、车灯、反光、暖色照明的条件；不要推倒原有火焰、烟雾等主证据。

Loop 流程

触发 /dsvlm 场景：xx --loop 时，读取 references/loop-strategy.md。

只做场景探索、方案完整性检查和优劣评审，不生成上传 payload，不调用提交脚本。
默认 2 轮；用户可指定更高轮数，但无新增、重复或主要变成不可验证假设时提前停止。
--save 有才保存到 loop_outputs/YYYYMMDD-HHMMSS-场景名-loop.md；没有就只回复。
输出是候选编排分析或方案评审，不是最终可提交算法。

输出格式

给用户配置方案时，固定使用 Markdown 表格：

| 字段 | 内容 |
| --- | --- |
| 算法 | ... |
| 解析模式 | ... |
| 预警等级 | ... |
| 启用区域框 | 开/关 |
| 排序 | 自动 |
| 思维条件1 | [模块] / [组件] / [填写内容] |
| 思维条件2 | ... |
| 备注 | ... |

只有用户要求 --post 并实际提交后，才追加提交结果：

| 提交字段 | 结果 |
| --- | --- |
| 是否 post | 是 |
| 是否成功 | 是/否 |
| 平台状态 | POST_SUCCEEDED_DO_NOT_RETRY / UPDATE_SUCCEEDED_DO_NOT_RETRY / ALREADY_EXISTS_DO_NOT_RETRY / POST_FAILED / ... |
| 平台说明 | ... |

没有要求 --post 时，不输出提交结果表、提交状态或 dry-run 状态。

组件选择

| 场景 | 默认选择 | | --- | --- | | 只找具体物体 | 目标理解 / 多模态目标理解，锚点标签优先英文 | | 物体加状态、属性、关系 | 先用英文 多模态目标理解 锚定，再用 内容理解 或 深度内容理解 | | 动作、状态、关系、一般语义 | 内容理解 | | 身份、年龄、服饰、细节状态、复杂上下文 | 深度内容理解 | | 文字/OCR | 文字理解 / OCR | | 未佩戴、缺失、看不到 | 先找主体和场景，再用目标缺失或反向思维排除不可判定画面 | | 持械、暴力、翻越、拉拽 | 先锚定人和关键物/部位，再用内容或深度内容确认危险动作 | | 细动作、高误报交互 | 目标锚定后，用 正向思维 + 正向深度思维 做双语义复核 | | 任一独立正向候选成立就预警 | 逻辑理解 / 或者，且每个 OR 分支都完整展开 | | 已有模板、截图或平台配置明确给出 | 可用 全结构化理解；不要主动发明 |

组件细节、字段格式和 parsingId 映射见 references/platform-components.md。

核心规则

条件和逻辑

思维条件按从上到下的顺序逐层过滤；上方条件不满足时，不会继续执行下方条件。
不添加任何 逻辑理解 行时，平台会把思维条件默认按 AND 组合。
默认 AND 不是要求所有编排都必须 AND；先判断业务逻辑。
逻辑理解 / 或者 按编程语言里的 || 理解：它分隔完整分支，不是局部连接上一条和下一条。
公共前提和公共排除项不会自动跨 OR 继承；需要在每个分支里重复写。
例如 A && B && (C || F) && !D && !E 要展开为 A && B && C && !D && !E || A && B && F && !D && !E。
同一条语义里的枚举，例如“短裙、低胸上衣、超短裙任一”，优先写在同一个内容理解条件里，不要滥用平台 OR。
OR 常用于“不同目标锚点代表同一风险”的分支枚举，例如 paper in hand 或 card 都代表小广告材料，knife 或 stick 都代表持械攻击，truck carrying people 或 tricycle/bicycle carrying people 都代表违规载人；每个分支都要重新写目标和动作。
不要用 A 或者反向排除B 表达“排除 B”；OR 会把反向条件变成独立分支，逻辑上可能让配置失效。
正向思维1 是原始 prompt 能力，填写内容基本就是最终 prompt。
正向思维2 是调优迭代版，内部已有固定提示词，填写内容会作为变量传入。

目标和区域

目标理解 最后的数字是置信度，不是目标数量。
只有 目标理解 / 通用目标理解 或 目标理解 / 多模态目标理解 检测出的物体才会套框。
内容理解、深度内容理解本身不会给物体套框。
找锚点默认用英文 多模态目标理解，例如 person、hand、car door、helmet、stick；除非已验证平台支持该中文标签。
启用区域框 表示只检测画面中的指定区域，不是使用整个画幅作为检测范围。
远近比、延伸比例只是围绕目标框扩展上下文；不要把它当成业务条件。小物体、手部、脸部、车门等局部动作可用小比例扩展，整图事件不要强依赖延伸比例。
阈值不是固定 50。稳定大目标或误报代价高的具体目标可适当提高；危险事件、低清远景、小目标或漏报代价高的目标可适当降低，再用语义复核兜误报。
有明确目标框、需要定位告警对象时开 启用区域框；纯整图分类、不需要框或目标框不稳定时可关。
添加到门户 不默认开启；只有用户要求、重点展示类算法或需要门户侧直接查看时再开。
直接事件标签稳定时可以单条 多模态目标理解 起步，例如 person in water、Hazardous Chemical、crowd gathering；但涉及行为成因或误报高的任务仍要补语义复核。
排序 用户未指定时填 自动；post 时脚本会读取原有算法列表，并排到当前最大排序之后。

建模偏好

初始配置优先用 2-4 条稳定主证据跑通，不要默认添加反向排除。
条件描述优先“短描述 + 强判据 + 少量排除”：每条只抓一个最关键、摄像头可见的判断点，避免长句堆叠太多细节把语义组件变成硬门槛。
反向思维主要用于调试误报；误报优化按“先补场景门槛，再补朝向/互动关系，最后补误报排除”的顺序。
小物体、细线、局部变化、远景低清结果不要默认作为硬条件。
对“小物体 + 人手动作”任务，不要只识别小物体；至少补一条手部持有、拉拽、张贴、挥舞、递交等动作确认。
对拉车门、手持刀棍、拉横幅、翻越栏杆、未戴头盔等局部交互，不要只停在目标锚点；用普通正向思维确认动作，再用正向深度思维复核细节和关系。
多目标关系不要只写 人 AND 车；必须补关系或动作条件。
判断物体安装、悬挂、粘贴、摆放状态时，先用 目标理解 锚定物体，再用内容理解写位置关系和安装方式。
缺失、未穿戴类任务先找大目标，再用反向思维排除明确合规状态。
未佩戴类任务不要只写 helmet = 0、口罩 = 0；先确认骑手/人员和对应头脸部位可见，再判断未佩戴，并排除看不到头、看不清脸等不可判定画面。
暴力、持械、跌倒、冲撞等风险任务优先写正向危险动作，例如推搡、拉扯、挥拳、踢踹、持刀攻击、持棍攻击、肢体撕扯冲突；反向只排除正常交谈、搭肩、握手、姿态放松、制服工作人员等窄场景。
服饰、表情、奇装异服等细节任务，先用目标标签锚定，再用深度语义确认“与周围明显不符、脸部可见、表情夸张”等可见差异；看不清、遮挡、戴口罩时不要硬判。
车辆载人、翻越栏杆、拉横幅、交通事故等事件类任务，优先用事件目标标签或主体目标锚定，再用内容理解复核事件是否真的发生，不要停在 人 + 车/栏杆/横幅 的并列目标。
存在多个独立危险来源时才用 OR，例如 跌倒冲突、持刀攻击、持棍攻击 三类分别成立；每个分支都要包含本分支的目标和正向行为。
临水、禁区、道路、工地等风险类任务，先限定真实场景，例如河流/水域/工地/道路，再判断人员面部、身体或视线是否朝向危险源，避免正常路过、背对休息、远处背景水面等误报。
临水防溺水不要只写“有人在水域边缘”；优先抓攀爬、跨越、骑跨护栏、手脚搭栏杆、身体探出等人与水域边缘的高危交互动作，再用反向思维排除正常走路、散步、骑行、钓鱼等非危险活动。
OR 分支里的公共场景门槛和反向排除都要重复写。

解析模式

| 模式 | 用法 | | --- | --- | | 通用模式 | 简单锚点、普通物体识别、目标关系容易被串行拆散时使用 | | 深度解析模式 | 整图事件、行为语义、身份服饰、脸部表情、事故状态等需要更强语义判断时使用 | | 深度串行解析 | 多锚点加局部交互、穿戴缺失、手部动作、目标间逐步过滤时使用 |

选择规则：

不要机械默认 通用模式。简单物体可用通用；截图式复杂策略里，深度解析和深度串行解析经常更合适。
需要给物体套框时，必须包含 目标理解 组件。
两个及以上 目标理解 不等于必须用 深度串行解析；如果是整图事件或关系，先考虑 深度解析模式。
人 + 狗、人 + 车 这类整图关系判断，串行解析可能拆散目标关系，不要强行串行。

提交脚本

scripts/post_theme_config.py 默认只预览，只有原始 --user-request 里有独立 --post 才写入。

常用命令：

open scripts/configure_env_from_curl.command
python3 scripts/post_theme_config.py --auto-login
python3 scripts/post_theme_config.py --refresh-auth
python3 scripts/post_theme_config.py --theme-data-page
python3 scripts/post_theme_config.py --theme-data-detail '算法id'
printf '%s\n' "$AGENT_OUTPUT" \
  | python3 scripts/post_theme_config.py \
      --agent-output - \
      --user-request '/dsvlm 场景：识别垃圾车 --垃圾车识别 --post'
printf '%s\n' "$AGENT_OUTPUT" \
  | python3 scripts/post_theme_config.py \
      --agent-output - \
      --user-request '/dsvlm --识别火情 --update --灯光误报 --post'
python3 scripts/post_theme_config.py --config payload.json --post

写入规则：

--theme-data-page 和真实 post 会优先复用现有 token，探活失败才刷新一次；通常不需要手动 --refresh-auth。
默认 post 必须使用 --agent-output - 从 stdin 读取刚生成的最终表格；不要先写 output.txt。
只有用户特别要求调试、复现或留档时，才使用 --agent-output output.txt。
--agent-output 以原始 --user-request 为准；模型自己乱加 CLI --post 不会提交。
用户请求里的 --算法名 或 --算法名称：... 优先覆盖输出里的 算法。
默认查重同名 themeLabel；已存在则返回 ALREADY_EXISTS_DO_NOT_RETRY 并停止。
update 模式不会走同名跳过；有 --post 时读取旧详情，合并修改后用 PUT /s/theme/data 保存。
success: true 且 status 为 POST_SUCCEEDED_DO_NOT_RETRY、UPDATE_SUCCEEDED_DO_NOT_RETRY 或 ALREADY_EXISTS_DO_NOT_RETRY，都表示任务完成。
鉴权、.env、动态 Authorization 见 references/posting.md。

生成前自检

条件是不是摄像头可见证据，而不是抽象标签。
组件是不是平台已有组件，没有发明新选项。
锚点目标是否优先用了英文 多模态目标理解，而不是中文抽象词。
更新模式是否确实读取到同名现有算法，而不是只按算法名猜配置。
更新模式是否只改和新需求直接相关的最少条件。
多条件默认 AND 是否符合业务；任一独立分支成立才加 逻辑理解 / 或者。
是否把 逻辑理解 / 或者 两侧分支完整展开；公共前提、公共排除项是否已在每个分支重复。
是否错误地把 逻辑理解 / 或者 和反向思维混用成独立预警分支。
场景风险类任务是否先限定真实场景，并判断人员与危险源的朝向或互动关系。
条件描述是否足够短，是否只保留最强可见判据；有没有把多个细节堆进一条条件导致漏报。
是否已经区分“可见锚点、语义复核、反向排除”，而不是只堆目标标签。
细动作或高误报交互是否用了普通正向思维和正向深度思维双校验。
未佩戴、看不到、表情、脸部类任务是否确认关键部位可见；不可判定画面是否被窄排除。
持械、暴力、事故、翻越、拉横幅、载人等事件类任务是否补了真实动作或事件复核。
解析模式是否匹配任务：简单物体、整图事件、多锚点局部交互不要混用。
阈值、远近比、启用区域框、添加到门户是否有业务理由，还是机械照抄。
临水防溺水是否从“靠近水域”收紧到“攀爬、跨越、骑跨、探身”等高危动作，并排除正常经过、散步、骑行、钓鱼。
目标理解 数字是不是置信度，不是目标数量。
原始用户请求没有独立 --post 时，是否没有触发提交。

硬约束

不要编造用户未提供、页面未见过的模块选项。
不要把置信度当成目标数量。
不要把抽象行为直接当作最终条件。
不要默认添加反向排除；先根据误报类型追加。
不要机械默认通用、深度解析或深度串行解析；按任务结构选择。
不要在用户未明确授权时保存配置。