做一条 10 分钟 AI 漫画视频，难的不是生图，是全程不出戏

任务一：先冻结原始文案，再建立项目配置

输入：一篇已经确认的中文人生故事，以及标题、横竖屏、旁白声音、开头素材和 BGM 等项目要求。

动作：

1. 把用户原文原样保存为 SCRIPT_SOURCE.md，不在制作过程中顺手改剧情。
2. 只把明确的错字、错代词和转写错误列入项目纠错记录。
3. 用 PROJECT_SPEC.json 保存标题、章节、画布方向、旁白参数、开头素材和 BGM。
4. 从原文派生可朗读的 SCRIPT.md，但不改变故事视角、立场、情绪、人物动机和结局。

产物：原始文案、项目配置、可朗读脚本三份相互分离的文件。故事数据与构建器分开，换一篇故事时不需要改工具代码。

拒绝条件：找不到未改动的原文；纠错没有单独记录；横竖屏、声音和标题仍散落在脚本里。任一项存在，都不进入角色和旁白生产。

可参考：项目配置规范。

任务二：锁定人物身份和漫画世界

输入：项目脚本和角色关系。

动作：

1. 在 CHARACTERS.md 里写明主角不同年龄阶段的脸型、五官比例、发型、发色、识别点、体型、气质、常用服装和阶段变化。
2. 先生成一张主角身份锚点图，检查年龄、面部特征、发型、服装和漫画风格。
3. 锚点通过后，后续每个提示词都重复真正不可变的面部特征，并且只允许出现当前镜头需要的人物。
4. 不要求每张图都出现主角，但所有画面必须属于同一个漫画世界。

产物：CHARACTERS.md、通过检查的主角锚点图、明确的角色拒绝条件。

拒绝条件：锚点没有通过就批量生图；只靠角色名字维持一致性；镜头提示词把不该出现的配角一起带入画面。

可参考：视觉系统说明。

任务三：把三秒开头当成一个独立成品

输入：本期完整人生标题、候选人生快闪图、齿轮或棘轮音效、旁白和 BGM。

动作：

1. 先播放“今天体验的人生副本是……”这一类引导语。
2. 让一到两秒的齿轮音效与多种人生画面快闪同时发生。
3. 快闪结束后停在本期人生，画面保持，再读出完整标题。
4. 快闪图交替使用明显的 zoom-in 和 zoom-out，避免只是快速换幻灯片。
5. 中文标题由 HTML 渲染，不让生图模型直接写字。
6. 先单独压制十几秒开头预览；速度、音效、标题、音乐都通过后，再绑定到长片。

产物：一条独立、可人工审核的开头预览，以及它对应的版本记录。

拒绝条件：齿轮声和快闪错位；先念完标题再快闪；标题存在 AI 错字；长片仍引用旧开头。

可参考：开头系统说明。

任务四：让连续旁白、VTT 和语义字幕共享一条时间线

输入：确认后的 SCRIPT.md。

动作：

1. 开头引导语、完整标题可以单独生成，正文尽量使用一条连续 Edge TTS 音频。
2. 默认保持自然语速，不为了缩时长直接加速。
3. 发送 TTS 前，先把 Markdown 排版造成的断行重新连接，停顿由标点而不是换行决定。
4. 同时生成 VTT，用真实语音时间推导章节、镜头和字幕，不能音频完成后再平均分配图片时长。
5. 字幕先找原句标点和完整词组，再考虑单行长度。原作者的横屏参考范围是 8～18 个汉字，竖屏是 8～14 个汉字；短句可以更短，但不能制造没有意义的两三字短尾。
6. 去掉不需要显示的句末标点，字幕尽量一行、最多两行，并分别检查横屏和竖屏安全区。

产物：连续正文音轨、VTT、字幕文件和真实全局时间轴 STORYBOARD.json。

拒绝条件：旁白分段后音色或语气跳变；字幕留下无意义短尾；画面与字幕仍靠估算时间；横竖屏共用同一套坐标。

可参考：分镜与字幕规则和字幕语义审计脚本。

任务五：用真实语音决定镜头密度，再规划宫格和单图

输入：连续旁白、VTT、章节和场景变化。

动作：

1. 不按“每句话一张图”机械分镜，而在场景、时间、主导动作、人物关系、情绪强度、关键道具或现实与回忆切换时增加新画面。
2. 原作者把普通静态漫画镜头控制在约 4～8 秒；8～12 秒只留给情绪停顿或复杂细节；超过 16 秒默认先按缺图处理。
3. 对 8～12 分钟故事，作者给出的经验范围约为 70～110 张静态画面；14～15 分钟故事往往需要 125～165 张。它们是这套工作流的规划参考，不是所有项目的统一标准。
4. 低风险、同角色、同场景的连续镜头可以四格合并生成；高风险镜头必须单图。
5. 在 STORYBOARD_BASE.json 中记录语义分镜，再根据 VTT 生成最终 STORYBOARD.json。

产物：每个镜头都有开始时间、结束时间、场景目的和素材类型的分镜表。

拒绝条件：普通镜头长时间停留；图片数量与真实音频时长无关；没有标注宫格或单图；同一分镜被遗漏或重复覆盖。

可参考：镜头密度审计脚本。

任务六：并发生图，但把现实逻辑放在“好看”前面

输入：身份锚点、最终分镜表、宫格与单图计划。

动作：

1. 四格图必须面积相等、分隔线清楚、每格独立构图，且不含字幕、气泡、Logo 和水印；人物和格子顺序要与分镜一致。
2. 手部、双手接触、手机正反面、打字、抽烟、筷子、焊接、肢体重叠、身份关键镜头和重要情绪特写使用单图。
3. 锚点通过后，互不依赖的任务可以并发；原仓库兼容 Images API 的默认并发数是 5，上限 10。这个数字是仓库配置，不代表所有服务都适合照搬。
4. 为每个分镜建立素材映射，证明它恰好被一张最终素材覆盖。
5. 高风险图按全分辨率检查：每只手能追溯到手腕和前臂；没有重复掌形或多余指簇；手机屏幕、摄像头和按键方向合理；人物视线与屏幕方向一致；工具和手真实接触。
6. 遮挡严重到无法判断时直接拒绝。宫格里某一格失败，只把这一格改成单图重生，不靠裁切或运动模糊掩盖。

产物：最终镜头素材、素材映射、提示词和拒绝/重生记录。

拒绝条件：结构无法确认仍强行通过；用模糊遮盖多手或错误方向；没有素材覆盖证明；主角身份关键镜头仍使用拥挤宫格。

可参考：生图与拒绝规则和四格拆图脚本。

任务七：分别处理运动、混音和长片渲染

输入：最终镜头、VTT、字幕、旁白、开头音效和 BGM。

动作：

1. 静态图使用确定性的轻运动。仓库参考包括 zoom-in、zoom-out、轻微左右平移和情绪停留，连续镜头不要重复同一种运动。
2. 图片放在覆盖画布并隐藏溢出的容器中，运动内部图片，避免缩放或平移露出黑边。
3. 记忆碎片和强转折可以硬切，情绪连续段落再使用短淡化，不给所有镜头套同一种转场。
4. 旁白、齿轮音效、BGM 和画面分轨处理。BGM 默认保持恒定增益，不跟着每句话反复升降。
5. 先压制 15～20 秒混音预览。作者以低于旁白约 8～12 dB 为起点，每次调整 3～4 dB，再用听感确认；最终编码至少保留 3 dB True Peak 余量。
6. 长片渲染前检查磁盘。原工作流建议 1080p 的 8～12 分钟高质量视频至少预留约 12 GiB；空间不足时使用流式 FFmpeg 路径，而不是先把整条视频每一帧落盘。
7. 每次输出新版本文件名，不覆盖已经验收通过的 MP4。

产物：开头混音预览、完整时间线、版本化 MP4 和可回退的上一版成片。

拒绝条件：连续镜头运动完全相同；画面露黑边；BGM 忽大忽小或盖住人声；磁盘预检不过仍启动长片；新渲染覆盖旧成片。

可参考：样式系统、长片预检脚本和流式渲染脚本。

任务八：验收编码后的 MP4，再把返工变成规则

输入：准备交付的最终 MP4，而不是 HTML 预览或源图片。

动作：

1. 检查分辨率、帧率、总时长和总帧数。
2. 扫描黑帧、异常静音、综合响度和 True Peak。
3. 确认旁白、BGM 和齿轮音效都进入最终音轨。
4. 从最终 MP4 抽取开头、标题、正文、关键修正镜头和结尾，生成联系表人工复核。
5. 检查开头运动、字幕背景和安全区、高风险手机与手部镜头、章节转场、过长停留和最后一帧。
6. 把这次出现的新问题归入三类：固定规则、项目配置或人工判断。能确定复用的规则进入 Skill，项目特有内容留在配置，审美和现实判断继续由人负责。

产物：最终 MP4、QA 报告、联系表、拒绝/重生记录和下一版规则清单。

拒绝条件：自动脚本通过就直接交付；只检查浏览器预览；没有抽帧看实际编码画面；新问题只修成品却不记录规则归属。

可参考：渲染与 QA 说明、最终视频检查脚本和联系表脚本。

这次真实长片验证了什么

原作者报告的完整集成样本为：

| 项目 | 结果 | | --- | --- | | 成片 | 10 分 49 秒，1920×1080，30fps | | 总帧数 | 19,472 | | 静态漫画镜头 | 144 | | 生图任务 | 46 次，其中包含 2×2 宫格 | | 视觉拒绝并重生 | 2 次 | | API 传输失败 | 0 次 | | 黑帧事件 | 0 次 | | 异常静音事件 | 0 次 | | 综合响度 | -22.8 LUFS | | True Peak | -4.1 dBFS |

这组数据能说明仓库公开的方法跑过一条完整长片，但不能证明安装 Skill 后每个人都会得到相同质量，也不能据此推断成本下降、效率提升或跨环境稳定性。

两种使用方式：不安装也能执行，安装前先看清边界

方式一：先用“最小长视频项目任务卡”跑一个项目

不安装任何 Skill，也可以先把下面这张卡交给你的 Agent：

这张卡不是“一句话自动出片”。它的作用是把确认点前移，避免 Agent 一次生成完所有素材后才发现角色、时间线或画布方向从一开始就错了。

方式二：查看并评估开源 Skill

仓库提供可安装的 Agent Skill、横竖屏样式、项目规范、分镜、生图、渲染和 QA 脚本。本文没有亲自安装或复现，所以这里只提供一手资源入口，不把仓库说明改写成我的实测：

• hbg-life-simulation 仓库首页
• Agent Skill 主文件
• 项目配置规范
• 分镜与字幕规则
• 生图与拒绝规则
• 渲染与最终 QA
• 辅助脚本目录

仓库要求 Node.js、FFmpeg/FFprobe、Python 与 edge-tts、HyperFrames 和 ImageGen 能力。它不包含模型权重、API Key、用户故事、生成素材、BGM 或最终视频。第三方音乐、字体、图片和语音服务的许可仍由发布者确认。

我的理解：Skill 不是取消人工，而是安排人工出现的位置

我看完后最认同的不是“用更多工具”，而是作者最后把判断拆成了三层：

1. 固定规则：默认画布、自然语速、标题顺序、字幕安全区、镜头时长和最终 QA。这类判断可以写进 Skill，每次重复执行。
2. 项目配置：故事标题、角色、章节、横竖屏、BGM、快闪素材和旁白声音。它们随项目变化，但应该集中管理。
3. 人工判断：角色是否真的像同一个人，手和手机是否符合现实，音乐是否舒服，故事情绪是否成立。这些不能因为脚本通过就自动宣布完成。

所以，AI 生产力的分水岭并不是工具数量。更实际的判断是：第一次返工之后，下一次是否还会在同一个节点、用同一种方式重新出错。

做到什么算完成

• 原始文案、项目配置、朗读脚本和角色约束相互分离；
• 主角锚点与开头预览通过后，才进入批量生产；
• 旁白、镜头和字幕共享真实 VTT 时间；
• 分镜表标明镜头密度、宫格、单图和高风险检查；
• 每个分镜都有且只有一张最终素材；
• 最终检查对象是编码后的 MP4，并保留自动结果和人工抽帧复核；
• 新的返工问题已归入固定规则、项目配置或人工判断；
• 没有把作者的一次样本外推为普遍效率或效果结论。

来源与使用边界

本文的制作经历、流程与验证数据来自蛋黄堡的 X 制作复盘和 hbg-life-simulation 开源仓库。本文没有复制原文十五节结构，而是按入行之路读者的实际执行顺序重组为八个任务，并补上输入、产物、拒绝条件和资源入口。

仓库代码采用 MIT License；这项许可适用于仓库中的代码，不应扩大解释为 X 原文可以全文转载。本文没有亲自安装或复现仓库，也不承诺安装后可以获得相同成片。