正文
获取原文件references/delivery-profile.md
目录
一、档案由创作者声明，本文只规定槽位职责
交付档案是创作者可选声明的一份排布约定：把已接受的运动规格摊成执行端逐行读取的 文本。本套件只规定每个槽位必须回答什么（语义），不规定它写成什么样子（语法）。
- 槽位语义属于本套件：一个位置槽必须回答“相对哪个画面内可命名的锚点”，换任何 执行端这个问题都成立，也不含任何供应商内容；
- 槽位拼写属于创作者档案：用什么括号、分隔符、编号前缀和字段名，随执行端更换而 作废，本套件不规定，也不把任何一种拼写当作标准格式；
- 项目没有声明档案时，按 motion-recipe.md 写连贯的自然语言即可。 不要为了“像个格式”自造槽位，空槽位比缺槽位更难审查。
数字规则仍然一律拒绝，只有两处例外，因为它们是对创作者已接受值做算术，不引入 任何新标准：时长在两个层级上都必须精确加总（分段之和等于所属镜头的已接受时长，容器 时长等于其成员镜头已接受时长之和）；分段标识必须唯一且有序。除此之外的档位、配额、 每镜增量和元素上限都不由本文档提出。
容器之外的交付路由
容器回答的是“一次交付里装几个已接受镜头”。有些执行方式还会改变这一次从哪里开始生成， 那是另一个维度，容器字段表达不了：
| 路由 | 起点来自 | 对本套件产物的影响 |
|---|---|---|
| 逐镜（默认） | 该镜已接受的起始边界 | 无 |
| 多镜打包 | 首个成员镜头的已接受起始边界 | 无，按本文容器算术记账 |
| 单次长生成 | 覆盖段落中第一个镜头的已接受起始边界 | 无；按多镜容器记账（见下） |
| 从已生成结果续接 | 上一次生成出来的结果 | 多一层证据义务，见下 |
前三种只改变打包粒度。镜头目的、起止边界与逐镜可审查性不因为”这次一起生成”而消失。
单次长生成不是容器之外的第三种账。 它承载多个已接受镜头，所以就是一个多镜容器，
照 VID-13 与 VID-15 记账：成员来源顺序连续、共享同一条绑定链、不跨场次边界，
容器时长等于成员已接受时长之和，且在全集账目里只被算一次。它只是把切换交给执行端
在已接受的成员边界上完成，不把若干镜头合并成一个没有内部边界的长镜。
若一次长生成想跨越 Location/View 变化或场次边界，先拆成两个容器——这一条没有例外，
“执行端一次能读多长”不是创作决定。
第四种不一样：它的起点是一段已经生成出来的媒体，而这段媒体在本套件里不是权威产物，
最多只能是一条 generated_result 观察记录（两种观察的区别由核心的参考资料定义）。
因此续接路由要同时守住两条：
- 已接受的镜头起始边界仍是唯一权威。续接不产生第二个起点取值权威；不能因为“结果看起来 是这样”就把观察到的状态回写成镜头边界。两者不一致时先回分镜发修订请求，不在交付层调和。
- 对结果状态的任何主张都要绑定观察记录。没有创作者提供或授权形成的观察时写
unverified， 并说明续接依据缺失。不要凭想象补一个结尾画面：续接提示词的每一条连续性指令都建立在那个 起点上，起点是编的，后面整条链一起作废。
连续段真正进入生产时，下一段同时使用两项真实输入：
- 上一段实际视频：承接已经生成出来的动作速度、人物表演、运镜、环境运动与声音空间；
- 上一段实际尾帧：从该视频直接取得，作为下一段第一帧的人物姿态、双手、持物、光线与构图起点。
二者职责不同，不能只给其中一项，也不能用计划尾帧、分镜关键帧或文字描述冒充。提示词仍按下一段 已接受的「起点 → 唯一动作 → 终点」写；实际尾帧若与已接受起点冲突，先处理上一段结果，不能把漂移 写进下一段继续放大。
创作者已经选择续接后，缺素材只改变就绪状态，不改变执行路由：后续容器标成“待续接、不可提交”， 列明缺少上一段实际视频与实际尾帧，继续保留从已接受起点写出的内容草案；不得把它改称普通文生视频。 真实素材到位后再按模型方言加入续接触发词与实际槽位。逐镜运动正文继续承担成员边界和内容依据， 不能被当作绕开续接的平行提交方案。
路由由创作者档案声明。项目没有声明时按逐镜写，不为“支持更多路由”预留空字段。声明后在
视频提示词.md 只标一个正式执行路由；其他粒度的正文若因可审查性而保留，要明确标成成员依据。
这里的“逐镜 / 多镜容器”是打包粒度，不自动表示独立生成。同一场次、时间连续、地点与资产绑定链
不变的相邻正式段，在目标档案支持续接时默认组成实际结果接力链：第一段从已接受起点生成，第二段起
等待上一段实际视频和实际尾帧。只有创作者明确选择独立重生成，或已接受内容发生时间/地点跳变时才
重新起链；不能仅凭 one-shot-per-generation 把每镜都解释成互不相干的文生任务。
二、容器算术（唯一允许的数字规则）
容器是执行端一次读取的交付单位。它可能正好等于一个已接受镜头，也可能按创作者声明的 打包方式承载若干个连续的已接受镜头。两种形态下算术都只对创作者已接受的值做加法， 不引入新标准：
- 单镜容器：容器时长 = 该镜头的已接受时长。分段是容器内的有序切片，用来给动作 因果分配时间，不是新的剪辑边界——一个分段内不允许出现第二次切换（见 review-and-fixtures.md 的段内藏切）。
- 多镜容器：容器时长 = 各成员镜头已接受时长之和。成员之间的边界仍然是真实剪辑 边界，打包不合并、不改写、也不重新分配它们；每个成员镜头内部再按上一条切分段。
两种形态的区别只在“容器里有几个镜头”，不在“镜头是什么”。把多个镜头装进一个容器 不会让它们变成一个长镜，也不会让它们失去各自的目的、边界与可审查性；反过来，容器时长 若不等于成员时长之和，多出或少下的时间会落在没有任何镜头负责的区间里。
structural_invariant：容器只能承载已接受镜头；容器时长等于其成员镜头已接受时长
之和；镜头边界、镜头目的与逐镜独立可审查性不因打包发生变化（VID-13）。
这条不变式必须可本地核对，所以需要多镜打包时，在 视频提示词.md 增加“交付分组”章节：
用稳定组 ID 依次列出成员 MOTION-... / SHOT-...、各镜时长、容器总时长，以及同场、连续、
同一地理/资产链的理由。单镜交付不需要额外章节。
双向和不变式
structural_invariant：在每个成员镜头内部，所有非重叠分段的时长相加必须等于
该镜头的已接受时长；重叠段要写明重叠关系。两个方向都是缺陷：
- 超出：落在该成员镜头已接受时长之外的那部分被执行端截断，段尾的动作、逐字
对白和终点姿态一起丢失，
end_report会声称到达了从未被拍出的终点。在多镜容器里， 它还会挤占下一个成员镜头的起点，把两个镜头的边界一起搞坏； - 不足：执行端可能把已写动作拉长去占满镜头，写下的秒点整体后移，计划不再描述成片 （观察与修法见 motion-recipe.md 3.6）。
多镜容器的成员资格
打包不是把相邻镜头凑够时长。可以同处一个容器的镜头必须同时满足：
- 来源顺序连续：在已接受的覆盖里相邻，且容器内顺序与来源顺序一致；不跳镜、不重排。
- 绑定链不变：共享同一条已接受的地理与资产绑定。出现新的 Location/View、新的资产 变体、新的可读文字义务或任何未解决绑定时，必须换容器——否则执行端会把绑定切换当成 同一空间内的位置移动。
- 不跨场次边界：容器不跨越已接受的场次或时间跳跃。省略、闪回分支与声明过的蒙太奇 各自单独成容器。
- 各成员仍可单独审查：每个成员镜头保留自己的目的、起止边界与终点报告，容器只是 它们的排布方式，不是新的权威记录。
不满足时就拆容器。容器数量由绑定链和场次决定，本文不设配额；执行端一次能读多长也不是 创作决定，若打包方式与镜头边界冲突，改打包方式，不改镜头。
全集账目：一个镜头只能被算一次（VID-15）
单个容器的时长加总正确，不代表全集的账是对的。容器逐个看都成立，而某个镜头同时出现在 两个容器里，或者某个镜头谁都没装——两种错误在单容器视角下都看不见。前者让全集时长凭空 多出一段，后者让一个已接受镜头无声消失，而它对应的台词、绑定与关键帧提示词都已经做完了。
structural_invariant：在一集之内，一个镜头最多属于一个容器。容器不必覆盖全部镜头，
未装容器的镜头可以直接交付；但容器成员与散镜合起来，必须不重不漏地正好覆盖本集镜头集合。
重复计入或无人认领都是缺陷，不是打包偏好。
对账方法就是集合运算，不需要判断：把各容器的 members 展开取并集，与覆盖记录里本集的
镜头集合相比——交集之外的差集两侧都必须能解释。任一侧非空且解释不了时，先修容器划分，
不要调整镜头时长去凑总数。这条与 SHT-16 的加总互为验算：镜头侧给出本集应有的总时长，
容器侧给出实际打包出去的总时长，两个数字必须相等。
有一种情况拆容器解决不了：单个已接受镜头本身就长于执行端一次能读的长度。容器只能 承载整镜，分段又不是剪辑边界，所以这里没有打包层的解法——回分镜环节发修订请求， 把该镜头拆成两个已接受镜头，而不是在交付层把它截断或硬塞。
分段标识
分段标识必须唯一、连续，并按时间升序。重复或跳号会让引用无法解析，也让审查者无法把 问题定位到具体一段。分段数量由动作的因果节点决定，本文不设配额；但把整镜写成一个不 分段的整块，等于把全部时间交给执行端自行分配，这是最常见的失控形态——不是因为“段 太少”，而是因为没有任何一段说明这几秒里先后发生了什么。
三、槽位语义表
| 槽位职责 | 该槽位必须回答什么 | 省略会怎样失败 |
|---|---|---|
| 空间 | 本段发生在已接受场景的哪个可命名区域？画面外紧邻的是什么？ | 执行端沿用上一段残留或参考图猜测环境，同一场景在段与段之间换了地理，正反打穿帮 |
| 姿态 | 段首人物的重心、朝向、双手与持物是什么？段尾变成什么？ | 段与段之间人物瞬移、换手、道具凭空出现或消失，接触动作失去因果顺序 |
| 位置 | 相对哪个画面内可命名的可见锚点？距离与朝向怎样可比较地表述？（裸写的左右指画面左右；人物自身的左右要带主体） | 只剩绝对坐标或“靠左一点”，执行端按自己的构图重排人物，轴线与遮挡关系随段变化 |
| 表演 | 触发是什么，可见处理是什么，落到哪个状态？这个形容词要演到多硬？ | 只剩情绪标签，执行端按平均值演；同一个形容词在不同段被演成完全不同的强度 |
用法：
- 表演槽与剧本
（情绪）括注同源：同一个括注同时决定表演状态和说话方式。三者 （标尺值、可见表演、说话方式）互相矛盾时以剧本括注为准，需要改动就发修订请求； 形容词要演到多硬的问题见 performance-action-timing.md 的表演标尺。 - 每个槽位只写本段执行需要的内容。参考帧已经承载的外貌、整套服装和静态构图不重复。
- 槽位留空好过槽位填废话。没有依据就留空并记为未解决，不要用“自然”“电影感”“氛围 拉满”占位——这类词占住了槽位，却没有回答槽位的问题。
- 交付文本里不出现
hash、参考图文件名、内部规则 ID、锁定标记、草图指代或任务备注， 见 production-prompt-grammar.md 的“交付文本只含交付内容”。
四、必须原样保留的文本
交付文本里有两类内容不能被改写，失败方式相反：台词被改写会念错，触发词被改写会 什么都不发生。两类都由创作者档案声明，本套件都只规定它们必须回答什么。
逐字对白围栏
必须逐字保留的文本要用档案声明的定界符与描述文本隔开：围栏内是原样保留的台词， 围栏外是可以改写的描述。围栏是一道文本边界，不是风格选择——没有它，执行端会把台词 当描述改写、翻译或压缩，也可能把描述句当成台词念出来。
- 围栏内只放台词本身与必要的说话人标识；情绪括注、导演提示和动作说明写在表演槽或 围栏外的相邻描述里。
- 围栏用哪一对符号来自创作者档案，本文不规定。
- 画外音、旁白与同期对白各自带明确的声源标识；把三者混进同一段无标识文本，执行端无法
决定要不要对口型。声源标识里一并写这句台词的口语语言：说话人的
voice_direction.language已经定了就照写，没定就向创作者确认后再写，它与描述文本用什么 语言无关。不写，执行端就按描述语言念，得到错的配音语种和错的口型。
执行触发词
有些执行方式要求交付文本里出现固定字样，才会走到对应的处理路径。它和逐字对白同属 不可改写的文本，但风险方向相反。
按字面匹配的入口，通常不会因为字样被改写而报错——改写后的句子仍然是一段合法描述， 于是那条路径没有被选中，而请求照常返回。本提示词环节不调用生成服务，因此不断言任何具体 入口的实际行为；这里只说明为什么这类改写值得当成缺陷防：它的失败是安静的， 交付文本读起来完好，不像超时或参数错误那样自己暴露出来。
至于某一次结果是否真的走了那条路径，属于结果服从度，只能由绑定的生产观察支持， 不能从提示词文本推断。
- 触发词由创作者档案声明。本套件不规定任何具体字样，也不推断某种执行方式需要哪些词； 档案没有声明就不写，凭空加入的“固定字样”只会变成画面上的文字或多余的旁白。
- 一旦声明，就在该路由的交付文本里逐字节出现：不同义替换、不翻译、不省略，也不为了 “读起来顺”改写语序。这与参考编号的稳定性同源——都是执行端按字面匹配的记账，不是措辞偏好。
- 触发词写在描述文本中，不进逐字对白围栏：围栏内的内容会被当作要念出来或要显示的台词。
- 触发词只声明路由，不替代内容。写了续接字样不等于说明了续接从哪个状态开始， 该写的起点、动作与终点一条都不能少。
reviewed_invariant：档案声明了某路由的必需字样时，该路由的交付文本逐字保留它们；
审查者拿档案声明与交付文本比对（VID-19）。档案给出可机读字样清单后校验器才可能接管，
在此之前不声称机械阻断。
五、合成示例（记号来自创作者档案）
以下人物、场景与记号均为合成材料。这是一个单镜容器：镜头已接受时长 5.0 秒，容器 时长同为 5.0 秒，三段相加正好 5.0 秒。若同一场戏的下一个镜头也被装进这个容器，容器 时长就变成两镜已接受时长之和，而每个镜头内部各自重新分段。
[段1 | 0.0–1.6]
〈空间〉檐廊内侧，右手边是通向内院的门；门外区域本段不入画
〈姿态〉角色甲半跪，重心在右膝，左手扶栏，右手在竹箱内翻找
〈位置〉角色乙站在角色甲右后方约两步，位于角色甲视线之外
〈表演〉角色甲听见身后一次落锁声，翻找动作停住，未回头
〈对白〉无
[段2 | 1.6–3.4]
〈空间〉同上
〈姿态〉角色甲右手离开竹箱、按住箱盖；角色乙双手仍垂在身侧
〈位置〉角色乙向前一步，进入角色甲右侧余光
〈表演〉角色甲从警觉转为压住不动；角色乙保持不变，只等对方先开口
〈对白〉〔角色乙 · 同期 · 汉语〕「你找的东西不在里面。」
[段3 | 3.4–5.0]
〈空间〉同上
〈姿态〉角色甲合上箱盖并把左手撤离栏杆，重心移回双膝
〈位置〉两人相对位置不变
〈表演〉角色甲落到承认被看见后的克制，未反驳
〈对白〉无
〈…〉、方括号、竖线、分段编号和对白围栏的写法都来自创作者档案，本套件不把其中
任何一种拼写规定为交付格式。可迁移的只有每一行必须回答的问题。若只写到 3.4 秒就收尾，
前两段的动作可能被拉长去占满 5 秒，段边界的秒点就不再是实际发生的时刻。
六、自检
- 容器里装了几个已接受镜头？容器时长是否正好等于这些镜头已接受时长之和？
- 在每个成员镜头内部，各分段时长相加是否正好等于该镜头的已接受时长？余量是被分配了， 还是只写到一半？
- 多镜容器的成员是否来源顺序连续、共享同一条绑定链、不跨场次？是否每个成员仍能单独审查？
- 分段标识是否唯一、按时间升序？有没有跳号或重复？
- 每个分段内是否只有一个连续视角？切换是否都落在成员镜头边界上，而不是藏在段内叙述里？
- 位置槽是否指向画面内可命名的可见锚点，而不是绝对坐标或模糊方向？
- 姿态槽的段尾状态是否等于下一段的段首状态？最后一段是否落到已接受终点？
- 表演槽是否写了触发与可见处理，而不是只有一个形容词或一个数字？
- 逐字对白是否在围栏内原样保留？声源（同期、画外、旁白）与这句台词的口语语言是否分别标明？
- 交付文本里是否只剩要被拍出来的画面内容，没有工艺备注与内部记号？
- 档案声明的执行触发词是否逐字节出现、且留在围栏之外？没有声明时是否也没有自造字样？
- 本次用的是哪条交付路由？若是从已生成结果续接，起点状态是绑定了观察记录，还是仍为
unverified？有没有把观察到的状态当成新的镜头边界？