sweety-handdraw-video 是一个把主题、文章或完整故事做成手绘讲解视频的 Skill：按部位描线、逐字书写、VoiceStudio 配音，并内置五项制作依赖。它最值得学习的机制，是成片交付前的双层质量门槛——工程检查（verify）与观感验收（review）分开记录、互不替代，外加一套明确的返工规则：问题先定位到层，只改对应层，同一失败连续三次无改善就换路线。本文讲清楚这套"质量检查"体系怎么运作，以及如何用它避免"文件能播放"被误当成"视频可以交付"。

先看懂：两道门槛各管什么

很多人以为"渲染成功 + 能播放 = 验收通过"。这个项目明确拆成两层，且规则写在 quality-gates.md：

• 工程检查：由verify命令执行，完整解码 MP4、核对像素、路径、时序与音频指标，输出工程结果并生成实际成片的抽帧；
• 观感验收：人工（或模型看图 + 实际听音）对内容、画面、运动、声音、隐私五个维度逐条记录证据，写入review.json；
• 交付回执：finalize仅在"工程结果匹配当前文件且五项观感记录明确通过"时才生成。

一个细节很能说明设计意图：verify通过后的状态名不叫 "passed"，而是engineering_passed_review_required——工程通过，但观感仍未验收。名字本身就在提醒你还差一半。

第一道门槛：verify 到底检查了哪些工程项

完整命令链见 runtime-contract.md：

python3 skills/sweety-handdraw-video/scripts/handdraw_video.py doctor /path/to/job python3 skills/sweety-handdraw-video/scripts/handdraw_video.py build /path/to/job python3 skills/sweety-handdraw-video/scripts/handdraw_video.py render /path/to/job --preview --duration 15 python3 skills/sweety-handdraw-video/scripts/handdraw_video.py render /path/to/job python3 skills/sweety-handdraw-video/scripts/handdraw_video.py verify /path/to/job

其中render --preview --duration 15是"代表段先行"：先渲染 15 秒覆盖文字、上色、字幕与转场的短段实际看过，再渲染整片。verify的检查项可以归纳为四类（实现见 video_verifier.py）：

1. 绘制路径类
   • 插画的每个可见像素都有语义部位归属，所有轮廓完成后才填色，两阶段按同一部位顺序；
   • 文字/线稿的显现位置必须靠近笔尖（距离 < 9px），每个颜色像素都要有真实笔刷覆盖，不允许剩余色块在最后一帧整体补齐；
   • 手写文字逐字隔离，前字未完成不得露出后字；字形四边保留至少 5px 空白，字脚、下伸部不能被裁掉；
   • 封面前 0.5 秒静止、0.5—1.0 秒渐隐，旁白 1 秒后才开始。
2. 成片文件类
   • 完整解码音视频并核对分辨率、帧率、H.264 + AAC 编码；
   • 音画时长差 < 0.08 秒；成片时长必须覆盖完整旁白时间线；
   • 响度在 -20 ~ -14 LUFS 之间，真峰值 < -1 dBTP；
   • 编码音轨与预期混音的波形相关系数 > 0.99，最后一句单独再核一次（> 0.98）。
3. 时序与字幕类：同一主笔事件不重叠；绘制在旁白结束前 0.45 秒完成；字幕时序有序、无越界。
4. 哈希指纹类：任务清单、时间线、旁白、封面、手部素材乃至脚本文件全部参与指纹计算。渲染后任何输入变化，verify/finalize直接拒绝，必须重新构建渲染——旧的通过记录不能跟着新文件走。

verify还会从实际 MP4 抽帧拼出一张抽帧联系表（decoded-contact.jpg），供观感阶段使用。注意：稀疏抽帧只能验证字形与版面，不能单独证明全片运动流畅——这正是第二道门槛存在的原因。

第二道门槛：review.json 里的观感验收怎么填

工程检查通过后，任务目录会生成一份review.json骨架，执行者实际看过成片之后逐条填写：

{ "video_sha256": "实际视频哈希", "content": {"status": "pass", "evidence": "事实/限定/来源和字幕已核对"}, "visual": {"status": "pass", "evidence": "实际看过的帧、时间段及修正结果"}, "motion": {"status": "pass", "evidence": "实际看过的绘制/上色/转场"}, "audio": {"status": "pass", "evidence": "ASR或听音依据"}, "privacy": {"status": "pass", "evidence": "清理工具与复核结果"}, "limitations": ["未实际完成的听感或其他主观验收"] }

五个维度的填写边界被规定得很死：

• pass/fail/not_checked必须基于观察，不可由脚本自动填成通过；
• 只做了 ASR 转写核对，就不能写"已经完整听过"，要把"主观听感未验收"如实写进limitations；
• 内容维度要求"叙事事实必须在图中成立"：每幅插画的narrative_requirements列出原文引用与可观察条件，drawing-review里逐条记录状态和可见位置证据，"主体正确""图片存在"这类空话不算证据；
• 交付检查还包含 MP4 无额外字幕轨、同目录无 SRT/ASS/VTT 文件等硬性条件。

finalize会做三重哈希比对：工程报告里的视频哈希、review 记录里的哈希、磁盘上 MP4 的实际哈希必须完全一致，任何一项对不上就判定"review 属于另一个视频"。

返工规则：只改对应层，且不无限重试

发现问题时的流程不是"整体重做"，而是先定位问题属于内容、素材、声音、路径还是时间安排，然后只修那一层。quality-gates.md 给出的示例很直观：

三条红线同样明确：

1. 同一失败连续三次没有改善时，改路线或报告具体阻碍，而不是第四次重试；
2. 不无限生成付费素材，不把相同失败当新候选；
3. 不通过"仅延长视频"来掩盖机制问题。

这套规则配合"声音决定节奏"的主时间线设计（见 audio-and-ending.md）特别重要：改变分页不得改变旁白波形，改变旁白后必须重算画面和字幕——视频页面永远不能成为声音切口。

两个容易被忽视的硬门槛

🔍 字幕唯一性是交付硬门槛。同一句旁白在同一时刻只允许显示一份字幕。无论是画面烘焙、字幕事件、MP4 内嵌字幕轨、网页<track>还是播放器自动加载的字幕文件，任何双字幕直接判 FAIL。交付前要实际解码画面检查长句、换句和片尾，第三方播放器的自动翻译/实时字幕须单独关闭。

🎧 "文件完整"不等于"收尾自然"。默认不添加背景音乐（交付时必须告知用户可自行配乐）；母带至少保留末次发声后 0.12 秒保护，成片尾部静音不得超过 1.2 秒；检查末句时要单独看末句后的完成画面与尾音，而不是只看时长相等。

下面这张来自内置依赖示例资产的画面，正是观感阶段需要逐页核对的对象类型——元素是否都在画布内、层级是否正确、文字是否完整可读：

相关文件速查

小结

sweety-handdraw-video 的质量体系可以浓缩成三句话：

1. 能播放 ≠ 能通过：verify只做工程检查，状态名就叫"待观感验收"；
2. 验收必须写证据：五个维度逐条记录"实际看到了什么"，脚本不能替你填pass；
3. 返工要定位到层：只改对应层，三次无效就换路线，而不是无限重试。

对新手来说，这套"双层门槛 + 哈希绑定 + 分层返工"的做法，比任何单点技巧都更能保证手绘讲解视频在交付前不翻车。