一个人用 AI 流水线做出 156 支双语视频：完整方法与踩坑复盘
先说结果：13 集《孙子兵法》职场解说系列，中英双语，每集 1 支 7 分钟横屏长片 × 2 种语言，再加 10 支竖屏切片，一集 12 支，13 集共 156 支成片。全程一个人，没有剪辑师，没有配音员，没有插画师。
这篇文章不卖课，就是把这条流水线怎么搭的、钱花在哪、坑踩在哪，原样复盘一遍。你可以把「孙子兵法」换成任何一个「固定结构 + 系列化」的内容题材，方法是通用的。
整条流水线长什么样？
六个命令，串起来就是一集视频：
script → 人工审稿 → parse → images → tts → render
(LLM) (人) (本地) (生图API) (语音API) (本地渲染)
关键认知：整条链路只有 3 处花钱调 API——LLM 出文稿、文生图画插画、TTS 配音。其余全部本地跑：
- parse：把人审过的 Markdown 文稿解析成结构化 JSON，同时跑质量门禁（后面细讲）
- 音频拼接和字幕时轴：本地把逐行语音拼成整轨，时轴直接用每行音频的实际时长累加——这一招绕开了"字级对齐"这种又难又不稳的技术
- render：用 Remotion（React 写视频）本地渲染，横屏长片和竖屏切片共用同一套场景组件，零 API 成本
一集双语全量出片（2 支长片 + 20 支切片素材），渲染时间大约 8 分钟。长片一支约 3 分钟，切片一支约 20 秒。
为什么中英两个版本，插画只画一套？
这是整条管线里性价比最高的一个设计：插画锁定「简笔画线稿」风格，并且硬性禁止图内出现任何文字。
图里没字，就没有语言归属。中文版和英文版共用同一套 20 张插画，生图成本直接砍半。风格锁定靠一段固定的 STYLE_PREFIX 拼在每个 prompt 前面，13 集下来 250+ 张图，只有 1 张风格跑偏（这张的事故原因见下面踩坑部分）。
缓存是这条流水线的命根子
批量生产最怕的不是第一遍生成，是返工。第 10 集发现第 3 集有个错别字，难道重跑整集？
所以缓存粒度必须细：
| 资产 | 缓存粒度 | 改动成本 |
|---|---|---|
| TTS 语音 | 行级（音色+语速+语言+文本哈希） | 改 1 行文案 = 只重新合成 1 行 |
| 插画 | 张级（模型+风格+prompt 哈希） | 改 1 个 prompt = 只重画 1 张 |
| 渲染 | 无缓存，但纯本地 | 重渲切片 = 0 元，只花 20 秒 |
实际发生过的场景：EP13 有一张插画风格翻车，重抽 1 张图 + 增量重渲 4 支受影响的视频，全程 6 分钟，API 成本 1 张图。没有行级/张级缓存的话，这就是重跑一整集的钱。
一个配套的纪律：文稿里每一行有个自动生成的行 ID（比如 S1-03），它是语音缓存、字幕时轴、插画锚点的共同索引。在段落中间插一行，后面所有行的 ID 会位移，对应缓存全部失效重新合成——这是设计上的已知成本，不是 bug。所以改稿时能加在段尾就加在段尾。
质量靠什么守住？机器门禁 + 两处人审
AI 批量生产最容易翻车的地方是"看起来都对，读起来全是塑料味"。我的做法是把审核拆成两层。
机器门禁（parse 阶段强制执行，不过不给出片）：
- 五段结构完整、行动建议必须恰好 3 条
- 案例段必须有具体人物和数字，不许空对空
- 鸡汤词黑名单：命中「从今天起」「记住这句话」这类词直接拒绝。EP12 的中文稿就撞上过，被打回重写——事后看重写的版本确实好得多
- 引用原文必须真实在场：文稿声称引用了某句原文，门禁会做归一化比对，防止 LLM 伪造引文
- 插画 prompt 版权黑名单，防止生成侵权元素
人工审核只保留两处：一是文稿（整条管线唯一必须人工的环节，也是质量的真正来源），二是插画 contact sheet（一张网页看全部 20 张图，不满意的单张重抽）加配音试听。
我的体会是：人工审核不能省，但可以收窄。把人的注意力集中在"文稿好不好"和"图有没有翻车"两个点上，其他全交给机器门禁，这个分工跑了 13 集没出过质量事故。
踩过的 9 个坑，按疼痛程度排序
1. 英文 "9 a.m." 被断行器腰斩。 长句自动切行是按标点切的，"9 a.m." 里的句点被当成了句尾，一句话被切成两行，TTS 念出来是割裂的。发现时已经渲了一半，中途停链把稿子里的 "9 a.m." 全改成 "9 o'clock" 重跑——行级缓存兜底，只补合成了改动的那几行。教训：喂给断句逻辑的文本，先想想缩写、小数点、省略号这些"假句号"。
2. 插画 prompt 里一个词毁掉整张图。 EP13 有张图的 prompt 写了 "keywords" 和 "a hand adding a mark"，模型十分听话地画了一只写实人手，还在图里写了字——同时破了"简笔画"和"图内无文字"两条风格底线。改成抽象符号的说法后一次通过。教训：prompt 里出现"手""写""文字""标注"这类词，文生图模型大概率真的给你画出来。
3. MiniMax 的业务错误走 HTTP 200。 限流（1002）、余额不足（1008）、内容敏感（1026）这些错误，HTTP 状态码全是 200，真正的错误码藏在响应体的 base_resp.status_code 里。只判断 HTTP 状态的话，限流失败会被当成成功，拿到一个空产物继续往下跑。接任何国产大模型 API，先看它的错误码到底在哪一层。
4. 连续生图必被限流，重试要带退避。 一集 20 张图连着打，触发限流是常态不是意外。加了 2s/5s/10s 三段退避重试，外加每张成功后主动歇 1.5 秒，之后三集连产 54 张图零失败。批量调用别裸奔，退避 + 主动节流是标配。
5. 引文门禁的比对逻辑反过来约束了写稿话术。 门禁要求引用的原文在归一化后是全文的连续子串。EP13 想引的那句话在原著里中间隔着别的句子，直接引就过不了门禁。最后用「缩成一句话：先知者，必取于人」的话术化解——既符合口播习惯，又满足机器比对。机器规则和内容创作打架时，先想想有没有两全的表达，别急着给规则开洞。
6. TTS 默认音色不能信，必须真人试听。 代码里默认配的"高管音色"参数上看着很对，实际一听平淡得像念说明书。换成"精英青年"音色后整个片子的精气神都不一样。音色选型没有捷径，就是把候选都合成一遍用耳朵挑。代价是：换音色 = 该语言全部行重新合成，所以这个决定要在第一集就定死。
7. 停顿控制要按厂家翻译。 文稿里统一写 [pause] 标记，但 Azure 认的是 SSML 的 <break> 标签，MiniMax 认的是 <#0.50#> 这种文本停顿符。管线在合成前按目标厂家翻译标记。多供应商架构里，"内容标记"和"厂家方言"必须分层，不然换一次供应商就要改一遍全部文稿。
8. Remotion 的 bundle 快照。 Remotion 渲染时会把素材打包成快照，素材必须在 bundle 之前落盘到位，晚一步就是渲出来图片全空。这个坑第一次踩的时候排查了很久，因为报错信息完全不指向真正原因。
9. LLM 直出的稿子不能直接用，但也不是没用。 直出稿的问题是套路化和悬浮感，但它把五段结构、切片选点这些"体力活"做完了。我的用法是把它当"结构完整的初稿"，人工改口语度、换案例细节、调节奏。审稿是整条流水线里最值钱的人工时间，省这个等于放弃质量。
这套方法适合什么内容？
一句话判断：固定结构 × 系列化 × 讲解型的内容都适合。
具体点：每集结构相同（我的是"痛点—原文—框架—案例—行动"五段）、系列有 10 集以上（摊薄搭管线的成本）、画面以插画+字幕+旁白为主（不需要真人出镜和实拍）。反过来，单集内容、结构随性、强依赖真人表现力的内容，搭这套流水线是亏的。
FAQ
Q：一集视频的 API 成本大概什么量级？ 一集双语大约是 1~2 次 LLM 出稿、20 张文生图、300 行左右 TTS 合成。因为有行级/张级缓存，这是"第一遍"的成本，之后所有返工都只花增量。渲染完全免费（本地）。
Q：为什么用 Remotion 而不是剪映/CapCut 的模板？ 因为要"数据驱动"：字幕时轴、插画位置、进度条全是从结构化 JSON 算出来的，改稿重渲不需要人碰时间轴。Remotion 本质是用 React 写视频，对工程师来说心智成本最低。代价是渲染吃 CPU，且第一次搭场景组件有门槛。
Q：竖屏切片是重新做的吗？ 不是。切片和长片共用同一套语义场景组件和行级语音缓存，切片的音频是从缓存现拼的，零额外 TTS 成本，一支只要 20 秒渲染。
Q：最不能省的环节是什么？ 人工审稿。机器门禁能拦住结构错误和鸡汤味，拦不住"平庸"。13 集的质量差异基本全部来自审稿投入的时间差异。
Q：从零搭这条流水线要多久？ 我的路径是先花一天跑通"单集出片"的最小闭环（P0），再花两三天补缓存、门禁、双语、切片（P1）。不建议一上来就设计完整架构，先让第一支片子出来。
这套流水线的完整技术选型：TypeScript CLI + MiniMax（文生图 image-01 / TTS speech-02-turbo）+ Remotion 渲染，全部本地运行。如果你也在做系列化的 AI 视频内容，希望这些坑你一个都不用再踩一遍。