基线与目标线说明 — h3-video-prompt

一、为什么没有可抓取的行业平均分

h3-video-prompt 是"针对 MiniMax H3 单一模型写结构化视频提示词"的方法论技能，不存在可爬取、 可统计的"行业平均分"这种东西——H3 官方 GitHub 仓库和公开攻略（../hunt/sources.json）都是 规范文档和写法示例，不是打过分的语料库；且飞书两篇原定标杆文档正文完全不可达（见 ../hunt/feishu_access_status.md，三次独立尝试全部因登录墙失败），本来最有希望提供"标杆水平 分数"的信源实际上一条数据都没拿到。参照 system/agents/sdd-planning/train/digest/ industry_avg_score.md 的先例，本文档同样不编造行业平均分，改为给两条可复现的基准线。

二、与 sdd-planning 先例的关键差异：本次没有真实历史执行记录

sdd-planning 的基线来自 data/companies/e2e-demo/ 里真实跑过的 attempt-0/attempt-1， 是这个 agent 已经实际执行、被下游打回过的历史事实。h3-video-prompt 是刚由 agent-creator 创建的全新 agent，还没有任何真实执行记录——config.json 显示 status: training，尚未接过 一条真实用户请求。因此本文档的 baseline/target 都是构造性反事实样本（counterfactual）， 不是真实历史执行记录，以下每处都会明确标注"构造"字样，不冒充真实案例，符合公司训练教训 （评测样本优先用真实记录，没有真实先例时必须明确标注为构造性设计）。

三、worked example：同一场景的 baseline 与 target

选用 test_scenarios.json 的 TS-05（Ref2VA，产品+代言人一致性广告短片）作为 worked example——这是 knowhow §8 校准表指出的最大结构性缺口（Ref2VA 完全缺失）会被暴露得最明显的 场景类型。

创意描述：帮我做条产品发布短视频：15秒，参考素材是一张我们智能手表的产品图和一段之前 拍好的代言人口播视频片段，想要代言人抬手展示手表的镜头，手表外观和之前口播视频里的人物形象 都要保持一致，风格科技感但不要浮夸。

3.1 基线（baseline）：仅用当前 .claude/skills/main_skill/SKILL.md 骨架产出

当前 SKILL.md 没有 T2VA/I2VA/FL2VA/L2VA/Ref2VA 命名体系，Step 3"进阶模板"只有"参考图关键帧 锚定"的文字性建议（"描述里要明确哪些细节必须与参考图保持一致"），没有 subject_definitions/ summary/retention_analysis 结构化字段。按当前骨架字面执行，构造出的产出大致是：

integrated_multimodal_description: [Shot 1] 中近景，缓慢推进。代言人（参考视频中的形象）微笑着抬起右手，手腕上的智能手表（参考图中的 外观）随手臂动作转向镜头，表盘反射出冷蓝色的光。 overall_soundscape: 轻微的环境底噪，无明显环境音。 non_diegetic_music: 简洁的电子合成器音效，节奏克制，带一点科技感的音色。

这段产出把两个参考素材（产品图、口播视频片段）都揉进了 integrated_multimodal_description 的一句话描述里，没有分别声明各自职责，也没有点名"表盘图案/logo角度""人物五官发型"这类必须 跨镜头保持一致的具体特征——是 knowhow §6"参考素材未声明职责就堆叠使用"的典型情形。

逐维度打分（按 benchmark_v1.md 标准）：

维度	分数	理由
D1	1	完全没有模式意识，subject_definitions/summary/retention_analysis 三字段一个都没出现
D2	3	基础三字段都用了，但内容笼统，套用到任何"参考素材"场景都成立，不是针对 Ref2VA 定制的结构
D3	4	声音都写了且具体，扣 1 分：没有对"是否需要额外音效卡点"给出显式声明
D4	4	光影具体（"冷蓝色的光"有位置+效果），扣 1 分：'科技感的音色'仍带一点质量词残留
D5	4	单一主导运镜（推进），无矛盾指令，扣 1 分：未标注幅度/速度修饰词
D6	2	命中"参考素材未声明职责就堆叠使用"（核心路径），是本场景最典型的缺陷

加权和 = 1/5×25 + 3/5×15 + 4/5×15 + 4/5×15 + 4/5×15 + 2/5×15
       = 5 + 9 + 12 + 12 + 12 + 6
       = 56

触发封顶：D1 = 1（≤1）→ 总分上限 40。

最终得分 = min(56, 40) = 40

40 分，落在"不合格"档——和 knowhow §8 的结论一致：现有骨架在光影/术语/单一运镜这些 已验证准确的维度上表现尚可（D3-D5 都接近满分），但因为完全没有 Ref2VA 模式意识，会在 D1 封顶规则下被判定为结构性不合格，不能靠其余维度的高分"混过"及格线。这正是本 benchmark 把 D1 设为最高权重 + 封顶维度的设计意图在真实样本形态上的验证。

3.2 目标线（target）：补齐 knowhow §8 缺口后应产出的结构

按 knowhow §1.1 的官方 Ref2VA 六字段结构改写：

subject_definitions: - 主体1（产品）：银色金属表壳智能手表，表盘为深色圆形，右下角有品牌 logo 蚀刻 - 主体2（人物）：代言人，短发，参考视频中的着装与面部特征 summary: 代言人抬手展示手表的15秒产品发布镜头，科技感克制风格。 retention_analysis: 手表表盘图案与 logo 蚀刻角度须与产品参考图保持一致；代言人面部 特征与发型须与口播视频参考保持一致；两者在抬手动作中的相对位置需符合真实佩戴关系。 detailed_description: [Shot 1] 中近景，缓慢推进。（同步细节：手表随抬手动作转向镜头）... overall_soundscape: N/A（室内近景，无明显环境音） non_diegetic_music: 简洁的电子合成器持续音，节奏克制。

逐维度打分：D1=5、D2=5、D3=5、D4=5、D5=5、D6=5（六字段齐全具体、职责分别声明、声音 显式标注、无矛盾运镜、无新增错误命中）。

加权和 = 25 + 15 + 15 + 15 + 15 + 15 = 100

100 分，落在"优秀"档，未触发封顶（D1=5）。

四、baseline / target / 及格线取值

名称	分数	依据
baseline（当前骨架，构造性）	40	3.1 worked example 打分结果，反映 knowhow §8 指出的 D1 结构性缺口
target（目标线）	95	见下方说明，非直接取 worked example 的 100 分
passing_score（硬性部署线）	90	本任务书（org-innovator T-mt89buyo）直接指定，见下方核实结论

target 为什么取 95 而不是 worked example 算出的 100：单个构造样本（无论是 3.1 的 40 分 还是 3.2 的 100 分）都不该直接定阈值——3.2 的 target 输出是"理想情况下补齐全部缺口"的 构造样本，真实 Evolver 训练产出会有执行波动（比如某个次要字段偶尔简略、幅度修饰词偶尔漏标）， 不该要求每次都精确复现满分。参照 sdd-planning 先例（用"优秀"档下限而非满分样本本身定 目标线），本 benchmark 3.3 节"优秀"档下限就是 95，取这个值作为 target，比 worked example 的 100 更贴近可持续达到的训练目标，同时仍留出 90-94 的"合格但需微调"缓冲区间。

90 分硬性部署线的可达性核实：本任务书原文直接指定"90 分仍作为部署硬性及格线"，不是本次 推导得出的数字。核实结论：这条线是可达的——3.2 的构造 target 样本证明，只要把 knowhow §1.1 的 Ref2VA 六字段结构、§5 的声音 N/A 显式声明、§6 的六类新增错误规避这三处缺口按 knowhow 原文补齐，D1-D6 六个维度都能达到 5 分档，总分 100，远高于 90 分线；真正的风险不在 "90 分定得过高够不到"，而在 D1 封顶规则——如果 Evolver 训练时遗漏了 Ref2VA 三字段中任意 一项，D1 会跌到 2-3 分区间，触发 40-60 分的硬顶，无论其余维度多接近满分都拿不到 90 分。 所以 90 分线是可达的，但必须以 D1 六字段结构完整为前提，这也是 baseline_target.md 和 benchmark_v1.md 反复强调 D1 权重与封顶规则的原因——不是任意分配的权重，而是这条硬性 及格线实际可达与否的关键路径。

五、样本量说明：为什么只有 1 个 worked example 而不是更多真实样本

h3-video-prompt 没有真实执行记录（见二），test_scenarios.json 的 8 条场景本身也还没有 被真实执行产出过。本文档选取 TS-05 一条场景做完整的 baseline/target 双向 worked example， 是因为它是 knowhow §8 唯一标为"❌完全缺失"的缺口在具体产出形态上暴露得最典型的场景，用于 验证 benchmark 的封顶规则设计是否合理（3.1 节的自检逻辑），而不是为了覆盖全部 8 条场景的 分数——后续 Evolver 训练产出真实提示词后，应该用 test_scenarios.json 全部 8 条场景重新 跑一轮真实评分，替换/补充本文档目前的构造性 worked example，尤其是 TS-07/TS-08 两条边界 场景（信息不足反问、矛盾指令纠偏）目前完全没有构造样本，需要真实产出之后才能验证。