knowhow_v3.md 34.4 KB

Edit Raw Blame History


H3 视频提示词专家 — Hunt 阶段调研报告 v3
任务：T-mtb58zsc｜调研人：innovator-hunt (Hunter)｜抓取时间：2026-08-27（UTC 06:51）
性质：纯增量报告。v1（hunt/knowhow_v1.md，2026-08-25）已核实的结论一律不重写，只标注引用位置；
本文只写本轮新增的事实与新增的缺口。
配套逐字信源清单：hunt/sources_v3.json（URL + 行号级引文 + 抓取时间）。


0. 结论速览（8 条）

官方原文里根本没有 references 数组这个词。参考素材进模型的通道叫 conditions[]，
每条是 {type, uri, role[, frame_index]}，url 写在结构化字段 uri 里，不写进提示词正文
（官方脚本逐字证据见 §2）。SKILL v0.3.0 §0.6 第 6 步里那个 {"prompt","references"} 形状
是调用方约定，不是官方 schema——这一点此前没有分开说，容易误读成「references 是官方字段」。
官方全文没有 object N / background N 字面标签。四个参考标签只有
<Subject N> / <Picture N> / <Video N> / <Audio N>（ref-en.txt L28-L34 表格，§3.1 引文）。
对 master 要求的两种读法如实分列在 §3，不替上级二选一。
§0.6 的「立绘只用来定义人物、不另起 Picture 条目」有官方逐字支撑，属通用默认而非 conv-mtabpqx9
输入特定：ref-en.txt L68 "If an image is used only to define a character, scene, costume, or
style, do not create a standalone picture entry. Instead, cite the image source inside the
corresponding <Subject N> definition."（§4.1）。它与 master 新要求「所有参考图保留 url 并打标签」
不在同一层、并不冲突：资产层保留 url ≠ 正文层加 Picture 条目，判据在 §4.3。
新发现一个 v0.3.0 与官方写法的真实偏差（可修的缺口）：官方范例用资产序号内联引用非锚点图
（<Subject 2> is the fluffy white Samoyed in <Picture 2>, <Picture 3>, and <Picture 4>，
ref-en.txt L313），而 SKILL §0.6 第 3 步让正文里写 "the NPC portrait" 这种文字指代。
按 ref-en.txt L37 的规则，来源应写成 <Picture 2> 这类标签引用（§4.4）。
六大盲区的定位结果：双说话人编号稳定、音频 Audio N 锚定、画外音 off-screen voiceover 三条
有官方逐字出处；人物出场过程、道具跨镜头跳变两条官方无逐字条款（各有最接近的一条相邻规则，
已如实列出）；JSON 序列化通道可解析性无任何官方原文，属内部合理推演（§5）。
⚠️ 新发现一处官方原文内部的规则张力（比盲区更值钱）：base-en.txt L129 要求对白
"Preserve every original word and punctuation mark verbatim"；而 ref-en.txt L274 针对另一类
台词要求 "Standardize punctuation to the basic written marks … End complete statements,
questions, and exclamations with ., ?, or ! respectively before </d>"，还要删掉波浪号/
emoji/装饰标点。两者作用域不同但表面互斥（§5.6），直接关系 TS-11 的判分口径，必须由
Digester 拍板成作用域条款。
原故事情节保留 / 台词原语言保真两条的官方定位也补齐了（§5.5）：原语言保真是三条独立原文叠加；
「原故事情节保留」同样没有逐字条款，最接近的是 T2VA Case 1 的
"details that remain consistent with the user's intent"（base-en.txt L172）。
本轮网络受限记录：MiniMax 开放平台文档（platform.minimax.io）不可达（WebFetch 被拒 + curl 超时），
README L58 只确认了入口链接存在，开放平台侧的请求 schema 未核实（§7）。已拿到的 9 个文件
字节数与 GitHub API 树逐一核对一致。


1. 本轮实际抓到的官方原文清单（全部 raw.githubusercontent.com 直读全文）


#
文件
bytes
sha256 前16位
说明


1
.claude/skills/h3-prompt-writing/SKILL.md
2177
a48f9db1231cebe6
官方技能总说明（Output Rules 在这里）


2
.claude/skills/h3-prompt-writing/references/base-en.txt
15773
2cfebc096a6e0837
基础模式规范（223 行全文到手）


3
.claude/skills/h3-prompt-writing/references/ref-en.txt
23553
1e574f356716ad55
Ref2VA 规范（342 行全文到手）


4
.claude/skills/h3-prompt-writing/agents/openai.yaml
240
7770c9d784b7251a
仅 UI 元数据


5
README.md
40135
7964f3044d3c7efa
含模型表 / conditions[].uri / API 入口


6
README.zh-CN.md
36894
5c109694dae87cf0
中文版


7
Ref2VA/processor/chat_template.json
5499
5c72a170d2a4a1a3
图像→Picture N 自动编号机制的机制性证据


8
scripts/readme/reproducible-768p-ref2va-request.sh
5047
73ea0e5cc94440b2
官方 Ref2VA 请求示例（video+audio）


9
scripts/readme/reproducible-768p-fl2va-request.sh
5718
82d1c06897da37e5
官方 FL2VA 请求示例（image+keyframe）


上轮 v1 的未决项之一就是这两份 reference txt 的逐字全文没拿到（v1 §9.1）；本轮已闭环：
三份核心文件全文直读、行号级引用全部落到 sources_v3.json。.agents/skills/... 与
.claude/skills/... 在仓库里是两份同字节副本（tree.json 核对：2177/15773/23553 完全一致），任取其一即可。


另外抓取 api.github.com/repos/MiniMax-AI/MiniMax-H3/git/trees/main?recursive=1 用于全量路径清点，
确认仓库内与提示词写作相关的就这九处（其余全是模型权重/配置目录 FL2VA/Ref2VA 等）。


2. 【需求 (1)】Ref2VA 下线上 URL 的传入机制 —— 官方事实
2.1 先纠正一个提问预设
任务问的是「官方示例里 references 有没有 url 字段」。官方体系里不存在叫 references 的数组：


提示词正文是一段带六个小节（或三个字段）的纯文本，里面只出现 <Subject N> 等标签，不含 url；
参考素材是通过请求体的另一个顶层字段 conditions[] 传进去的，素材地址放在每条的 uri 键上。


「references 数组」这个说法来自我们自己的交付形态约定（SKILL §0.6 第 6 步 / benchmark_v2），
它是调用方 schema。不是错误，但从这轮起要分清楚两层：资产层（conditions/我们的 references 数组，放 url）
和 正文层（prompt 文本，放标签）。这个区分正是回答需求 (3) 冲突问题的关键杠杆（§4.3）。
2.2 官方请求体形状（逐字）
scripts/readme/reproducible-768p-ref2va-request.sh L11-L32（全文见 sources_v3.json s08）：
{
  "task": "ref2va",
  "prompt": "subject_definitions:\n<Subject 1> is the young man with short wavy blonde hair, ...",
  "conditions": [
    { "type": "video", "uri": "https://cdn.hailuoai.com/prod/hailuo_demo/testsets/...mp4",
      "role": "reference" },
    { "type": "audio", "uri": "https://cdn.hailuoai.com/prod/hailuo_demo/testsets/...mp3",
      "role": "reference" }
  ],
  "target": { "short_edge": 768, "aspect_ratio": "auto", "duration_seconds": 5 },
  "seed": 0
}


要点：


线上 https URL 官方直接用（cdn.hailuoai.com 公网 CDN 地址原样放 uri）。所以 master 说
「H3 模式允许使用线上 url 作为参考图地址」——属实，且不需要把图下载到本地再传。
已观测到的 role 取值："reference"（ref2va 的 video/audio）、"keyframe"（fl2va 的 image，
带 "frame_index": 0，见 fl2va_768p.sh）。README L270-288 还示范了 file:///data/minimax-h3/my-keyframe.png
这种本地路径用法。
注意：官方公开脚本里没有一个纯「图片角色 reference」的 Ref2VA 图片用例（ref2va 示例用的是视频+音频，
图片 keyframe 用例挂在 FL2VA 下）。图片-only 的 Ref2VA 请求里 role 具体能填哪些枚举值
（reference / keyframe / 其他？）官方原文未在本轮抓到的文件中给出 → 见 §7 存疑项。

2.3 README 对 uri 机制的逐字说明
README.md L272："The reproducible scripts above reference conditions[].uri values hosted on a public CDN
so they work out of the box, but uri is not limited to http(s)://."
L285："The path is resolved by the SGLang server process, not by the machine running curl, so it must
point to a file the server can actually see."
2.4 编号机制：为什么 Picture N 天然等于素材顺序号
Ref2VA/processor/chat_template.json（模型侧模板，逐字）：
{%- if content.type == 'image' or 'image' in content or 'image_url' in content %}
    {%- set image_count.value = image_count.value + 1 %}
    {%- if add_vision_id %}Picture {{ image_count.value }}: {% endif -%}
    <|vision_start|><|image_pad|><|vision_end|>
{%- elif content.type == 'video' or 'video' in content %}
    {%- set video_count.value = video_count.value + 1 %}
    {%- if add_vision_id %}Video {{ video_count.value }}: {% endif -%}


推论（这一条是从实现层面推演的，标注为机制性证据而非写作规范原文）：
图片按它们在请求条件序列里的先后被自动编号成 Picture 1:、Picture 2:、Picture 3:……
编号跟「这张图是不是构图锚点」无关。 所以 even if 我们不给立绘单独的 Picture 定义条目，
立绘在模型输入流里仍然占着 Picture 序号。这正是 §4.3 判定「保 url 不冲突」和 §4.4 缺口的物理基础。
2.5 素材上限与混合输入
README.md L85（H3-Base-Ref2VA 行）："Supports multi-modal reference inputs: Images: ≤ 9 images;
Videos: ≤ 3 clips; each clip must be 2–15 seconds long; total duration ≤ 15 seconds; Audio: ≤ 3 clips;
each clip must be 2–15 seconds long; Mixed inputs: Maximum number of files across all input types is 12."

→ 生产菜单如果超过 12 个文件总量会被拒；v1 §1.1 只写了「最多9图+3视频+3音频」，
「全部类型合计 ≤ 12」这条是本轮新补齐的上限。


3. 【需求 (2)】object N / background N 字面标签 —— 两种读法分列（本节独立成节）
3.1 官方原文字面事实（先钉死，避免各自脑补）

官方四个参考标签全表（ref-en.txt L26-L34）：


"Full-reference rewrites use four types of labels to identify the source and role of referenced content:
| <Subject N> | Visible content abstracted from reference assets that can be reused or modified in the target video |
| <Picture N> | A reference image used as a concrete target frame or shot-planning anchor |
| <Video N> | A reference video that provides an editing source, continuation starting point, or whole-video temporal structure |
| <Audio N> | An audio signal that is copied or referenced |"


全部 9 个官方文件的 grep -i "object\|background" 结果：object/background 只出现在
「People, animals, or objects」「Scenes, backgrounds, or environments」（ref-en.txt L43/L44，
即 Subject 可涵盖物与环境）和「Describes background music…」这些普通词义里，
不存在任何形如 object 1、background 1 的标签语法。语言标签也只有
<Picture N>（图片）/<Video N>/<Audio N>，没有给「背景图」「道具图」单设类别。
反向约束（读法 A 的主要风险依据）—— SKILL_official.md L14：


"Preserve the exact field names, section order, labels, and timing notation from the selected guide."


「背景图属于哪类内容」官方也有正面答案：背景/场景是可以作为 <Subject N> 定义的可见内容
（ref-en.txt L44 + L313 官方范例把咖啡店环境定义成 <Subject 1> is the coffee-shop environment in <Picture 1>, featuring an exposed brick wall, ...）。

3.2 读法 A —— 按用户字面要求，在产出里加 object 1 / object 2 / background 1 / picture 1 编号标签
主张：最终产出的某个层（例如我们自己的 references 数组每个元素加一个 label 字段，
或在 prompt 正文给每张参考图写一行 object 1: 白衣古装女子，url 原样附上），用来满足
master 说的「给每个参考图打 object 1 / object 2 / background 1 / picture 1 这类标签来满足 H3 生成需求」。


对 SKILL 条文的影响：


§0.6 第 1 步（构建 references）需增补「每条素材必须带上 master 给定的类别编号标签」；
§0.6 第 2 步与自查清单第 5 条「立绘是否仅作为人物来源绑定，没有另起图片条目」要改写——
读法 A 允许甚至要求给立绘挂显式标签，<Picture N> 独占锚点的表述要放宽到「picture/object 双轨」；
需要新增一节说明 object/background/picture 三套前缀各自的语义边界（谁算 object、什么才算 background、
多个 NPC 时怎么编号），这套语义目前没有任何官方或第三方文本背书，只能靠我们自己定义并在
交付说明里声明是自定义扩展。

对评分判据的影响：


D7/D9 的判据若维持「官方标签一致性」，读法 A 会变成系统性扣分项；需要先改 benchmark 再改行为，
否则训练目标自相矛盾；
若走读法 A，就必须同时新增「标签不得替换官方 <Subject/Picture/Video/Audio N>」的保护条款，
避免产出里出现两套互相打架的编号。

主要风险：与 §3.1 第 3 条官方命令 "Preserve the exact field names, section order, labels…" 直接相抵；
相当于在官方正文之外发明一套平级标签词汇。

3.3 读法 B —— 用户说的这类标签对应官方既有 <Picture N> / <Subject N> 体系，url 进 references/conditions
主张：master 口中的「object 1 / background 1 / picture 1 标签」翻译到官方词汇上是：


生产菜单里的图
官方正文层的落位
url 放哪


scene（昏暗旧屋，构图锚点）
<Picture 1> 独立条目；subject_definitions 里同时把环境作为 <Subject N> 定义来源
references[0].url = 原 OSS 地址


npc 立绘（白衣古装女子）
不给独立 Picture 定义条目；在 <Subject N> 的定义句里以来源形式内联引用其序号（§4.4 的官方范例写法）
references[1].url = 原 OSS 地址


player 立绘（深色长袍捕快）
同上
references[2].url = 原 OSS 地址


即「给每个参考图打标签」的义务由两层共同满足：正文中每张图都能通过 <Subject/Picture N> 找到归属，
资产层 url 原样保留、不下载不改链。summary 任务类型此时通常是
[keyframe completion + reference generation]（scene 当首帧锚点、两张立绘只当生成指导时）。


对 SKILL 条文的影响：


§0.6 第 3 步要改成官方式来源引用（目前写的 "as established in the NPC portrait" 应改为
in <Picture 2> 这种带序号的引用，依据 ref-en.txt L37/L313，见 §4.4）；
自查清单第 3 条要补一句「凡以 assets 身份进入 references 的图片，要么有独立 <Picture N> 定义条目、
要么在某条 <Subject N> 定义里被序号引用，不允许成为正文里完全无人认领的幽灵编号」（这句是我们
推演出来的收口规则，非官方原文，落地时要标注）；
新增一条硬规则：「产出中禁止出现官方四标签以外的编号词法」，把 master 的口语化需求明确映射过去。

对评分判据的影响：


D7/D9 无需改动方向，只需在 D7 判据里写清「资产层 url 必须保留」与「正文层不得发明新标签」两个点，
都属于现有「官方格式忠实度」维度的细化，不推翻现有基准。

局限（如实写）：master 如果坚持要在交付 JSON 里看到字面的 object 1 字符串，读法 B 单独满足不了，
需要与读法 A 混合（见下）。

3.4 两读法对照与决策要点（不替上级选）


维度
读法 A（字面新标签）
读法 B（映射既有官方标签）


是否满足「每张图都有编号标签」的字面需求
✅ 直接满足
⚠️ 以 <Picture/Subject N> 形式满足，字面不是 object/background


是否符合官方 "preserve exact labels" 命令
❌ 违反，属自定义扩展
✅ 完全一致


url 原样保留
两读法相同：都在资产层保留原 OSS url
同左


需要动 benchmark 吗
要（D7/D9 判据 + 新标签语义表）
不要（只做判据细化）


需要动 SKILL 吗
要（新增标签语义一节 + 放宽 §0.6/清单第 5 条）
要（§0.6 第 3 步改官方引用写法 + 幽灵编号收口）


与生产样例（painted_skin_room）兼容性
兼容，但要额外解释两套标签并存
直接可用（§6 给出逐图落位）


主要不确定性
新词汇零外部背书，评分与生成效果均未知
master 语义是否真的等同于此映射，需上级确认


混合形态（既保留读法 B 的官方正文写法，又在我们自己的交付说明/manifest 里附一张
「master 标签 ↔ 官方标签 ↔ url」三方对照表）可以同时给出两边证据，代价是要在 SKILL 里声明
「对照表只出现在中文交付说明里，不进入喂给模型的英文正文」。是否接受这个折中由上级拍板。


4. 【需求 (3)】压测 §0.6「立绘只用来定义人物、不另起 Picture 条目」
4.1 它是不是 conv-mtabpqx9 特有的输入规则？—— 不是，有官方逐字背书，是通用默认
ref-en.txt L62：


"Use a standalone <Picture N> when the reference image itself serves as a shot's first frame,
keyframe, last frame, edited keyframe, or composition anchor"


ref-en.txt L68：


"If an image is used only to define a character, scene, costume, or style, do not create a standalone
picture entry. Instead, cite the image source inside the corresponding <Subject N> definition."


ref-en.txt L37：


"If <Picture N> or <Video N> only identifies the source of another referenced item and will not be
analyzed or used separately later, cite it inside that item's definition without adding a separate line."


所以 v0.3.0 把它写进 §0.6 属于把官方通用规则实例化到那份输入，方向正确；但表述上把它归因于
「这份输入自带绑定规则」会低估它的普适性。建议 Evolver 把 §0.6 该处的措辞升级为
「这是官方通用规则（引 ref-en L62/L68），该输入只是又重复强调了一遍」。
4.2 该输入的「references 顺序 scene → npc → player」与官方的关系
官方没有规定素材排列语义，只规定了：素材顺序决定 Picture 编号（chat_template 证据）、
正文标签含义全程一致（SKILL_official.md L27 "Reference labels stay consistent across all sections."）。
所以「按菜单 id 顺序进 conditions」这个约定是安全的，且是唯一稳妥选择（重排会让 Picture 编号错位）。
4.3 master 新要求（保留所有参考图及原 url 并打标签）与这条规则有没有冲突？—— 没有，前提是分层
判定句：冲突只在「把 url 或标签塞进错误的层」时发生。


资产层：三张图全部进 references[]/conditions，url 原样保留 —— 与「立绘不做 Picture 条目」毫无冲突，
因为那条规则只管辖正文层是否有独立 <Picture N> 定义条目，不管资产怎么传（官方自己也是这么做的：
正文的 <Audio 1> 定义引用了 <Video 1> 的音轨，但 video/audio 资产照样各占一个 condition 条目，
见 ref2va_768p.sh）。
正文层：只在一种情况下真正冲突 —— 要求把立绘写成新的独立 <Picture N> 定义条目，或写出
object N/background N 这类官方外标签（§3.2 的风险）。
note 里的水印禁令不受影响：url 保留 ≠ 污染素材可用。painted_skin_room 的 scene 图右下角有 AI 生成
水印 + 飞书角标、note 明确「出片前必须换洗过的版本」，按 §0.5.2 仍要预检并可能阻塞；保留它的 url
只是数据完整性要求，不代表允许引用（两者不能混为一谈，这点要写进交付说明防止下游误读）。

4.4 本轮发现的真实缺口：非锚点图的「序号引用」写法
官方做法是把来源用序号标签内联进 Subject 定义（ref-en.txt L313 官方范例逐字）：


" is the fluffy white Samoyed in , , and , with thick white fur,
pointed ears, a dark nose, and a curved tail."


注意两点：(a) 这里连场景图都同时身兼 <Picture 1> 与 <Subject 1> 的来源（L312
" is the coffee-shop environment in "）；(b) 官方范例的 retention_analysis
只保留了 Subject 行，没有任何 <Picture N> 行（L320-L325），因为那些 Picture 只是来源、不被单独分析。
而 SKILL v0.3.0 §0.6 第 3 步给的写法是 "as established in the NPC portrait" —— 文字指代、缺序号。
按 ref-en.txt L37 这更接近官方文风的是 "...as established in <Picture 2>."。这是一处可直接修的小缺口，
修完还能顺带解决「幽灵编号」问题（§3.3）。

另一个需要注意的点（官方范例的静默信息）：既然立绘在模型流里天然占用 Picture 序号（§2.4），
那么「References 数组顺序必须与 <Picture N> 一致」（自查清单第 4 条）这句话在
「部分图不做 Picture 条目」的生产格式下含义要重新表述 —— 实际恒成立的命题是
「references 数组顺序 = 素材原始顺序 = 模型自动编号顺序」，与正文里有没有 Picture 定义条目无关。
4.5 边界推演：其他常见输入形态下怎么落位（均为基于官方规则的推演，非官方逐字）


形态
处理
官方依据


多镜头 / 有分镜草稿图
分镜图可用独立 <Picture N> 且显式声明映射到哪些镜头
ref-en.txt L72-L74: " is a storyboard reference for [Shot 1] and [Shot 2], defining their viewpoint, subject placement, and shot order."


NPC 多人（多张人设立绘）
一张立绘 = 一个 <Subject N>，各自在自己的定义句里内联引用自己的立绘本体（不带 Picture 条目）；每人首次出场按 §6 规则建立身份
ref-en.txt L41-L48（Subject 可为人/动物/物体等）+ L37


道具图（如某件兵器特写）
道具也是 Subject（objects 在 ref-en L43 列举中）；同理只在 Subject 定义里引用来源；除非该道具图本身被用作某镜头帧锚点
ref-en.txt L43 + L62


场景图但只取氛围不入帧
若仅风格/氛围参考则作 weak_reference 的来源处理，仍不必独立成条
ref-en.txt L168 (weak_reference: Only broad similarity in style, category, composition, or atmosphere is retained)


音频素材
进 <Audio N>，并按 §2.4 处理与说话人的绑定
ref-en.txt L92-L118


素材总数超限
合计 ≤ 12 文件（9 图 + 3 视频 + 3 音频各自上限之下还有总闸）
README.md L85


5. 【需求 (4)】六大盲区 + 两条补充表述的官方原文逐字定位

判读口径：只有能给出 raw.githubusercontent.com 文件 + 行号 + 引文的才记「官方原文」；
给不出的按任务要求显式标注「无官方原文，属合理推演」。


盲区 / 待办
定位结果
出处与关键引文


① 双说话人 (S1)/(S2) 编号稳定性
✅ 官方原文
base-en.txt L127: "Subjects who speak, sing, or produce an off-screen human voice use stable IDs such as (S1) and (S2). When multiple already-numbered speakers speak or sing together, use a compound ID such as (S1,S2). **A speaker keeps the same ID across shots; characters who never vocalize receive no speaker ID." ；ref-en.txt L278: "Assign (Sx) once according to the order of actual vocal events in the target video. Reuse the corresponding ID at every actual vocal event in detailed_description… Do not write (Sx) in retention_analysis."（跨镜头不变 + 目标视频出现顺序分配 + 不进 retention 三件事官方都有明文）


② 音频类素材 Audio N 锚定
✅ 官方原文
ref-en.txt L92-L106（§2.4 全节）：用途五类逐条列举 + "When an <Audio N> explicitly corresponds to a target speaker, reuse that speaker's global ID in the definition: write <Subject N> (Sx) when the speaker maps to a defined subject, or use a stable voice description followed by (Sx) otherwise."；L100 "The ID comes from the target video's global speaker order and is not independently assigned or renumbered in the audio definition."；L110/L112（Video/Audio 独立编号、同名源视频不一定产生 Audio N）；L193-L205 四个音频关系标记 fully_copy / partially_copy / reference / weak_reference 逐字表格


③ JSON 序列化通道可解析性
❌ 无官方原文，属合理推演
全部官方文本描述的是「提示词正文怎么写」，没有一处规定交付必须是 JSON、更没有 JSON 可解析性的要求。SKILL §0.5.7 第 11 条与本条是内部工程约定（from fde_report_v2 §四.3）。给 Digester 的处理建议：留在 checklist 里但当「内部工程规范」标注，不要在 SKILL 里冒充官方出处


④ 画外音 off-screen voiceover
✅ 官方原文
base-en.txt L136: "For voiceover, use the exact phrase says in an off-screen voiceover. Immediately after every voiceover <d> block, state that the corresponding on-screen character's lips remain closed:" + L139 例句；ref-en.txt L266: "If the same subject speaks off-screen, keep the same form and mark it as off-screen."


⑤ 人物出场过程（必须有进入方式）
⚠️ 官方无逐字条款，属内部推演
最接近的两条官方相邻规则：ref-en.txt L246 "At the first clear appearance of an important <Subject N>, describe its referenced characteristics, position in the frame, and current action within what is actually visible in the shot."（要求描写首次出现时的位置与动作，但没有要求交代进入过程）；base-en.txt L92 "A cut should introduce new information about the subject, space, state, viewpoint, or time."。「无过程突然现身是错误」这半句是 benchmark_v2 D6 引入的内部标准，不许写成官方规则


⑥ 道具跨镜头跳变
⚠️ 官方无针对道具位置连续性的逐字条款，属内部推演
最接近的官方一致性语句是 I2VA 语境下的 base-en.txt L54："Character identity, clothing, colors, key objects, and spatial relationships should remain consistent." 以及 Ref2VA 的保持度框架 ref-en.txt L165-L170（fully_preserved: The defined role of the referenced content is fully preserved）。跨镜头连续性检查（SKILL §5.3 第 3 条）仍是内部增强


补充A 原故事情节保留
⚠️ 无「保剧情」逐字条款
最接近：base-en.txt L172（T2VA Case 1）"You may add scene, character, action, and sound details that remain consistent with the user's intent."；反方向的官方原文倒是有一条硬话——ref-en.txt L207 "Do not treat newly added actions, backgrounds, or plot events in the target video as losses of reference fidelity."（说的是别把新增情节当保真损失，不是允许新增剧情）。SKILL §0.5.4 的「高风险剧情推断不得添加」仍属内部收紧，方向与官方不矛盾，但出处只能标内部


补充B 台词原语言保真
✅ 官方原文（三处叠加）
SKILL_official.md L33: "Write rewrite sections in English; preserve dialogue, lyrics, and visible scene text in their original language."；base-en.txt L129: "Preserve every original word and punctuation mark verbatim; do not translate or rewrite them."；ref-en.txt L5: "Preserve the original language only for dialogue and lyrics inside <d> and for text visibly present in the scene."


5.6 ⚠️ 本轮最重要的新发现：对白标点的两个官方条文作用域不同（表面互斥）

base-en.txt L129（面向用户提供的台词，基础模式与 Ref2VA 通用）：
> "Inside <d>, include only the language tag and the actual user-provided spoken content.
> Preserve every original word and punctuation mark verbatim; do not translate or rewrite them."
ref-en.txt L274（面向从参考音频直接复用的台词/歌词/旁白，或输入明确要求 reperformance 的情形）：
> "When dialogue, narration, or lyrics from reference audio are directly reused, or when the input prompt
> explicitly requests their reperformance, preserve the exact source words and original language inside <d>.
> Write [unclear] for unintelligible spans instead of guessing or paraphrasing them.
> Standardize punctuation to the basic written marks needed to express the sentence, such as ,, ., ?,
> and !; remove repeated tildes, emoji, bullets, and repeated or decorative punctuation. End complete
> statements, questions, and exclamations with ., ?, or ! respectively before </d>."


也就是官方体系里其实存在两种合法口径：


用户直接给的台词 → 一字一标点 verbatim（TS-11 现行判据，conv-mtabpqx9 的「你出去看看」就属这类，
维持现判不受影响）；
从参考音频复用/重演的台词 → 允许（官方甚至要求）清理标点和装饰符号。


风险：SKILL §0.5.5 / §6 / 自查清单第 16 条现在写成全局「不擅自添加/删除/改动标点」，
一旦测试场景出现「复用 BGM 里的歌词」或「重演原声」，现行硬判会把官方要求的标准化误判成硬错误，
或者相反。这是六盲区之外、由逐字阅读新暴露出的一个判据分叉，必须由 Digester 拍板作用域条款
（建议写成：先判台词来源——用户提供 / 参考音频复用——再选对应标点规则，两句一并保留原文）。


6. painted_skin_room 样例的三张图在官方规则下的落位（演示，含推演标注）
生产样例：scene = 昏暗旧屋场景参考（note 含水印警告：「右下角 AI 生成水印+飞书角标，出片前必须换洗过的版本」）；
npc = 白衣古装女子立绘（pack tag model_sheet_face 带 real face，note 明确别用 model_sheet——那张脸涂黑了）；
player = 深色长袍捕快立绘（tag constable_model_sheet_face）。


资产
资产层（进 references，url 原样）
正文层
note 处理


scene
{"id":"scene","role":"场景参考","url":"<OSS原址>","label":"background 1"(仅当走读法A)}
<Picture 1> 独立定义（构图锚点）；同时可作为环境型 <Subject> 的来源
水印+飞书角标 → 按 §0.5.2 属「必须替换」型 note：必需且无替代即阻塞，阻塞报告要写明预期补料后的 references 顺序与绑定预案


npc
{"id":"npc","role":"NPC 立绘","url":"<OSS原址>",...}
不另起 <Picture 2> 定义条目；<Subject 1> 的定义句内联引用其序号，并把 model_sheet_face 指定版写进去
「别用 model_sheet 版」= 版本要求型 note（§0.5.2 第 5 条）：菜单里有正确版（face 版）就不阻塞，选定 face 版即可


player
{"id":"player","role":"玩家立绘","url":"<OSS原址>",...}
同 npc，绑 <Subject 2>；正文里捕快的具体可辨识特征必须写实（深色长袍款式等，满足 §4.1 硬规则）
constable_model_sheet_face 为指定版，照选


写法示意（读法 B，English 正文内的一行）：
<Subject 1> is the woman in flowing white ancient robes with a delicate, unnaturally pale face, as established in <Picture 2>.
（此行是推演产物：<Picture 2> 序号来自素材顺序 + chat_template 编号机制；官方范例证明这种内联引用是官方文风，
但官方没有写过古装题材的具体句子。）

summary 前缀通常：[keyframe completion + reference generation]（scene 作首帧/构图锚点 + 两立绘仅作生成指导）；
若 scene 也只当氛围来源则退化为 [reference generation]。


7. 未核实 / 受限事项（如实，不充当任何结论依据）

MiniMax 开放平台 API 文档不可达（platform.minimax.io / platform.minimaxi.com，WebFetch 域校验被拒、curl 超时；
三次尝试一致）。因此开放平台 /video-generation-v2-create 的官方请求 schema（其字段名可能与 SGLang 的
conditions[].uri 不同）未核实。README.md L58 只证实了这个入口链接的存在。
图片-only Ref2VA 请求里 conditions[].role 的完整枚举值未核实：官方脚本给了 video/audio 的
"reference" 和 image 的 "keyframe"（FL2VA 场景），没有抓到「图片 + role=reference」的官方案例。
上一轮遗留的飞书标杆文档依旧未访问（沿用 v1 §9.6 状态，本轮没有重新尝试）。
H3-Context-IR / H3-Regenerate-2K 的请求细节未展开（scripts/readme 下另有 4 个相关脚本，本轮时间预算内未抓；
与本轮 4 个需求的相关性低，与 2K 工作流改造相关时可再抓）。
README.zh-CN.md 仅核对存在与字节数（36894），未逐行比对与英文版差异；引用一律以英文版为准。
§4.5 的边界表、§6 的落位示范、「幽灵编号收口」规则均为推演，已在各自位置标注，不得当作官方出处转述。

8. 给 Digester / Evolver 的增量建议（只在 v1/v2 基础上追加）

拍板 §3 的读法选择（或混合形态），据此更新 §0.6 与自查清单第 3/4/5 条的三句话表述。
把 §5.6 的标点作用域写进 §6：按台词来源分流（user-provided → verbatim；audio-reused → official standardize），
两句官方原文都要带引文落位，避免下一轮再发明第三次口径。
§0.6 第 3 步的来源引用改为官方式 <Picture N> 内联写法（§4.4），并同步自查清单第 5 条的措辞
（把「立绘是否另起图片条目」改成「非锚点图是否被某条 <Subject N> 序号引用，而不是凭空丢编号」）。
benchmark 增加「资产层 url 保真」判据：references 中每条必须携带原 url 且顺序 = 输入菜单顺序，
同时保留水印阻塞逻辑不受影响（§4.3 第三点）。
六盲区中 ③（JSON 通道）、⑤⑥（出场过程/道具跳变）三条在 SKILL 里要把出处标成「内部规范/推演」，
①②④ 已经有三处官方引文可以直接补充引用（§5 表）。
下轮 Hunt 可选补课：开放平台文档（若网络放开）、full-2k-ref2va-* 四个 2K 脚本、
ComfyUI R2V 模板里 role 枚举的第二信源验证（README L209 提到 workflow_templates 链接）。