ddcat-ai/open-ai-canvas/13

交付文件审核（模块 13）

主链定位：PV 校验 + TD 放行 + T2V/I2V 交付规格 + 负面约束总库。

做什么

本模块是 13 级主链的最后一道闸门，也是整条链的质量闭环。它做三件事：

1. 放行 —— 交付文件能不能出（PV 校验 + TD 放行）。
2. 定规格 —— 交付按 T2V 还是 I2V 出、字段与形态怎么钉死。
3. 兜底与复盘 —— 负面约束总库集中取用；生成之后失败时，走失败诊断层定位、裁定、记录。

本模块无 `engine/`：四本导演学专著不覆盖交付审核与失败诊断，本模块的知识源是数据层而非方法论引擎。

数据层

⚠️ 本模块只判不合，不持有拼装规则。 交付文件的制造（三模式顺序、即梦形态、负面三法）全部归 12——

顺序见 12/SKILL.md §按模式的拼装顺序；即梦形态见 `12/platform/09-即梦交付拼装规格.md`（负面三法的规则归属地）。

本模块拿它们当尺子判合规。同一份交付文件里，12 出的规则与 13 判的判据不得混写。

失败诊断闭环（review/）

第一步永远是分层，不是修复

总纲：诊断先于修复。绝不在诊断之前原样重发——同样的文本会绊响同一个分类器、踩中同一处渲染边界；重发不是诊断。

循环出现的即时失败是过滤器问题，绝不是渲染能力问题——在重写完成之前，先拦住重新生成的手。

先分岔——系统性还是随机性

在约 1.5% 的视频通过率门槛下，大多数失败是方差，不是提示词坏了。

• 失败都是同一种失败 → 系统性：提示词错了，走单变量迭代。
• 失败方式五花八门、偶尔接近命中 → 随机性：锁定提示词，批量开火，然后淘汰。

防线：一个保留者、其余全部记账（保留 + 真实的淘汰原因），分母保持诚实。整批都过不了硬性闸门 → 失败终究是系统性的，停止收割，回去迭代。

镜头裁定——交付镜头的五种裁定

修复处理的是彻底失败；大多数真实交付落在中间地带部分可用。任何东西重新触发之前，每条交付镜头必须拿到五种裁定之一：

重写绊线是双向的：同一瑕疵出现两次 → 停止往同一堵墙上重掷；每次都是不同瑕疵 → 失手是随机的，属于批量抽卡的领地而不是重写。

尝试预算——第一条镜头开拍前声明：一个条数预算数字 + 一条写下来的"够好"标准（主要目标已交付、次要瑕疵可后期）。不写下来，这个标准会悄悄变成"完美"，而任何预算都扛不住"完美"。预算过半而同一瑕疵毫无进展时，停止迭代并改变策略。

拍摄日志：每条镜头一行——改了什么、结果如何。两行共享同一瑕疵，重写绊线就可审计。

交付前自我修复清单

发送前把对策整合成一遍预防（每条提示词花 60–90 秒，在烧额度之前抓住大多数可预防的失败）：

• [ ] 帧率写在提示词正文中（不只元数据头）？
• [ ] 身体/感性语域 token 已清理？
• [ ] 首次出现的元素已标记"不在源关键帧中"？
• [ ] 相邻物体不变量已点名（"X 保持吸附""Y 不移动"）？
• [ ] 运动把整条片段花在一个方向上？短动作串成 2–3 个同向节拍？运镜有具名终点？
• [ ] 对白窗口被完整写出？短台词扩长或静默写进脚本？每张可见的脸都带嘴部状态？
• [ ] 每镜头一个主导运镜？复合运镜拆成先后相位或分开的剪切？
• [ ] 几何用空间布局块锁定？
• [ ] 为最终条次预留了逐帧审查时间？

完整清单、诊断流程图与视觉锚定诊断流程见 review/13-失败诊断.md。

交付规格与放行

T2V / I2V 交付规格 —— 按模式判合规

交付按哪种模式出，决定这份文件该有什么、不该有什么。12 负责按顺序拼装（`SKILL.md` 的「按模式的拼装顺序」节），本模块负责判它合不合格——逐条判据见 review/14-交付规格与合规判据.md。

声音层档位（三模式通用）：交付文件头部必须声明 【声音层】全量 / 去配乐。

• 全量（默认）：⑧对白 + ⑨背景音 + ⑩BGM 三轨齐全。
• 去配乐：⑩ 必须是 `NO BGM`（显式抑制），且不得残留任何音乐类 token（除 NO BGM 本身）。
• ⚠️ 去配乐 ≠ 省略 ⑩：Seedance 2.0 自带音效/配乐，不声明 ≠ 不生成。判据 G7（档位与内容匹配）/ G8（档位已声明）/ G9（零音乐 token）。

放行规则：全部 PASS 才放行；任一 FAIL 即阻断，并按判据编号退回对应模块（12 拼装 / 04 首尾帧两图 / 08 运镜 / 09 声音与档位）——本模块不改写内容。

完整判据（G1–G7 / T1–T5 / F1–F6 / L1–L7）与退回路由见 review/14-交付规格与合规判据.md。

负面约束总库 —— 已补实

本模块持负面约束总库，供各模块按类取用。本层已由两件补实：

已指向本层的三处（现在都有表可查）：

取用纪律：03 render/12 已明确——负面约束层只负责按类生成，不负责机械堆入最终提示词；成表与按类取用归本模块。

⚠️ 两件的关系未做合并：16-负面约束总集 是漫剧导演全流程口径，15-负面词全量 是 DirectorPlus 口径，两者有重叠但组织方式不同。同一规则两处出现时以 `16-负面约束总集` 为准（层级更完整），避免双源漂移。

PV 校验 / TD 放行（待补）

路由表把本模块前半段定义为"PV 校验 + TD 放行"，但判定细则未随包提供（PV / TD 的确切所指与校验项清单均无原文支撑）。⚠ 待确认——请补充这两项的字段清单，或改写下表：

两项未补齐前，链尾闸门以 `review/13-失败诊断.md` 的交付前清单 + 五种裁定为准执行。

与其他模块的关系

• 上游：接收 11 导演链路校验放行的产物；11 不通过时回溯返修，不回本模块。
• 12 是交付文件的制造方（语言转换与提示词结构）；本模块是审核方——只判过不过，不改写内容，改写一律退回 12。
• 02 / 03 / 06 向本模块的负面约束总库投稿（按类生成反向约束），由本模块集中成表与取用。
• 05 `performance/04-表演约束与质量控制.md` 的预防块与本模块失败诊断层同源（Seedance / 即梦的 AI 生成瑕疵），两处诊断同一现象时以 05 的表演侧措辞、本模块的裁定与记录为准。