用 Codex 做一条完整的 AI 口播视频：从访谈素材到竖屏成片

这次，我把 Mel Robbins 对 Allie Miller 的一段访谈，整理成介绍六种 AI 用法的中文口播，再配上原访谈画面，做成一条 9:16、约 1 分 44 秒的视频。

制作过程中，文稿、配音、下载素材、排版和合成都交给 Codex 操作本地工具。我负责提出要求、看效果，以及指出需要调整的地方。

成片并不是一次生成就完成的。先做了短预览，再扩成完整版；后来又调整语速，修复 32 秒附近的配音节奏，把整段字幕拆成短句，并给重点词加颜色、让字号适当变化。

这篇文章记录这条视频实际走过的流程。这里的下载与视频处理使用本地脚本和 FFmpeg，配音使用 VoxCPM2；没有把没有执行过的步骤写成 Cloudl 的功能。

图中是同一条成片的不同时刻。口播字幕每次显示一个短句，重点词使用黄色或青色，统一黑色细描边。

先确定成片长什么样

一开始就把画面结构说清楚，后面会少很多反复调整。这条视频最终采用下面的布局：

这些是本次视频的参数，可以作为起点，不必每条都照搬。比如，底部留白先在预览里用了 180 像素，后来觉得还不够，完整版增加到了 290 像素。

标题和口播字幕要分开处理。标题固定在上方，观众随时能知道视频在讲什么；字幕跟随口播出现，帮助理解当前这句话。两者不要互相遮挡。

第一步：先把访谈整理成能说出口的稿子

原视频是 Mel Robbins 对 Allie Miller 的访谈。这次从中整理了六类用法：让 AI 采访自己、挑文稿的问题、模拟难开口的对话、看着现场提供帮助、制作小工具，以及练习换角度思考。

写稿时，每个用法都配一个具体情境。例如，不只说“让 AI 帮你写东西”，而是说：你想做视频，但只有一句模糊的观点，可以让它一次问一个问题，把经历和想法问出来，再整理成提纲。

口播里还要区分访谈原有案例和自己的应用示例。后来补充的“做一个练口播的小网页”，就应该作为延伸用法来讲，不能让观众误以为是嘉宾的原话。

介绍人物时，也不用堆满履历。保留一个与主题有关、能核验的数据就够了。粉丝数、下载量这类数字，要记录来源和核验日期；标题和正文如果分别改过，还要检查是否出现“近两百万”和“两百多万”这样的口径差异。本次文件里就出现过这个差异，正式发布前仍应统一。

最后，读一遍稿子。书面表达里能理解的句子，念出来未必自然。例如下面这句，拆开之后会更顺：

关于这件事，你先问我。一次只问一个问题，帮我把思路理清楚。

原计划是做两三分钟，实际配音应用 1.2 倍速后，成片约 104 秒。如果时长是硬要求，应在配音完成后重新测量，再决定是否补充内容；不能只凭字数认为一定够两分钟。

第二步：先做 10～30 秒预览

预览的作用，是尽早看见排版和声音放在一起是什么样。

这次先从原视频前 20 分钟挑了两段互不连续的 15 秒片段，避开开头 10 秒，分别是 02:00–02:15 和 15:00–15:15。两段都移除了原声，用来验证竖屏画面。

预览至少要能回答这些问题：标题是否太挤，横屏画面裁成竖屏后人物是否还合适，字幕在手机尺寸下是否能读清，黑色留白是否过多，水印是否抢眼。

这次允许访谈画面作为氛围素材，不要求每一镜都对应当前口播，因此下载时不需要逐分钟看完整段访谈。理解内容与挑选背景片段是两项工作；如果做的是教程操作、产品演示或论据展示，就需要重新按内容选择画面。

预览确认之后，再下载更多素材、生成完整配音。这样一旦要移动视频位置或改标题大小，不必反复重做整片。

第三步：下载足够多的片段，并记录来源时间

两段素材能支撑短预览，用来铺满一分多钟的完整版，就容易让观众看见相同动作反复出现。

这次又下载了 16 段不同的 15 秒素材，加上原有两段，共有 18 段可用。它们都位于原视频前 20 分钟，并且避开了最初 10 秒。后来排除了三段带大面积英文图文的画面，最终使用 15 段不同素材，每段只出现一次。

下载和使用的长度不必相同。保留 15 秒原片段，实际成片中每段使用约 6.9 秒，给剪辑留出余量。

处理一个已经取得的本地源视频，可以用下面这样的命令截取片段：

ffmpeg -ss 120 -i source.mp4 -t 15 \
  -an -c:v libx264 -preset fast -crf 20 \
  -movflags +faststart source_interview_0120.mp4

这里 -ss 120 表示从第 120 秒开始，-t 15 表示截取 15 秒，-an 表示不要音轨。示例中的 source.mp4 要替换为实际文件。

本次下载脚本读取的是已解析的媒体地址，再由 FFmpeg 截取所需区间。YouTube 页面链接与可读取的视频流地址不同，不能直接把页面链接填进这个示例就认为一定能下载。远程地址也可能过期，失败后需要检查地址是否仍有效。

每段素材都记录原视频地址、开始时间、结束时间和本地文件名。下载完成后检查时长、分辨率、能否解码，以及是否确实没有音轨。临时文件检查通过后，再改成正式文件名，避免把未下载完整的文件当成素材。

第四步：用本地声音模型生成口播

配音使用已安装的 VoxCPM2，通过 Mac 的 MPS 运行，采用 float32、10 步推理，关闭编译和自动重试，并使用本地模型离线生成。

声音参考使用自己的已有录音，取其中第 25–37 秒。语气要求是自然的视频口播：像面对镜头聊天，吐字清楚，有短停顿和重点，句尾干脆，避免刻意压低声音或夸张表演。

这里需要把“声音是谁的”和“怎么说这段话”分开考虑。参考录音用于保留音色辨识度，节奏则根据新稿子的含义重新组织。

文稿里的英文人名，在送入配音模型前做了中文读音映射，例如把 Mel Robbins 转成“梅尔·罗宾斯”。画面字幕仍保留英文原名。这能让配音输入更明确，也方便单独调整发音。

生成后再统一应用 1.2 倍速，并处理响度。最后交付的音频为 AAC/M4A、48 kHz、256 kbps；内部 WAV 留作后续修改的缓存。

32 秒附近的节奏问题：分段太碎

这次一个很具体的问题，出现在下面这组连续问句：

把稿子发过去：哪里你不信？哪里听不懂？哪句话需要举例子？指出具体位置。

最初把它拆成四次独立配音，拼起来之后，用户听出 32 秒附近的节奏不自然。

修复时，把这段合成一次连续生成，并补充要求：几个问题平稳地说出来，之间稍作停顿，不抢拍，也不要突然拔高问句尾音。其余 36 段配音直接复用，避免把已经可以使用的内容全部重做。

这个问题给流程带来了一个明确的调整：配音按语义和语气的连续性分段，字幕另外按阅读长度分段。 一口气说顺的一段话，完全可以在屏幕上拆成五条短字幕。

第五步：字幕每次只放一个短句

前一版字幕直接沿用了配音分段，结果常常在屏幕上一次显示整段话。虽然字幕覆盖了文稿，但读起来很累，也让人物画面被文字占住。

修改后，整条视频拆成 102 条短句字幕，每条只占一行。比如上面的问句，依次显示为：

把稿子发过去
哪里你不信？
哪里听不懂？
哪句话需要举例子？
指出具体位置

拆分时先看逗号、句号、问号和冒号，再处理过长的部分。不要为了统一字数，把一个完整词语或者英文人名从中间切开。

字幕时间先继承实际配音片段的起止时间，再根据声音活动和停顿估计段内边界。29–35 秒这段连续问句，则参考测到的停顿位置单独划分。

这套方法属于按音频估计短句边界，没有做逐字强制对齐。它能避免把整段文字同时放上去，但仍需在播放时检查字幕是否提前出现、切换太快或落后于人声。本次最短的一条约 0.4 秒，也值得在试听时重点关注。

颜色、字号和位置，给变化设一个范围

这次字幕最终使用三种文字颜色：普通文字为白色，重点词用黄色 #FFE052 或青色 #68E0E8。所有文字统一使用 2 像素黑色描边，没有背景色块。

颜色落在“你先问我”“挑毛病”“举例子”“实时视频”“小动作”这类能帮助理解的词上，保留其他文字为白色。

字号在 48–64 像素之间变化，重点短句偏大；长句先检查实际宽度，确保一行能放下。随机位置限制在访谈画面区域内，不进入标题或底部留白。本次按要求没有做自动避脸处理。

随机规则使用固定种子。这样同一版重新渲染时，位置和字号不会全部重新抽一遍，比较修改前后效果也更容易。

配色信息保存在渲染清单和画面层中。普通 SRT 文件主要保留字幕文字和时间，本次最终看到的彩色、描边、字号变化，是烧录进视频画面的效果。

第六步：分层合成，修改时只重做必要部分

这条视频可以拆成四层：黑色背景与访谈画面、固定标题与水印、随时间变化的字幕，以及中文配音。

访谈原素材是横屏，先裁切到接近目标区域的比例，再等比例缩放，避免把人物横向或纵向拉变形。目标视频区域从画布坐标 (20, 600) 开始，大小为 1040 × 1030，底部到画布边缘正好留下 290 像素。

标题位于这个区域上方。水印固定在访谈画面右上角，使用 Arial Bold、52 像素，约 57% 不透明度。

具体合成时，先把 15 个镜头分别渲染并缓存，再拼接成基础视频。标题和水印做成透明图片，字幕做成按时间切换的透明画面轨道，最后一起叠加，并加入配音。

这样修改“字幕重点词换颜色”时，只需要重新生成字幕和最终合成，原始素材、已渲染镜头、配音都可以继续使用。

本项目把生成入口分成两个阶段：

# 在本地视频项目根目录执行；路径对应本次项目环境。
local_voxcpm2/.venv/bin/python 20260919/make_full.py audio
local_voxcpm2/.venv/bin/python 20260919/make_full.py render

audio 负责配音和音频时间轴，render 负责画面与字幕。这是本项目脚本的用法，不是安装 VoxCPM2 后就会自动具备的通用命令。

只改字幕样式时运行 render。改了文稿，就先更新音频，再同步字幕。脚本保存文稿校验值，发现当前稿子与音频记录不一致时会停止，避免用新字幕配旧口播。

第七步：检查成片，并明确还有什么没检查

导出成功之后，还要看文件是否真的可用。此次记录中的技术结果包括：

这里最后一行需要保留。能解码、不是静音、响度合适，都不能证明没有漏字、重复、发音错误或奇怪的停顿。字幕文字覆盖检查，也不能证明配音模型确实把每个字都念了出来。

本次工具流程没有完成听感验收，因此还需要实际听一遍，尤其关注英文人名、连续问句、字幕切换较快的位置，以及最后一句是否完整收尾。

正式发布前，也应在手机上看一遍。桌面上的抽帧图能发现遮挡和排版问题，连续播放才能看出频繁换字号、换位置是否影响阅读。

文件管理：保留一套预览和一套完整版

多轮修改很容易留下 v2、v3、final_final，过几天就分不清哪份才是最新版本。

这次采用固定文件名：每个主题只保留一套当前预览和一套当前完整版。修改成功后覆盖对应成品，预览和完整版互不覆盖。

除了 MP4，还要同步更新配套音频、SRT、文稿副本、素材清单和验证记录。原始素材、原始录音和仍被当前版本引用的缓存继续保留。

目录可以保持简单：

20260919/
  ai_everyday_uses_script.txt
  ai_everyday_uses_full.mp4
  ai_everyday_uses_full.m4a
  ai_everyday_uses_full.srt
  ai_everyday_uses_full_manifest.json
  ai_everyday_uses_full_validation.json
  make_full.py
  full_captions.py
  download_full_media.py
work/
  配音缓存、镜头缓存、透明字幕轨道和临时文件
assets/
  原始声音参考与公共素材

导出时先写临时 MP4，完整解码通过后再替换正式文件。这样即使中途失败，原来可用的成片也还在。

下次可以直接交给 Codex 的任务说明

把本次确定下来的要求整理成任务模板，下一条视频就不用从头解释：

根据已确认的中文稿制作竖屏口播视频，先做 10～30 秒预览，再做完整版。

画面：1080×1920，30 fps，黑色背景。
顶部放固定两行标题，重点数字标黄，不能被视频画面遮住。
素材放在中下区域，底部留黑约 290 像素，底部不加内容。
视频画面右上角加 0xbroli 加粗水印，约 57% 不透明度。

声音：使用已有的本地 VoxCPM2 环境和指定声音参考。
先按完整语义生成自然口播，再统一应用 1.2 倍速。
连续问句尽量一次生成；只改字幕时复用音频。
移除素材原声，只保留中文口播。

素材：准备足够多的不同片段，记录来源和原片起止时间。
本次限定原视频前 20 分钟，避开开头 10 秒，不要求画面逐句相关。
排除不适合裁切或带大面积图文的片段，避免重复铺满整片。

字幕：与配音独立分段，每次只显示一个单行短句。
按照实际音频时间安排出现和消失，不按整篇字数平均分配。
白字为主，重点词适当使用黄色或青色，统一黑色细描边，无背景。
字号在 48～64 像素间变化，位置限制在视频区域内，不做避脸处理。

验证：检查完整解码、音频非静音、字幕文字覆盖、位置边界和素材重复。
抽查画面，并试听人名、连续问句和结尾；无法试听时明确记录。
只保留一套当前预览和一套当前完整版，配套文件同步覆盖更新。

以后再调整这套流程，先看问题发生在哪一层：内容不清楚就改稿，语气不顺就改配音分段，阅读吃力就改字幕，画面单调就补素材。每次只重做受影响的部分，修改会快很多，已经确认的效果也更容易保留下来。