【实践记录】AI 内容生成流水线 5.0：一条录音变出图文、播客、视频
之前在《一段录音变文章和播客，这条 AI 流水线我大改了三次》里，我聊过这条流水线在 4.0 版本怎么靠「做减法」定型。最近，我又大改了一版，也就是现在的 5.0。
这次改的地方不少，折腾到挺晚才弄完，所以我先不长篇大论了，画了张图，你一眼就能看出大概的不同：
图里两条流程，上面是 4.0，下面是 5.0，盯着下面多出来的一截看就行。差异归成四句：
一，多了个视频。 以前录音变两件（文章 + 播客），现在变三件。
二，从「一个人干」变成「一群人各干各的」。 4.0 是一个大脑包揽所有事；5.0 拆成一个调度员加六个专员，调度员只管喊谁先干、谁等谁。
三，多了两条互相「喂」的线。 插图的分段喂给播客（图和嘴对得上），播客的音频再喂给视频当旁白。
四，视频能自动发到视频号了。 用这条 5.0 流水线将上一篇《Anthropic 的 36 页创业手册：AI 把创业压缩成四个阶段》从文章一路跑到视频、再自动发到视频号，整条链路已经跑通了。
下面这篇就来接上，把这次的具体改动讲清楚：相比 4.0 版本，我具体改了哪些地方，又为什么要这么改。
改动归成三件：多了一个视频产物、把「一个 agent」拆成「调度员加六个 agent」、把插图和播客音频拼成视频。一件件说。
改动一：加了一个视频产物
最直观的变化，是产出从两件变三件：文章、播客之外，多了视频。
为什么要加？一段录音转成文字后，能派生出的东西本来就多——文章是给人读的，播客是给人听的，视频是给人看的。以前只做了两件，第三件一直空着。这次补上：拿前面已经做好的文章、插图、封面、播客音频当原料拼成视频，不需要再从录音重新生一遍。
原料都是现成的，等于把一段录音的利用价值再榨一道。也正因为它复用的是前面几个产物的原料，视频不是凭空多出来的一环，它从一开始就长在已有产物上。
不过，要让这种复用真的顺畅，背后还做了一步不小的改造。视频不是把插图和播客随便堆一起就行——它得知道哪段画面配哪段旁白，对得上才行。这就要求插图和播客用的是同一套分段：文章先被切成几段，插图照着这个分段来配图，播客也照着这个分段来组织内容。等于把文章的分段当作一个统一信息源，插图和播客都从它派生。这样一来，视频直接照着分段，把对应的插图和播客音频对位拼起来就行，不用再重新理解一遍文章、重新切一遍。
这种把播客和插图对位拼起来的做法，效果谈不上最好，但成本最低。换成 hyperframes 那样从零写代码逐帧生成，画面动画精致一些，可每一期都要重新生成代码、计算量大；换成 AI 直接生成视频，效果好的贵，免费的效果又不行。相比之下，直接把播客和插图拼在一起，是最省成本的。
改动二：从「一个 agent」拆成「调度员加六个 agent」
要加上视频这第三件产物，问题跟着来了：怎么把它塞进已有流水线，还不搞乱原来的东西？
难就难在，旧架构本身就经不起再加东西了。上一版流水线，是一个 agent 内联干完所有事：转录、写文章、配图、合成播客、发布，全揉在一个 agent 里。这么做不是不能用，但随着产物越来越多，几个毛病会慢慢冒出来：所有职责挤在一个 agent 里，它的上下文越来越杂、越来越难聚焦，写文章的指令和合成播客的指令互相干扰，每一件的质量都不容易稳；想单独改某一环、或换个新模型试试某一步，也牵连太广，不好动手；更别提单独复用其中某一环——比如只想拿写文章那部分接到别的流水线里——根本抽不出来。真要把视频也塞进这个大 agent，只会让它更臃肿、更难稳。
既然硬塞进去行不通，那就换个思路：不改旧架构去硬装视频，而是把旧架构整个拆了重搭。这次我把这个大 agent 拆了，改成一个纯调度员：它自己不生产任何内容，只按顺序喊下游 agent 干活，每个 agent 只管自己那件产物、只认固定的输入文件、只吐固定的输出文件。**接口定死，谁也不许越界读不属于自己的东西。**这样视频作为新增的一件产物，只需要再开一个对应的 agent，而不必去改动别的部分。
具体到流程上，调度员要喊的下游 agent 有六个，它们按顺序接力、各管一件产物，交接关系是这样的：
调度员先把录音转成文字，交给文章 agent。文章 agent 拿这份转录作为输入，产出一篇公众号文章和一段摘要——这一步是整条线的源头，后面所有 agent 都从这篇文章往下接。
文章出来后，调度员同时喊起封面 agent和插图 agent。封面 agent 读文章的标题和论点，产出一张封面图；插图 agent 读文章正文，把文章切成几段、每段配什么图，产出一批插图，还顺手回写文章——把正文里的占位符换成真正的插图引用。它还会留下一份分段清单，记着每段配了什么图、图里突出了哪些词，这份清单后面会反复用到，改动三会讲。
接着是播客 agent。它的输入是文章和插图 agent 留下的那份分段清单，产出是一段播客脚本和一档合成好的播客音频。它读那份分段清单，是为了专门挑图里出现的词去讲——这样播客嘴上讲的，和插图里画的，天然就对得上了。
播客音频就绪后，视频 agent才开工。它不重新合成旁白，而是直接拿播客那版音频当旁白，配上文章、插图、封面、播客脚本，拼出一个视频。
最后是发布 agent。它是个多平台调度口，扫项目目录里已经做好的产物，按平台分发：文章配封面摘要发公众号，播客音频配标题描述发喜马拉雅，视频文件发视频号。预告里那句「视频能自动发到视频号了」，就是它干的——上传、选封面帧、填短标题、勾声明原创、标 AI 生成内容，一路跑到点「发表」。
可以看出，每个 agent 只管自己那一件，输入输出都固定死。这么分工，好处落在前面说的三条上：每个 agent 上下文聚焦，质量更容易稳；想改某一环、换某一步的模型，只动那一个 agent，不牵连别的；哪一环要复用到别的流水线，直接抽出去就行。而且做视频的和发视频的是两个 agent——做视频的只管把视频生成出来，发视频的只管把它送到平台，我不用在中间当搬运工。
改动三：插图和播客音频，到底怎么拼成视频
前面两件改动讲完，视频这第三件产物的原料都备齐了：文章、插图、封面、播客音频。但原料备齐不等于视频就能自动出来——视频 agent 还得解决几个问题：哪段画面配哪段旁白？字幕从哪来？最后怎么合成？
先说最难的：画面和旁白怎么对位。 视频不是把插图和播客随便堆一起就行，它得知道讲到第几句该显示第几张图。这就用上了改动二里那份分段清单——还记得播客 agent 会读它吗？视频 agent 也读它。那份清单记着文章分成了几段、每段配哪张图；而播客脚本里又带分节标记，标着每段口播对应哪一节音频。两边一对，每张图就绑到了对应的口播段落上：讲到这段，就显示这张图。分段清单相当于把插图、播客、视频三方串起来的统一索引，所以改动二里特意让它跨棒传递，就是为了视频这一步能直接对上位。
再说字幕。 字幕不是单独再写一份，而是对播客音频做语音识别，拿到每个词的时间戳，再把播客脚本对齐上去，生成逐句字幕，烧进画面。这样字幕、旁白、播客脚本三者完全同步，不会出现嘴上讲一个字、字幕显示另一个字的情况。
最后怎么合成。 每段画面先各自渲染成无声的小片段，再按顺序拼接起来——封面打头，后面跟着各段插图画面；然后整条播客音频作为音轨铺上去当旁白，字幕叠在画面上。整个过程在本地用 FFmpeg 完成，不依赖任何云服务，分五个阶段跑，每个阶段做完都会存档，中途断了接着跑就行。
这么一套下来，视频的每一帧画面、每一句旁白、每一条字幕，都能追溯到同一篇文章——这是前面三件改动最想拿到的好处：三件产物讲的是同一套话。
最后
回头看这三件改动，其实就奔着一个目标：让生成的内容物尽其用。一段录音转成文字，写出文章、配上插图、合成播客，每一样产物都是花了功夫做出来的；视频再把文章、插图、封面、播客音频统统拿来用，让这些中间产物不止服务于一件事，把每一样内容的价值尽量榨干。视频拼接的效果谈不上最好，前面也说了，但它换来了一个实在的好处——我不用再为视频单独操心，录音进来，三件产物自己往下跑，最后连视频号都自动发了。
具体怎么改的，前面三段已经拆开讲完了。这篇我只把设计和图讲清楚，没再嵌一遍视频——想看实际生成的视频长什么样，可以翻《AI 内容生成流水线 5.0：这次加上了生成视频》，里面那一段就是这套流程实跑出来的。想看这条流水线最初是怎么一步步搭起来的，可以翻翻《一段录音变文章和播客，这条 AI 流水线我大改了三次》。
这条流水线我还会继续打磨，如果你也在用 AI 做内容，或者对这套「一条录音变出图文、播客、视频」的玩法有什么想法、疑问，欢迎留言聊聊。觉得有用，也欢迎转发给同样在折腾 AI 内容的朋友。关注我，跟进后续。
本文由作者手写初稿，AI 辅助改写。