最近看了蛋黄堡对一条十分钟漫画“人生副本”视频的制作复盘。
这条视频最后做到了 10 分 49 秒、144 个静态漫画镜头。原文真正值得保存的，不只是人物锚点、VTT 和最终 MP4 三四个概念，而是一条从冻结文案、建立角色、生成旁白、规划分镜、生图、字幕、运动、混音、渲染到成片质检的完整生产链。
作者公开的开源仓库已经把这条链路拆成 Skill、项目规范、参考文档和辅助脚本。下面不照搬原文十五节结构，而是把核心内容重组为八个可执行任务。每个任务都回答四个问题：要准备什么、具体做什么、留下什么产物、什么情况不能继续。
本文不是我的制作实测。所有制作经历和验证数据均来自蛋黄堡的公开复盘与
hbg-life-simulation仓库。
先看清它解决的到底是什么
短片里，一张图不够好看，重新生成一次可能就解决了。长片的问题不是某一张图，而是同一个角色、同一条旁白和同一套视觉规则要在上百个镜头里持续成立。
原文列出的返工并不抽象：快闪画面与齿轮音效错位；主角换一张图就像换了一个人；声音已经进入下一句，画面还停在上一幕；字幕结尾只剩两三个字；BGM 忽大忽小；手机正反面、手指和工具接触不符合现实；竖屏参数污染横屏项目；长片渲染到一半，磁盘和编码时间开始失控。
这些问题单独看都能手修。麻烦在于，一条十分钟视频里有几千字文案、连续旁白、上百个镜头、字幕、音效和音乐。每个环节都用自己的时间或参数，修完一处，别处又可能漂移。
原作者最终形成的工具分工是：Codex 处理文案、分镜与调度；ImageGen 生成漫画素材；Edge TTS 输出连续旁白和 VTT；HyperFrames 组织时间线、镜头运动和多轨内容；FFmpeg 负责长片压制与编码后检查。工具只是执行者，真正让它们协作的是下面八个任务和对应门禁。
任务一：先冻结原始文案，再建立项目配置
输入：一篇已经确认的中文人生故事，以及标题、横竖屏、旁白声音、开头素材和 BGM 等项目要求。
动作：
- 把用户原文原样保存为
SCRIPT_SOURCE.md，不在制作过程中顺手改剧情。 - 只把明确的错字、错代词和转写错误列入项目纠错记录。
- 用
PROJECT_SPEC.json保存标题、章节、画布方向、旁白参数、开头素材和 BGM。 - 从原文派生可朗读的
SCRIPT.md，但不改变故事视角、立场、情绪、人物动机和结局。
产物：原始文案、项目配置、可朗读脚本三份相互分离的文件。故事数据与构建器分开，换一篇故事时不需要改工具代码。
拒绝条件：找不到未改动的原文；纠错没有单独记录；横竖屏、声音和标题仍散落在脚本里。任一项存在，都不进入角色和旁白生产。
可参考：项目配置规范。
任务二：锁定人物身份和漫画世界
输入：项目脚本和角色关系。
动作：
- 在
CHARACTERS.md里写明主角不同年龄阶段的脸型、五官比例、发型、发色、识别点、体型、气质、常用服装和阶段变化。 - 先生成一张主角身份锚点图，检查年龄、面部特征、发型、服装和漫画风格。
- 锚点通过后，后续每个提示词都重复真正不可变的面部特征，并且只允许出现当前镜头需要的人物。
- 不要求每张图都出现主角，但所有画面必须属于同一个漫画世界。
产物：CHARACTERS.md、通过检查的主角锚点图、明确的角色拒绝条件。
拒绝条件：锚点没有通过就批量生图；只靠角色名字维持一致性；镜头提示词把不该出现的配角一起带入画面。
可参考：视觉系统说明。
任务三：把三秒开头当成一个独立成品
输入：本期完整人生标题、候选人生快闪图、齿轮或棘轮音效、旁白和 BGM。
动作：
- 先播放“今天体验的人生副本是……”这一类引导语。
- 让一到两秒的齿轮音效与多种人生画面快闪同时发生。
- 快闪结束后停在本期人生，画面保持，再读出完整标题。
- 快闪图交替使用明显的 zoom-in 和 zoom-out，避免只是快速换幻灯片。
- 中文标题由 HTML 渲染，不让生图模型直接写字。
- 先单独压制十几秒开头预览；速度、音效、标题、音乐都通过后，再绑定到长片。
产物：一条独立、可人工审核的开头预览，以及它对应的版本记录。
拒绝条件：齿轮声和快闪错位；先念完标题再快闪；标题存在 AI 错字；长片仍引用旧开头。
可参考：开头系统说明。
任务四：让连续旁白、VTT 和语义字幕共享一条时间线
输入：确认后的 SCRIPT.md。
动作：
- 开头引导语、完整标题可以单独生成，正文尽量使用一条连续 Edge TTS 音频。
- 默认保持自然语速，不为了缩时长直接加速。
- 发送 TTS 前，先把 Markdown 排版造成的断行重新连接，停顿由标点而不是换行决定。
- 同时生成 VTT，用真实语音时间推导章节、镜头和字幕，不能音频完成后再平均分配图片时长。
- 字幕先找原句标点和完整词组，再考虑单行长度。原作者的横屏参考范围是 8～18 个汉字，竖屏是 8～14 个汉字；短句可以更短，但不能制造没有意义的两三字短尾。
- 去掉不需要显示的句末标点，字幕尽量一行、最多两行，并分别检查横屏和竖屏安全区。
产物：连续正文音轨、VTT、字幕文件和真实全局时间轴 STORYBOARD.json。
拒绝条件：旁白分段后音色或语气跳变；字幕留下无意义短尾；画面与字幕仍靠估算时间；横竖屏共用同一套坐标。
任务五：用真实语音决定镜头密度，再规划宫格和单图
输入：连续旁白、VTT、章节和场景变化。
动作：
- 不按“每句话一张图”机械分镜，而在场景、时间、主导动作、人物关系、情绪强度、关键道具或现实与回忆切换时增加新画面。
- 原作者把普通静态漫画镜头控制在约 4～8 秒；8～12 秒只留给情绪停顿或复杂细节；超过 16 秒默认先按缺图处理。
- 对 8～12 分钟故事，作者给出的经验范围约为 70～110 张静态画面；14～15 分钟故事往往需要 125～165 张。它们是这套工作流的规划参考，不是所有项目的统一标准。
- 低风险、同角色、同场景的连续镜头可以四格合并生成；高风险镜头必须单图。
- 在
STORYBOARD_BASE.json中记录语义分镜，再根据 VTT 生成最终STORYBOARD.json。
产物：每个镜头都有开始时间、结束时间、场景目的和素材类型的分镜表。
拒绝条件：普通镜头长时间停留；图片数量与真实音频时长无关；没有标注宫格或单图；同一分镜被遗漏或重复覆盖。
可参考：镜头密度审计脚本。
任务六：并发生图，但把现实逻辑放在“好看”前面
输入：身份锚点、最终分镜表、宫格与单图计划。
动作：
- 四格图必须面积相等、分隔线清楚、每格独立构图，且不含字幕、气泡、Logo 和水印；人物和格子顺序要与分镜一致。
- 手部、双手接触、手机正反面、打字、抽烟、筷子、焊接、肢体重叠、身份关键镜头和重要情绪特写使用单图。
- 锚点通过后，互不依赖的任务可以并发；原仓库兼容 Images API 的默认并发数是 5，上限 10。这个数字是仓库配置，不代表所有服务都适合照搬。
- 为每个分镜建立素材映射，证明它恰好被一张最终素材覆盖。
- 高风险图按全分辨率检查：每只手能追溯到手腕和前臂；没有重复掌形或多余指簇；手机屏幕、摄像头和按键方向合理；人物视线与屏幕方向一致；工具和手真实接触。
- 遮挡严重到无法判断时直接拒绝。宫格里某一格失败，只把这一格改成单图重生，不靠裁切或运动模糊掩盖。
产物：最终镜头素材、素材映射、提示词和拒绝/重生记录。
拒绝条件：结构无法确认仍强行通过；用模糊遮盖多手或错误方向；没有素材覆盖证明；主角身份关键镜头仍使用拥挤宫格。
任务七：分别处理运动、混音和长片渲染
输入：最终镜头、VTT、字幕、旁白、开头音效和 BGM。
动作：
- 静态图使用确定性的轻运动。仓库参考包括 zoom-in、zoom-out、轻微左右平移和情绪停留，连续镜头不要重复同一种运动。
- 图片放在覆盖画布并隐藏溢出的容器中，运动内部图片，避免缩放或平移露出黑边。
- 记忆碎片和强转折可以硬切，情绪连续段落再使用短淡化，不给所有镜头套同一种转场。
- 旁白、齿轮音效、BGM 和画面分轨处理。BGM 默认保持恒定增益，不跟着每句话反复升降。
- 先压制 15～20 秒混音预览。作者以低于旁白约 8～12 dB 为起点，每次调整 3～4 dB，再用听感确认；最终编码至少保留 3 dB True Peak 余量。
- 长片渲染前检查磁盘。原工作流建议 1080p 的 8～12 分钟高质量视频至少预留约 12 GiB；空间不足时使用流式 FFmpeg 路径，而不是先把整条视频每一帧落盘。
- 每次输出新版本文件名，不覆盖已经验收通过的 MP4。
产物：开头混音预览、完整时间线、版本化 MP4 和可回退的上一版成片。
拒绝条件：连续镜头运动完全相同；画面露黑边；BGM 忽大忽小或盖住人声；磁盘预检不过仍启动长片；新渲染覆盖旧成片。
任务八：验收编码后的 MP4，再把返工变成规则
输入：准备交付的最终 MP4，而不是 HTML 预览或源图片。
动作：
- 检查分辨率、帧率、总时长和总帧数。
- 扫描黑帧、异常静音、综合响度和 True Peak。
- 确认旁白、BGM 和齿轮音效都进入最终音轨。
- 从最终 MP4 抽取开头、标题、正文、关键修正镜头和结尾，生成联系表人工复核。
- 检查开头运动、字幕背景和安全区、高风险手机与手部镜头、章节转场、过长停留和最后一帧。
- 把这次出现的新问题归入三类：固定规则、项目配置或人工判断。能确定复用的规则进入 Skill，项目特有内容留在配置，审美和现实判断继续由人负责。
产物：最终 MP4、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：
请把这篇中文人生故事整理成一个“先规划、后生成”的长视频项目。
1. 原文单独冻结，只记录明确纠错，不改变故事立场和结局。
2. 先输出项目配置、角色身份锚点和真实旁白方案，等待我确认。
3. 旁白生成后，以 VTT 规划字幕和镜头，不平均分配画面时长。
4. 标记普通镜头、2×2 宫格和高风险单图；写清每类拒绝条件。
5. 生图前先提交开头预览、镜头密度和素材覆盖计划。
6. 最终验收对象必须是编码后的 MP4，并输出黑帧、静音、响度、字幕安全区、高风险镜头和最后一帧检查结果。
任何阶段没有通过，不进入下一阶段；不要把“已生成文件”写成“已通过验收”。
这张卡不是“一句话自动出片”。它的作用是把确认点前移，避免 Agent 一次生成完所有素材后才发现角色、时间线或画布方向从一开始就错了。
方式二：查看并评估开源 Skill
仓库提供可安装的 Agent Skill、横竖屏样式、项目规范、分镜、生图、渲染和 QA 脚本。本文没有亲自安装或复现，所以这里只提供一手资源入口，不把仓库说明改写成我的实测：
仓库要求 Node.js、FFmpeg/FFprobe、Python 与 edge-tts、HyperFrames 和 ImageGen 能力。它不包含模型权重、API Key、用户故事、生成素材、BGM 或最终视频。第三方音乐、字体、图片和语音服务的许可仍由发布者确认。
我的理解：Skill 不是取消人工，而是安排人工出现的位置
我看完后最认同的不是“用更多工具”，而是作者最后把判断拆成了三层：
- 固定规则：默认画布、自然语速、标题顺序、字幕安全区、镜头时长和最终 QA。这类判断可以写进 Skill，每次重复执行。
- 项目配置：故事标题、角色、章节、横竖屏、BGM、快闪素材和旁白声音。它们随项目变化，但应该集中管理。
- 人工判断：角色是否真的像同一个人，手和手机是否符合现实，音乐是否舒服，故事情绪是否成立。这些不能因为脚本通过就自动宣布完成。
所以，AI 生产力的分水岭并不是工具数量。更实际的判断是：第一次返工之后，下一次是否还会在同一个节点、用同一种方式重新出错。
做到什么算完成
- 原始文案、项目配置、朗读脚本和角色约束相互分离；
- 主角锚点与开头预览通过后，才进入批量生产；
- 旁白、镜头和字幕共享真实 VTT 时间；
- 分镜表标明镜头密度、宫格、单图和高风险检查；
- 每个分镜都有且只有一张最终素材；
- 最终检查对象是编码后的 MP4，并保留自动结果和人工抽帧复核；
- 新的返工问题已归入固定规则、项目配置或人工判断；
- 没有把作者的一次样本外推为普遍效率或效果结论。
来源与使用边界
本文的制作经历、流程与验证数据来自蛋黄堡的 X 制作复盘和 hbg-life-simulation 开源仓库。本文没有复制原文十五节结构，而是按入行之路读者的实际执行顺序重组为八个任务，并补上输入、产物、拒绝条件和资源入口。
仓库代码采用 MIT License；这项许可适用于仓库中的代码，不应扩大解释为 X 原文可以全文转载。本文没有亲自安装或复现仓库，也不承诺安装后可以获得相同成片。