# 我把一篇文章转成视频,最后发现最难的不是做页面,而是音频
**作者**: AFei Liang
**日期**: 2026-07-09T08:14:29.000Z
**来源**: [https://x.com/afei_AI/status/2075408812920680488](https://x.com/afei_AI/status/2075408812920680488)
---

这两天,我完整跑了一遍“文章转视频”的流程
这次没有使用 Hyperframes,因为我的重心是稿子、节奏、画面信息密度和用户反复确认
主要用于比如文章解说、B 站/YouTube 录屏、产品 talk demo、动态 PPT
可控性会高一些
> **AFei Liang@afei_AI**: [原文链接](https://x.com/afei_AI/status/2075131461049729438)
>
一开始我以为,最麻烦的地方会是网页开发
比如如何把文章拆成章节,如何设计每一屏,如何让动画和内容配合起来
但真正跑完之后,我发现最卡人的地方反而是音频
尤其是这三个问题:
1. 每一段单独合成,音色会漂
2. 整章合成,声音稳定了,但 step 边界不准
3. cue 校准如果靠手动下载和覆盖文件,流程会非常折磨
所以这篇文章,我想复盘一下这次真实的过程
不是讲一个“理论方案”
而是讲我怎么把一篇文章,变成一个可以自动播放、带旁白、能录屏的视频网页

中间踩了哪些坑,又怎么一点点把流程工具化
# 一篇文章,先变成网页视频项目
这次处理的是之前一篇关于本地测试 stripe 的文章:
> **AFei Liang@afei_AI**: [原文链接](https://x.com/afei_AI/status/2072865354217587043)
>
它不是传统视频剪辑项目,而是一个网页视频项目
使用的GitHub上开源的一个skill:web-video-presentation,当然根据自己的需求又做了些处理
具体的可以看我前面的那一篇
生成的网页目录大概是这样:

其中 presentation/ 是真正的网页演示项目
文章会先被拆成脚本和大纲,再变成一章一章的网页画面
最后这个项目做完后,一共有:7 章 44 段 narration

也就是说,整篇文章被拆成 7 个章节,44 个旁白片段
网页部分完成后,可以启动 dev server
然后打开
按数字键可以跳章节,按方向键或者空格可以推进 step
这正是我想要的

到这一步,网页视频的“画面”基本成立了
但它还没有声音
# 第一版音频方案:每个 step 单独生成 mp3
这里选择的 TTS 引擎,一个是有道的confuciustts,一个是 voicebox
让 codex 结合我的需求与 skill 的流程对比了两个 TTS,最终选择了 voicebox

而且 Voicebox 提供了一个 REST API,用于将语音输入输出集成到您自己的应用程序和代理中
更多关于 voicebox 使用可以看看这个:
> **AFei Liang@afei_AI**: [原文链接](https://x.com/afei_AI/status/2074679720176992758)
>
之后,直接让 codex 对接 voicebox 来合成音频
最开始,我沿用的是最直觉的方案:
每一段 narration 生成一个 mp3
也就是:
```
step 1 -> 1.mp3
step 2 -> 2.mp3
step 3 -> 3.mp3
```
放到项目里就是:
```
presentation/public/audio/<chapter-id>/<step>.mp3
```
比如第一章 coldopen:
```
public/audio/coldopen/1.mp3
public/audio/coldopen/2.mp3
public/audio/coldopen/3.mp3
```

这个方案的好处很明显
网页播放逻辑非常简单:
当前页面是 step 1,就播放 1.mp3
播完之后自动 next
step 2 就播放 2.mp3
对网页来说,这几乎是最省心的方案
但是测试 Voicebox 之后,很快就遇到问题
有些音频和参考音频很像
有些音频明显不像
这不是某一段文本写错了,而是生成方式的问题
因为每个 step 都是一次新的 TTS 请求
Voicebox 这类声音克隆模型,每次生成都会重新采样
短句尤其容易漂
有时候是音色变了
有时候是语气变了
有时候是速度和停顿不一致
听起来就像同一个视频里,换了几个人在说话
这对知识类视频来说很致命
画面可以简洁一点,动画可以少一点
但声音一旦不稳定,就有点拉跨了
# 第二版方案:按章合成,再切回 step mp3
于是我开始尝试第二个方案
不要每个 step 单独生成
而是把一整章的 narration 合并起来,一次性生成一个完整音频
然后再切回每个 step 的 mp3
也就是:
```
整章文本 -> chapter-full.mp3 -> 1.mp3 / 2.mp3 / 3.mp3
```
结果很清楚:
整章音频的音色确实更稳
因为它是同一次生成
上下文一致,声音也更连贯
但新的问题来了:
切分不准
如果只按照文本长度比例去切音频,很容易切到半句话中间
或者前一个 step 的尾巴被切到下一个 step
这就变成另一个问题:
声音稳定了,但画面和声音对不上
对视频来说,这也不能接受
# 真正靠谱的方案:整章音频 + cue 时间轴
后面我意识到,问题不在“怎么切得更准”
而是根本不应该切
最好的方案是:
保留整章音频,但不要再切成 step mp3
改成:
```
chapter-full.mp3 一直播放
cue.json 控制什么时候切换 step
```
也就是:
```
0.000s -> 显示 step 1
6.343s -> 显示 step 2
12.742s -> 显示 step 3
……
```

最终每章输出两个核心文件:

这个方案一下子把问题拆开了
声音交给整章音频
画面同步交给 cue 时间轴
音频不再被强行切开,所以不会切坏
step 仍然可以精准切换,因为 cue 可以人工校准
这才是我觉得更适合网页视频的方案
它只生成:
```
chapter-full.mp3
cue.json
```
不再切 step mp3
前端播放器也改成:
优先读取 chapter-full.mp3 + cue.json
如果没有,再 fallback 到旧的 step mp3
# 但 cue 校准又成了新痛点
一开始,cue 的校准方式也很原始

打开页面:
然后按数字键切章节
播放整章音频
听到下一个 step 应该出现的位置,就按 N
一章校准完,再按 S 下载新的 cue.json
然后手动覆盖回:cue.json
这个流程能用
但不好用
因为你每校准一章,就要下载一次,再找到对应目录,再覆盖文件
7 章还好
以后如果是 20 章、30 章,这个动作会非常烦
更关键的是,它容易出错
你可能覆盖错章节
也可能忘了保存
也可能下载了新 cue,但页面还在读旧文件
所以:
> 真正应该做的,不是让人手动搬文件,所以考虑把整个流程做成一个本地 Web 工具,把这个流程串联起来,这个后续做好了再来分享吧~
## 相关链接
- [AFei Liang](https://x.com/afei_AI)
- [@afei_AI](https://x.com/afei_AI)
- [19h](https://x.com/afei_AI/status/2075131461049729438)
- [2.1K](https://x.com/afei_AI/status/2075131461049729438/analytics)
- [Jul 3](https://x.com/afei_AI/status/2072865354217587043)
- [835](https://x.com/afei_AI/status/2072865354217587043/analytics)
- [Jul 8](https://x.com/afei_AI/status/2074679720176992758)
- [3.1K](https://x.com/afei_AI/status/2074679720176992758/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:36 AM · Jul 10, 2026](https://x.com/afei_AI/status/2075408812920680488)
- [59 Views](https://x.com/afei_AI/status/2075408812920680488/analytics)
---
*导出时间: 2026/7/10 11:18:13*