【实践记录】一段录音变文章和播客，这条 AI 流水线我大改了三次

上一篇聊的是视频生成那条线，这篇换个方向，说说音频——我是怎么把一段录音，同时变成一篇公众号文章和一期喜马拉雅播客的。

这事得从源头讲起。

最开始，我是自己录音做复盘，录完直接丢到音频平台上，日更，零剪辑。录音的时间也一直在变：起初是睡前，后来挪到下班骑车回家的路上——边骑边把当天的事说了。

后来出了一趟差，跟同事挤在一块儿住，录音就不方便了。我就换了种方式：改成先写文稿，再用 AI 把文稿合成音频、生成内容。

这一换，倒让我发现一个意外的好处——AI 合成的音频，效果比我那套零剪辑的录音好太多了。 自己录，难免有杂音、语气词、各种磕巴和停顿，听着累；换成 AI 念文稿，这些毛病一下全没了，播放量也比之前好看些。于是我就顺着这条路又用了一阵。

用着用着我琢磨：文稿都已经写出来了，干嘛不顺手发到公众号上？于是形式又变了一次——复盘的文稿发公众号，对应的音频发音频平台。 一稿两用，文字和声音各走各的。

可新问题跟着来了：写文稿这件事越写越长，时间越拖越久，到后来一期甚至要耗上两个小时。成本扛不住，我中间停更了一阵。

停的那阵子，我把这事重新捋了一遍，最后决定换个打法：还是回到语音录复盘，但不再自己吭哧吭哧写文稿——而是让 AI 拿转录下来的文字，自动帮我生成文稿和播客音频。 录音只管说，剩下的全交给它。

为这件事，我做了一条流水线。它前后大改过三次，而三次改动的方向始终是同一个词：做减法。

为什么一直在减？因为我慢慢想明白了一件事：流水线越复杂，就越慢、越容易出错、越不敢放手让它自己跑。 而我的终极目标，是把录音一丢，它自己跑完、自己发出去，我什么都不用管。要够格「自己跑」，它就得足够简单、足够确定。

下面就来讲讲我用 AI 折腾这件事的全过程——这条流水线「最开始长什么样、中间砍掉了什么、最后定型成什么」。

先说流水线长什么样

一段录音进来，要经过这些环节：

语音转文字 → AI 同时优化出两份内容（公众号文章 + 播客脚本）→ 质量门禁 → 配图和封面 → 播客用 TTS 合成音频 → 分别发到公众号和喜马拉雅

有意思的是，公众号和播客这两份内容，是从同一段录音文字同时分叉出来的，各自独立优化。下面先讲这条流水线本身的版本演进，再讲它每个环节用过的工具。

一、三个版本的瘦身史

第一个版本：8 个 AI 角色、17 次子 agent 调用

最早的版本，我设计了一支「AI 团队」来分工：有人专门提炼核心观点、有人负责写公众号文章、有人负责写播客脚本、有人专职检查质量……一口气 8 个角色（每个角色其实就是一个子 agent）。一次完整跑下来，光是子 agent 调用就要 17 次。

功能很全，每个环节都「专人专事」，听上去很专业。但实际跑起来：太慢，而且角色一多，它们互相交接的地方就多，每个交接点都可能出错。一次跑挂了，你甚至都不知道是哪个环节的锅。

第二个版本：砍到 4 个角色、4 次子 agent 调用

我做了第一次大刀阔斧的瘦身：8 个角色合并成 4 个，子 agent 调用从 17 次砍到 4 次。

怎么砍的？把那些「看起来分工精细、其实可以合并」的步骤并掉。比如「提炼观点」和「写文章」这两步，完全可以由同一个角色一次做完，没必要拆成两次子 agent 调用、两个角色。能一次做完的事，就别拆。

这一刀砍下去，速度快了一倍多，出错的地方也少了一大半。

第三个版本：删掉那个看起来很核心的「中间层」

第二次瘦身更狠——我删掉了一个听起来像是「整个系统核心」的东西：brief 中间层。

最早的设计是这样的：先从录音转出来的文字里，提炼出一份「内容策略 / 提纲」（我管它叫 brief）——核心观点是什么、结构怎么排；然后公众号文章和播客脚本，都基于这份提纲来写。一次提炼，两处复用，多优雅。

但我用着用着发现，多这一层，就多一次 AI「跑偏」和「丢信息」的机会。 提纲在提炼的时候，如果漏掉了某个细节，或者 AI 自作主张加了点演绎，那么公众号和播客会跟着一起错——而且这个中间产物还特别难调试，因为它夹在两层调用之间，你不专门去翻根本看不见。

于是我把它整个删了：公众号和播客，直接对着原始的录音转录文字各自优化。 公众号做「书面化」，播客做「口语化」，谁也不经过中间层。

代价当然有：两个平台可能观点覆盖不一致（以前那个中间层至少能保证都覆盖到核心观点）。这个代价，我靠后面的「质量门禁」来兜底。

工程上经常是这样：一个看着更「高级」、更「解耦」的设计，未必比一个更直接的设计跑得稳。少一层抽象，往往就少一类 bug。

二、平台也做减法：从四个砍到两个

这条流水线最早是同时管四个平台的——公众号、喜马拉雅、抖音、小红书。

后来，我把抖音和小红书砍了，只留公众号和喜马拉雅。

为什么？因为不同平台的格式、规则、发布方式差别太大。每多管一个平台，流水线的复杂度和维护成本就翻一倍。而且我做的内容（复盘和日记），现在更适合图文（公众号）和播客（喜马拉雅）一些，硬要塞进短视频平台（抖音）和图文种草平台（小红书），效果也一般，还要专门为它们再做一套适配。

还有一个更现实的原因：这套东西是跑在 Claude Code 里的，每多管一个平台，它的指令、流程和交接记录就要多吃掉一大块上下文。当时能用的上下文窗口只有 20 万（200k），四个平台塞下去几乎吃满，流水线自己都快「记不住」全貌了。现在窗口涨到了 100 万，余裕大了不少——所以这次砍掉那两个平台，更多是当下的聚焦，未必是永久砍掉——等以后有余力了，再拓展回来也不是没可能。

砍掉之后，流水线专心做好两件事，反而稳了。

（顺便说一句，抖音的发布能力没浪费——它被挪去了昨天说的那条「短视频流水线」那边，专门定时发抖音。工具是复用的，只是不再硬塞进这条录音流水线。）

三、每个环节用过的工具，都换过

光讲版本演进还不够。这条流水线的每个具体环节，「最开始用什么、后来换成什么」，本身也是一部小型的工具更替史。

语音转文字：whisper.cpp → Faster Whisper

这部分跟昨天说的视频流水线用的是同一套技术：最早用 whisper.cpp（要自己编译配 CUDA，很折腾），后来换成 Faster Whisper，配 large-v3-turbo 模型加 VAD，又快又准。这块换得不多，基本定型。

内容生成的「大脑」：Claude

整条流水线是跑在 Claude Code 里的一套 skills（技能），真正干「脑力活」的就是 Claude。

它干的活，说到底是把转录出来那团口语化、零碎、夹着一堆「然后」「那个」的文字理顺，再一分为二：一份往「书面化」走，结构收住、句子干净，发公众号；一份留在「口语化」，保住说话的节奏，给后面的 TTS 当脚本念。同一份录音，读文章的人和听音频的人要的不一样，就得分别伺候。

Claude 还兼着判断——哪句话有传播力、哪段该删、结构怎么排。但用得越久我越克制：该靠它「感觉」判断的才交给它，能写成硬规则的绝不麻烦它。 字数、禁用词、集号格式这些一刀切的检查，我都做成确定性程序去跑，不浪费它一次调用，也不给它自由发挥出错的机会（这部分后面「质量门禁」专门讲）。

还有个我觉得挺关键的习惯：每次让它干活之前，我先把提示词写到磁盘上，再拿去调用，而不是临场拼一句丢过去。这样提示词能留档、能回看、能复跑——哪次出来的东西不对劲，我能翻出当时到底给了它什么指令，不至于对着一个黑盒干瞪眼。

图片生成（封面 + 插图）：换得最频繁

这是整条流水线里换得最频繁的环节，先后用过三家：

• 最早用 Pollinations.ai，一个免费的 AI 画图服务。一开始免费好用，但后来它改了规则、要注册账号才能用，就没再用了。
• 换成 稿定（Gaoding），一个设计平台。它没有开放 API，我是用 Chrome 浏览器登进去、靠自动化替我「点鼠标」出图的——出图稳定、效果也好，缺点是走浏览器，比直接调接口慢不少（每张还要花几颗「豆」的积分）。
• 中间又接了 Agnes（另一个 AI 画图服务），本想用它替掉稿定、省掉走浏览器的麻烦。但用下来发现，它的出图效果比稿定差一截，达不到我要的质感，最后还是弃了。
• 所以最后固定回稿定：慢是慢了点，但效果好、稳定，综合下来最放心。

这一路换下来，踩了两个特别有意思的坑：

一是颜色只能用描述词（「暖橙色」），不能用 hex 色值（「#FF8800」）。因为 AI 画图模型分不清你给它的这串字符，到底是「颜色指令」还是「要画在图上的文字」——你给它一个 hex，它很可能在图里画上一行「#FF8800」。

二是图里要不要有文字，得专门验证一遍。AI 画图特别爱「画了一堆占位符」或者一串谁也看不懂的假字。所以我专门派一个角色去检查：提示词里说要画上去的字，是不是文章里真实存在的词，而不是乱码。

我还把封面和插图分别做成了独立的方法：封面用「五维方法」（类型×色彩×渲染×文字×情绪），插图用「三维方法」（类型×风格×色彩），给 AI 一个结构化的约束，而不是丢一句话让它随便画。这种把需求拆成几个维度来约束 AI 的做法，是参考了宝玉的 skills。

语音合成：edge-tts → MiMo 声音克隆

播客要的是音频，所以这部分是用 TTS 把脚本合成成一段音频文件再传上去的（不是直接传文字稿）。同样是从 edge-tts 换到了 MiMo，用克隆出来的品牌音色念。

排版：自写脚本 → inkpress

公众号文章要排版成微信兼容的样式。最早这部分是我自己写的一个把 Markdown 转成微信 HTML 的小脚本——能跑，但样式得自己一点点抠，想换个主题更是麻烦。后来干脆换成 inkpress（一个专门把 Markdown 转成微信 HTML 的库，自带二十多种主题），省心多了。我最终把主题定在 vogue，还顺手把水印关了。

发布：全浏览器自动化 → 公众号走 API

最早所有平台都是用浏览器自动化发的——我做了个 browser-publisher，连着我已经登录好的 Chrome，让程序替我把发布流程点一遍。能用，但脆。

最典型的是公众号：它的编辑器是 React 写的，浏览器上传图片这一步老出问题——你刚选好图，React 一重新渲染，文件框就被清空了。后来我发现公众号其实有官方开放 API，草稿、图片、发布都能直接走接口，比让程序模拟点击稳定太多了，不用再跟 React 编辑器斗智斗勇。所以公众号这块整个迁到了 API 上。

建完草稿我也不信它返回的「成功」，一定会用接口把内容读回来逐项核对，生怕图没传上、标题是空的。

喜马拉雅（播客）那边没开放 API，没法走接口，只能继续用浏览器自动化，连着登录好的 Chrome 去发。

四、质量门禁：从无到有，一层层加

最早的版本是没有质量门禁的，AI 生成什么我就发什么。后来问题多了，开始一层层往上加：

• 加了「禁用 AI 腔短语」检查——就是那些一眼假的 AI 套话，比如「在这个快速发展的时代」「让我们一起探索」，一旦出现就打回。
• 加了 reader_hook / story_value 检查——开头够不够抓人、有没有给读者实实在在的价值。
• 把那份「禁用词列表」做成了单一真相源：检查程序运行时去读一份配置文档，我想增删禁用词只改文档就行，不用动代码。
• 加了机器校验：字数在不在区间、结构对不对、播客集号格式对不对。

这里有个细节能看出规则得多细：禁用词里有「最后」这个词，但只有它出现在段落开头时才算违规（「最后我们来看看……」这种套路收尾），出现在段落中间的「最后」是不管的。规则不细到这程度，就会误杀。

一直在做减法，是为了敢放手

这条流水线的演进史，从头到尾就是一个「做减法」和「确定化」的故事：

角色从 8 个砍到 4 个，平台从 4 个砍到 2 个，中间层整个删掉，不可控的 AI 步骤换成确定性算法，图片生成固定到一家稳定的供应商，质量门禁一层层补上让规则取代感觉。

每砍一刀，流水线就简单一分、确定一分，我也就更敢放手让它自己跑。

做工具的人（包括以前的我）很容易有一种倾向：觉得功能越多越好、技术越先进越好、架构越「优雅」越好。但我这段时间最大的体会是——

一条能自己稳定跑通的简单流水线，远比一条功能炫酷却总出问题的复杂流水线有价值。 简单和确定，才是「自动化」真正的前提。

录完音之后的事，本就该交给机器。但只有当这条流水线简单到、确定到我完全信得过它的时候，我才真的敢把它交出去。

工具搞定了「能发」，没搞定「有人看」

讲了这么多「做减法」，可流水线把「能发出去」搞定之后，「有没有人看」它一个字也管不了——这件事，我得诚实说。

这些自动生成的播客，发到喜马拉雅，每期播放量也就几十。

比视频还惨。视频好歹还有几百播放，播客经常是个位数、两位数。

这个数字让我反思了很久。它说明的事跟视频那条线一模一样：我这条流水线解决的是「怎么把录音稳定地变成可发布的内容」，没解决、也解决不了「有没有人来听」。

播客没人听，不是因为 TTS 音色不够好、脚本不够顺、集号排错了——而是选题有没有切中一群人的需求、有没有攒起愿意追更的听众、内容有没有给到不可替代的价值。这都是内容本身和长期运营的事，跟流水线工程化到什么程度，没有半点关系。

那这篇文章讲的那些「做减法」「确定化」，到底图什么？图的是让我能把录音之后的所有琐事，毫无负担地丢给机器——好让我腾出全部精力，去死磕那个真正决定播放量的部分：内容。

流水线再精巧，也换不来一个听众。但没有这条流水线，我连稳定产出都做不到，就根本没有打磨内容的余力。

工具是地基，不是房子。地基打得再牢，房子还是得自己一砖一瓦去盖。播放量这件事，没有捷径，也没有哪个工具能替你扛。

而比播放量更让人难受的，是公众号那边：阅读量也差不多，每篇几十。但公众号的问题比「没人看」更深一层，而且这一层我得自己认：这些文章，很多我自己都看不下去。

事情是这样的。我后来把公众号文章，改成让 AI 直接拿录音的转录文本来「创作」。本意是省事，可实际跑下来我发现，AI 经常自己臆想——它会顺着转录里的只言片语，发挥出一堆我压根没说过、也不是我想表达的意思。我随口聊的一段话，到文章里被「润色」成了一个我并不认同的观点。

这种文章发出去，我自己读着都觉得别扭，不像「我」说的。一篇连创作者自己都看不下去的文章，读者凭什么读完？几十的阅读量，说实话非常正常——内容是自己糊弄出来的，就别指望数据好看。

这是这条流水线目前最大的短板：它能稳定地产出「形式上合格」的内容（结构对、字数够、没 AI 腔），却保不住「忠于我本意」这一层。 工程把「合格」自动化了，没把「好」自动化——而「好」恰恰得靠人来把关。

所以接下来我打算改打法了：AI 生成的初稿，我不再直接放行，而是自己过一遍，凡是跑偏的、臆想的、不是我想表达的地方，一律改回来或者删掉。流水线可以替我打草稿，但最后那道「这到底是不是我想说的」的关，必须我自己来把。

工具能帮你写得快，但没法替你写得真。