我用 Codex + ImageGen + HyperFrames，做了一条十分钟的漫画「人生副本」视频

囡囡外婆

我前后调整了很多轮，才把这套流程真正跑顺。

最开始我以为，“人生副本”视频无非是把一篇长文案配上旁白，再放几十张漫画图，让图片缓慢放大、缩小就行。

实际做起来，问题远比想象中多：

• 开头快闪不够快，齿轮音效和画面错位
• 旁白已经讲到下一句，画面几秒后才跟上
• 同一个主角换一张图就像换了一个人
• 字幕把一句完整的话切碎，最后只剩两三个字
• BGM 一会儿太小，一会儿又盖住人声
• 手机正反面画错，手指融合，多出一只手
• 竖屏调好的字幕和裁切参数，放回横屏后全部失效
• 十分钟视频渲染到一半，磁盘空间和编码时间开始失控
  

后来我没有继续手工修某一条视频，而是把每次踩坑得到的规则，逐步固化成一个可复用的 Agent Skill：hbg-life-simulation。

它不是一个固定的视频模板，也不是“一句话自动出片”的黑盒。它更像一套本地视频生产流水线：Codex 负责理解文案、规划分镜和调度工具，ImageGen 负责漫画素材，Edge TTS 负责连续旁白，HyperFrames 负责时间线和镜头运动，FFmpeg 负责最终压制与验收。

这篇文章把完整工作流拆开讲清楚。

零、这套人生副本视频用了哪些工具

工具	在流程中的作用	是否必需
Codex	保存文案、拆章节、设计分镜、生成提示词、执行脚本、检查结果	核心控制台
ImageGen	生成统一漫画 IP、2×2 宫格和高风险单图	可换兼容 Images API
Edge TTS	生成自然语速中文旁白和 VTT 时间轴	可换其他能输出时间轴的 TTS
HyperFrames	组装快闪开头、图片运动、章节、字幕和多轨音频	核心视频引擎
Node.js	生成脚本、分镜、字幕、项目配置和视频组合	推荐
FFmpeg / ffprobe	宫格拆图、尺寸归一、混音、长片压制和最终 QA	推荐
Python	调用 Edge TTS，以及处理部分媒体辅助任务	推荐

整条流水线可以概括成：

长篇中文文案→ 保存原文并做最小纠错→ 锁定主角漫画 IP→ 生成连续旁白和 VTT→ 按真实语音时间设计分镜→ 并发生成宫格与单图→ 制作 HBG 快闪开头→ 添加 zoom / pan 和同步字幕→ 混合旁白、齿轮音效和 BGM→ 渲染完整 MP4→ 对编码后的成片做最终检查

一、真正困难的不是生图，而是让十分钟内容始终一致



短视频只出现三五张图时，人物偶尔有一点变化不明显。

但人生副本通常是一篇几千字的第二人称故事。主角会从童年走到成年，从白天走到夜晚，从工厂、学校、出租屋走到办公室。几十甚至上百张画面放在一起，脸型、发型、年龄、衣服和人物关系只要漂移几次，观众马上会出戏。

所以我不会拿到文案后直接批量生图，而是先建立 CHARACTERS.md，把主角的不可变特征写清楚：

年龄阶段脸型与五官比例发型、发色和识别点常用服装与阶段变化体型和气质与配角的关系

然后先生成一张身份锚点图。锚点没有通过，后面的图片就不开始生成。

人物名字本身不能锁定 IP。后续每一个提示词都要重复关键面部特征，并且只描述当前镜头允许出现的人物。否则模型很容易把角色表里的所有配角一起塞进画面。

不是每张图都必须出现主角，但每张图必须属于同一个漫画世界。

二、原文必须先冻结，不能一边做视频一边改故事



每个项目先保留一份完全不改动的 SCRIPT_SOURCE.md，再用 PROJECT_SPEC.json 记录标题、章节、明确的转写纠错、画布方向、旁白参数、开头素材和 BGM。

只修正能够确定的错别字、错代词和转写错误，不擅自改变故事立场、情绪、结局或人物动机。

项目中真正会被工具读取的是：

SCRIPT_SOURCE.md      原始文案PROJECT_SPEC.json     项目配置和纠错规则SCRIPT.md             可朗读的章节稿CHARACTERS.md         人物身份约束STORYBOARD_BASE.json  语义分镜STORYBOARD.json       对齐语音后的最终时间线HBG_STYLE.json        横竖屏、字幕、开头和运动参数

以前把故事标题、章节和镜头直接写死在脚本里，换一篇文案就要重新改代码。现在故事数据和构建器分开，同一套脚本可以处理不同人生。

三、开头不是随便快闪几张图，而是一段固定的叙事顺序



这类视频最重要的识别点，是开头三秒左右的“抽取人生”。

正确顺序是：

旁白：今天体验的人生副本是……→ 立刻播放一到两秒齿轮 / 棘轮音效→ 多种人生画面高速快闪→ 停在本期选中的人生→ 画面保持→ 旁白读出完整的人生剧本标题→ 正文开始

齿轮音效和快闪必须同时发生，不能旁白说完后空等，也不能先把剧本名字念完再快闪。

快闪图不只切换，还要交替使用明显的 zoom-in 和 zoom-out。否则虽然图片换得快，视觉上依然像普通幻灯片。

标题由 HTML 渲染，不让生图模型直接写中文。这样不会出现错字，也方便横屏和竖屏分别调整安全区。

开头会先单独压制一条十几秒预览。只有画面速度、齿轮音效、标题和 BGM 都通过后，才把这条经过确认的开头绑定进完整视频，避免长片渲染时误用旧版本。










四、正文旁白为什么要尽量一次生












我一开始也尝试过把正文拆成很多段语音。好处是局部修改方便，但长故事很容易出现语气不连续、段落间隔不自然、音色轻微变化，以及画面时间不断累积偏移

现在的默认方案是：

• 开头引导语单独一段
• 选中人生的完整标题单独一段
• 正文使用一条连续 Edge TTS 音频
• 默认自然语速 +0%，不额外加速
  

Edge TTS 同时输出 VTT。这个 VTT 不是字幕附件，而是整个视频的主时间轴。

章节开始时间、镜头开始时间和字幕时间都从真实语音推导，不能在音频生成之后，再把图片平均分配到总时长里。那正是“声音已经讲完，画面几秒后才出现”的主要原因。

还有一个很容易忽略的问题：Markdown 里的换行只是排版，不应该自动变成语音停顿。发送给 TTS 前，要先把被换行拆开的完整句子重新连接，依靠标点决定呼吸。

五、字幕不是按字数硬切，而是按中文语义切



第一批字幕最大的问题，是一句话结尾经常孤零零留下“起来”“清楚”“一步”这种两三个字。

这不是字体大小问题，而是分句算法只看字符数，没有看中文语义。

现在字幕会优先寻找：

• 原句标点边界
• 完整短语和词语边界
• 能自然朗读的语义片段
• 最后才考虑单行长度
  

横屏通常控制在 8～18 个汉字，竖屏通常控制在 8～14 个汉字。完整短句可以更短，但不能因为切分制造一段没有意义的短尾。

句末标点会去掉，因为声音本身已经提供停顿。字幕尽量一行，最多两行。

横屏和竖屏使用不同的字幕安全区。默认项目是 1920×1080 横屏；只有用户明确要求时才切换到 1080×1920 竖屏。不能因为视频准备发短视频平台，就自动沿用上一个竖屏项目的坐标。

六、图片数量必须由真实语音时长决定



一张图即使有 zoom，也不能在普通叙事段落里停留二三十秒。

这套流程把普通静态漫画镜头控制在 4～8 秒；8～12 秒只留给情绪停顿或需要阅读细节的复杂画面；超过 16 秒，默认视为缺图，而不是“慢镜头风格”。

分镜不是每句话机械配一张图，而是在这些变化发生时增加新画面：

• 场景或时间变化
• 主导动作变化
• 人物关系和权力位置变化
• 情绪强度变化
• 关键道具出现
• 现实与回忆切换
  

对 8～12 分钟的故事，通常需要大约 70～110 张静态画面。更长的 14～15 分钟故事，往往需要 125～165 张。

图片太少时，zoom 只能暴露问题，不能解决问题。

七、2×2 宫格和单图必须混合使用



如果每一个镜头都单独调用一次生图，成本和等待时间都会很高。所以低风险、同角色、同场景的四个连续镜头，可以先生成一张严格的 2×2 宫格，再切成四张独立图片。

宫格必须满足：

四格面积相等分隔线清晰统一每格都是独立构图不包含字幕、气泡、Logo 和水印人物和格子顺序与分镜表一致

但以下画面必须单独生成：

• 手部特写和双手接触
• 手机正反面与看屏幕动作
• 打字、抽烟、筷子和焊接
• 肢体重叠较多的动作
• 主角身份关键镜头
• 重要情绪特写
  

主角锚点确认后，互不依赖的宫格和单图可以并发生成。兼容 Images API 的默认并发数是 5，上限控制在 10。一次宫格或一次单图算一个生图任务。

生成结束后，还要建立 SHEET_MAP.json，证明每一个分镜恰好被一张素材覆盖，既没有遗漏，也没有重复。










八、图片好看不等于可以进入视频












这个项目里最典型的返工，不是画风不好，而是现实逻辑错误。

例如手机拿反了，屏幕朝外但人物却在看背面；手腕下面多出一团手指；两个角色握手时出现第三只手；筷子穿过手掌；烟和手指没有接触；人物看向手机，但屏幕方向和视线不一致。

所以现在每张高风险图都要做全分辨率检查：

数清每个人的手臂、手掌和手指每一只手都能追溯到一个手腕和前臂重叠处不能出现多余掌形和重复指簇手机屏幕、摄像头和按键方向合理视线与屏幕方向一致工具和手真正发生接触

如果遮挡严重到无法确认结构是否正确，就直接判定不通过，不能用“也许藏在后面”替模型解释。

2×2 宫格里只要某一格失败，那一格就改为单图重生，不通过裁切或运动模糊掩盖问题。

XIMGPH_4

九、静态漫画怎么动，才不会像 PPT



人生副本不是角色骨骼动画，主体仍然是静态漫画。但每张图会使用确定性的轻运动：

zoom in：scale 1.00 → 1.10～1.13zoom out：scale 1.12 → 1.00pan left / right：保持轻微放大，横移不超过画面宽度 4%emotional hold：scale 1.00 → 1.025

zoom-in、zoom-out、pan-left 和 pan-right 交替出现，避免连续几张图使用完全相同的运动。

图片放在一个覆盖全画布、隐藏溢出的容器里，运动的是内部图片，而不是整个镜头层。这样缩放和平移过程中不会露出黑边。

记忆碎片和强转折可以使用硬切，情绪连续的段落才使用很短的淡化。不能所有镜头都套一个统一转场。

十、BGM 要听得见，但不能忽大忽小



最初的 BGM 混音有两个极端：要么几乎听不见，要么为了突出某句话反复自动压低和抬高，听起来像音量坏了。

现在旁白、齿轮音效、BGM 和画面使用独立轨道。BGM 默认保持恒定增益，不跟着每句话做 ducking。

先压制 15～20 秒的开头混音预览，以比旁白低约 8～12 dB 作为起点，再每次调整 3～4 dB，用耳朵确认。最终编码保留至少 3 dB 的 True Peak 余量。

开头齿轮音效可以短而明显，正文 BGM 则需要稳定存在。观众应该能感觉到音乐，但不需要费力分辨旁白。

十一、十分钟长视频不能只点一次“渲染”然后等



长片和三十秒测试片完全不是一回事。

如果视频有上万帧，直接把整条时间线全部捕获到磁盘，可能在编码前就占满临时空间。因此渲染前会先检查磁盘，1080p 的 8～12 分钟高质量视频通常预留至少 12 GiB。

常规路径使用 HyperFrames 分块编码；macOS 上优先使用 VideoToolbox。空间不足时，会切换到流式 FFmpeg 路径：每个静态镜头先生成一个带 zoom / pan 的短片段，再拼接、压字幕和混音，而不是把整条视频的每一帧全部落盘。

每次输出都使用新的版本文件名，不覆盖上一条已经验证通过的 MP4。

十二、浏览器里看起来正常，不代表最终视频正常



最终交付对象是编码后的 MP4，不是 HTML 预览，也不是源图片。

成片完成后会检查：

• 分辨率、帧率、总时长和总帧数
• 是否存在黑帧和异常静音
• 旁白、BGM 与齿轮音效是否都进入音轨
• 综合响度和 True Peak
• 开头 zoom 是否真的出现在编码视频中
• 字幕背景框是否可见并处于安全区
• 高风险手机、手部和工具镜头
• 章节转场、长停留镜头和最后一帧
  

同时从最终 MP4 抽取开头、标题、正文、关键修正镜头和结尾，生成联系表人工复查。

自动检查通过不等于一定好看，但它可以阻止很多“文件成功导出，内容其实坏了”的情况。

XIMGPH_5

十三、真实长片跑出来的数据



这套流程已经在一条 10 分 49 秒的横屏中文人生故事上完成完整集成验证：

指标	结果
画布	1920×1080
帧率	30fps
总帧数	19472
静态漫画分镜	144
API 生图成功任务	46
API 传输失败	0
视觉拒绝并重生	2
黑帧事件	0
异常静音事件	0
综合响度	-22.8 LUFS
True Peak	-4.1 dBFS

这里的 46 次生图任务不等于只有 46 张画面，其中一部分是 2×2 宫格，拆分后共同覆盖了 144 个静态漫画镜头。

十四、最后把所有踩坑固化成 Skill



如果每做一篇故事，都重新判断语音怎么切、字幕放哪里、图片要多少张、哪些画面必须单图、BGM 多大声，下一次仍然会重复踩坑。

所以我把这些判断拆成三类：

• 固定规则：默认横屏、自然语速、完整标题开头、字幕安全区、镜头时长和最终 QA。
• 项目配置：故事标题、角色、章节、横竖屏、BGM、快闪人生和旁白声音。
• 人工判断：主角锚点是否一致、画面是否符合现实、音乐是否舒服、故事情绪是否成立。
  

最终形成了 hbg-life-simulation：一个可以安装进 Codex 或 Claude Code 的开源 Agent Skill。

GitHub：

https://github.com/Mr-funny/hbg-life-simulation


安装到 Codex：

curl -fsSL https://raw.githubusercontent.com/Mr-funny/hbg-life-simulation/main/install.sh
| sh

安装后可以直接说：

使用 $hbg-life-simulation
处理下面的人生故事。默认横屏，先保存原文并锁定主角 IP，再生成连续 Edge TTS、同步短字幕和密集漫画分镜，使用 HBG 快闪开头、交替 zoom/pan、恒定 BGM，最后输出并检查完整 MP4。

十五、整条工作流总结

冻结原始文案→ 建立项目配置和人物身份→ 生成并确认主角锚点→ 生成连续 Edge TTS 和 VTT→ 按真实语音设计高密度分镜→ 规划 2×2 宫格与高风险单图→ 并发生图、拆图和现实检查→ 制作快闪人生开头→ 添加 zoom / pan、章节和同步字幕→ 混合旁白、齿轮音效和恒定 BGM→ HyperFrames 或流式 FFmpeg 渲染→ 检查最终编码 MP4

做完以后我最大的感受是：

人生副本视频真正难的，不是让一张图片动起来，也不是一次生成很多漫画图。

真正困难的是，让几千字文案、十分钟旁白、上百个镜头、同一个角色、同步字幕和背景音乐，在同一条时间线上始终保持一致。

而 Skill 的价值，就是把“这次终于改对了”变成“下一次默认不会再错”。