做内容站的人大多有个习惯：文章发完就完了，最多再同步到两三个平台。但同一篇内容其实还能变成第三种形态——可听的那种。
播客的好处不用多说：通勤、开车、健身时能听，是文字覆盖不到的场景；而且一旦进了播客客户端，订阅关系是长期的——听众会持续收到新一期推送，比搜索引擎的流量更稳定。
难点在于「手工做一档播客」的成本太高：写稿改一遍、录音录一遍、剪辑再一遍，一期节目能耗掉半天。所以这篇讲的不是「怎么录播客」，而是怎么用 OpenClaw 把已经写好的文章，批量变成一期期能听的节目，并生成订阅源让它真正被播客客户端收录。
一、先想清楚：这套流水线适合什么内容
不是所有文章都适合念。判断标准就一句话：把眼睛闭上一遍听下来，能不能听懂？
- 适合：概念解释、经验总结、案例分析、观点评论——这类内容本来就是「讲道理」，从耳朵进和从眼睛进差别不大。
- 不适合：代码教程、大量表格与数据的分析、严重依赖截图或图表的操作指南——「第三行那个参数改成六」这种话，听着就是灾难。
所以第一步不是配音，是选稿。让 Agent 按文章类型、字数、代码块占比、表格数量打个分，自动把不适合的排掉。如果文章本身是一条内容生产线产出的（参考 自动发文流程怎么搭），这个标签在写作阶段就能顺手标上，不用事后再判。
二、可听化改写：读得顺不等于听得懂
这是整条流水线最考验功夫的一步，也最容易偷懒。直接去掉 HTML 标签就丢给语音合成，出来的东西基本没法听。必须做改写，原则有四条：
- 去掉只能看的东西。代码块、表格、公式、图片说明，全部删掉或改成一句口头描述（「这里有一张对比表，结论是 A 更便宜」）。
- 把书面结构改成口语衔接。「综上所述」「基于上述分析」这类词念出来很别扭，换成「所以」「说白了」。小标题不用照念，但要在过渡处补一句「下面说第二点」。
- 数字和符号要念得出来。「30%」写成「百分之三十」，「1.2 万」写成「一万二」，「ROI」第一次出现时补一句「也就是投入产出比」。版本号、缩写、英文术语，要么展开要么删掉。
- 指代要明确。文字里能靠上下文找回的「它」「这个方案」，在两三分钟的音频里听众会跟丢。改写时要显式重复主体。
还有一个容易忽略的点：控制单期时长。先把每篇文章改写成 8–15 分钟的口语稿，太长的拆成上下两期，或者只讲其中最核心的一段。一期太长，完播率会掉得很难看。
长文改写时，上下文的管理方式参考 上下文怎么管：分段改写、每段都带上全文摘要和术语表，比一次丢整篇进去效果好很多。
三、切章节，把时间戳算出来
播客听众的一个刚需是「跳到想听的那段」，所以每期必须带章节时间戳。做法很简单：改写稿本来就按段落组织，让 Agent 在改写时给每个段落组标一个标题，配音完成后再按每段的真实音频时长累加，算出起始时间。
注意两点：
- 时间戳要实际测量，不能估算。按字数估时长在语速不一致的部分会偏得离谱。配音完成后拿到每段音频的真实时长再累加，这是唯一可靠的做法。
- 第一段固定是 0:00。开头的片头如果不算内容，建议单独拿出去，别混在章节里。
四、配音：音色、语速、停顿和响度
配音这一步门槛已经很低，真正的差别在设定。四件事定好，听感立刻不一样：
- 音色：一档节目只用一个音色，中途不换；跨期也要保持一致，听众是靠声音认节目的。选定之前拿同一段稿子多试几个，别听一句就定。
- 语速：中文播客通常每分钟 240–280 字听着舒服。太快像播报，太慢容易走神。数字和专有名词前后要放慢。
- 停顿：段落之间留 0.8–1.2 秒，章节切换留长一点，两秒以上。停顿是听觉的标点，没有停顿的段落会让人喘不上气。
- 响度：所有期统一到同一个响度标准，播客通用的参考值是 -16 LUFS 左右。这一条最容易被忽略，结果是听众每次换到你的节目都要手动调音量，体验极差。
顺带说一句：站内之前写过 给 OpenClaw 加语音能力，讲的是让 Agent 能听会说、做双向语音交互。这里是另一件事——把内容变成产品，重点在批量、一致性和分发。两者用的底层能力有重叠，但目标完全不同。
五、shownotes 和封面
每期节目除了音频本身，还要两样东西：
- 节目说明（shownotes）：一段 100–200 字的简介、本期章节列表（带时间戳）、提到的关键术语。让 Agent 从改写稿里直接生成，单期成本几乎为零。
- 封面：建议全系列用同一张底图加期号或标题的变体，保持视觉统一。批量生成封面的做法，站内 批量处理图片 那套可以直接改改就用。
提醒一句：节目简介别直接用文章摘要。书面摘要和听觉节目的简介是两种文体——前者是给搜索看的，后者是给人决定要不要点开听的。
六、音频托管与播客订阅源
这是最容易被忽略、却决定成败的一步。播客的分发机制和网站不一样：播客客户端不是去你网站上抓，是去订阅一个 RSS 源。所以你必须有三样东西：
- 能稳定外链的音频文件地址。把音频传到对象存储或自己的服务器上，拿到直链。注意播客客户端会对音频地址做周期检查，别用带时效签名的临时链接，否则过几天会集体报错。
- 符合规范的 RSS XML 文件。里面要有频道信息（标题、简介、封面图地址、分类、作者）和每一期的条目（标题、发布日期、音频直链、文件大小、时长、唯一 ID）。每个条目的 GUID 必须唯一且永不变，改一次就会被客户端当成新的一期重复推送给听众。
- 固定不变的 feed 地址。这个地址一旦公布，永远不要改——改地址等于所有订户清零。
RSS 文件本身是纯文本，让 OpenClaw 把每期信息收集好，按模板渲染、追加到 feed 里就行。注意和「订阅别人的内容」区分开：RSS 信息聚合 讲的是把外部订阅读进来，这里做的是把自己的内容按 RSS 规范吐出去。生成完一定要验证：先跑一遍 XML 格式校验，再丢进两三个主流播客客户端试订阅，看能不能正常拉到最新一期。托管和域名这套如果还没搭，参考 部署到服务器 的做法。
七、做成增量的：只处理新文章
这套流水线最大的价值在「持续」。一次性把五十篇转成播客意义有限，每周自动把新发的文章转成新一期，才算真的跑起来了。做法：
- 维护一份处理状态表（文章 ID／是否已转／音频路径／发布期号），每次只看新增和未处理的。
- 挂到定时任务上，比如每周固定时间跑一次，出来的音频先进待审目录，人听一遍首尾再发布——参考 定时日报周报怎么配 那套调度写法。
- 音频多了以后也是一种资产，要跟着一起备份，别只备份数据库。做法见 备份与迁移。
成本上要有数：语音合成按字数计费，一期十分钟的口语稿大约三四千字。每周一期量很小，但如果一开始就打算把几百篇存量文章全转一遍，先按 成本怎么算 那套估一遍再动手，别跑到一半发现预算超了。
八、三条不能越的边界
- 版权上只处理自己的内容。把别人的文章念成音频发出去，不是「二次创作」，是侵权。只转录自己原创或已获授权的内容。
- 音色授权要看清楚。用第三方音色服务前确认它允许商业使用；如果要克隆真人音色，必须拿到本人书面同意。这两条不是形式，是法律问题。
- AI 生成内容要标注。按目前各平台的通行要求，合成语音播出的节目应当明示「本节目的语音由 AI 生成」。主动标注，比被平台发现后再处理省事得多。
优缺点和适合人群
优点：同一份内容多一个触达场景，增量成本几乎为零；播客订阅关系稳定，比搜索流量更抗波动；流水线建好后每期边际成本很低；可听化改写本身也会反过来让文字稿更口语、更好读。
缺点：前期搭流水线要花时间，尤其是 RSS 规范和响度统一这两块，不像写脚本那么直观；效果高度依赖改写质量，改得敷衍就是「机器念稿」，没人会听完；机器音色在情感表达上仍有天花板，观点类内容的听感会比真人差一截。
适合：有稳定更新节奏的内容站、知识类自媒体、企业内部培训内容的复用。如果你一周只发一篇文章，做播客的性价比不高——优先把那个时间花在把这一篇写好上。
总结
- 先选稿：只挑「闭着眼能听懂」的文章，代码和表格多的排掉。
- 做可听化改写：去代码表格、口语衔接、数字念得出、指代说清楚，单期控制在 8–15 分钟。
- 切章节算时间戳：按实测音频时长累加，不估算；音色全程统一，响度全系列对齐。
- 生成 RSS 并验证：音频用固定直链，GUID 永不变，feed 地址永不改，生成后真机订阅测一遍。
- 跑成增量的：维护处理状态表，只处理新文章，挂定时任务。
最后一句实在话：播客不是把文章念一遍，是把「写给人看的内容」重做一遍成「说给人听的内容」。中间那道改写才是价值所在。改得好，它是一条新的流量入口；改得敷衍，就是多了个没人订阅的空壳。
