Codex + ImageGen + HyperFrames 热门人生副本喂饭教程

人生副本视频可以说是短视频里面比较火的一个类别，不需要真人出境，也不需要多高的剪辑教程，只要把下面的教程的流程跑通，就可以大批量复制。而且也不需去充值既梦成本。

人生副本视频需要工具

工具	在流程中的作用	是否必需
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 前，要先把被换行拆开的完整句子重新连接，依靠标点决定呼吸。

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

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

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

现在字幕会优先寻找：

1、原句标点边界

2、完整短语和词语边界

3、能自然朗读的语义片段

4、最后才考虑单行长度

横屏通常控制在 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 宫格里只要某一格失败，那一格就改为单图重生，不通过裁切或运动模糊掩盖问题。

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

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

zoom in：scale 1.00 → 1.10～1.13
zoom out：scale 1.12 → 1.00
pan 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 抽取开头、标题、正文、关键修正镜头和结尾，生成联系表人工复查。

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

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

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

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