Best Minds Board Report
双人语音播客接入：实现方案与模型/API对比
2026-01-19 · 个人开发者 / 人格创业者（做双人播客） · 接入方式 · API 生态 · 成本/性价比 · 配置清单 · One next action
从脚本到音频：可自动化流水线、供应商对比、成本估算与配置要点
要点速览
- 双人播客最稳的工程解法：先生成结构化对话脚本（A/B），再用两种 TTS 声线分段合成并拼接。
- API 方案优先选成熟云 TTS（AWS Polly / Azure Speech / 火山引擎等），再根据中文听感做“样音 A/B 测试”。
- 成本别拍脑袋：先算脚本总字符数，再按“每 1M characters”或“按时长”口径换算。
关键洞见
- “双人”不是模型能力，而是分段与声线映射的工程能力。
- 好听靠：停顿、复述句、追问节奏；不是靠堆更贵的模型。
- 先跑 90 秒样音对比，再决定长期供应商与预算。
步骤指南（新手友好）
新手模式
- 生成 A/B 脚本 JSON
LLM 输出分段对话（speaker=A/B），每段 1–3 句，便于合成与替换。 - 映射两种声线
A=主持音色，B=拆解者音色；统一语速与停顿规则（SSML）。 - 逐段 TTS 合成
用 TTS API 批量生成片段音频（wav/mp3），失败可重试单段。 - 拼接与响度标准
ffmpeg 拼接 + 轻 BGM + -16 LUFS；导出最终 mp3。 - 发布与归档
写 show notes（来源/链接/免责声明），把脚本与音频都归档。
检查清单
-
脚本段落是否足够短（可替换/可重录）
-
A/B 声线是否区分明显且不刺耳
-
数字与单位是否口语化（避免生硬）
-
音频规格是否统一（避免拼接爆音/跳变）
-
show notes 是否含来源与免责声明
奥卡姆优先（只保留必要的）
- 第一版先不做声音克隆（减少合规风险）
- 先做 3–5 分钟样音验证流水线
- 先选 1 家云 TTS + 1 家中文 TTS 做对照
SVG 图解
专家视角
Ira Glass — This American Life 制作人（叙事节奏与“场景”能力标杆）
- 立场： 先让听众进入场景，再给结论；复述句是听感的扶手。
- 论据： 播客不是论文朗读，双人对话要用“追问—复述—反驳—清单”把信息变得可听。
- 边界： 再好的技术也救不了无聊脚本；脚本结构永远优先于模型大小。
“（paraphrase）Start with the moment, then reveal what it means.” — This American Life
方案对比
| 方案 | 适用场景 | 收益 | 代价 | 关键风险 | 第一步 |
|---|---|---|---|---|---|
| A | 先验证节目风格（最快试播） | 最快出成品；不用写工程代码 | 可控性与自动化弱；难批量化 | 素材版权与引用边界容易忽略 | 用 1 篇公开文章做 10 分钟试播 |
| B | 想规模化与可控（推荐） | 脚本与声音完全可控；可批量生产 | 需要搭一套切段/合成/拼接流程 | 配置不当导致听感机械（停顿/重音） | 先跑 90 秒样音对比 2 家 TTS |
证据与置信度
| 主张 | 证据 | 置信度 | 来源 |
|---|---|---|---|
| AWS Polly 定价示例以 1M characters 展示，并区分 Standard/Neural/Long-form/Generative | AWS Polly pricing examples 表格包含上述列名与示例金额 | High | AWS Polly Pricing |
下一步
- 选一篇稿件，切成 60–90 秒 A/B 段落 JSON
- 用 AWS Polly + 火山引擎各跑一版样音对比
- 把最优组合写进 SOP，并固定 voice/语速/停顿规则
细节（可选）
二级页面
保持主报告简洁。复杂推导、长表格、深度材料放到二级 HTML 页面，再在这里以链接方式引用。
你要解决的本质问题
- 双人播客不是“一个模型能不能生成两个人说话”，而是：你能不能把内容切成可控的对话片段，并用两种声线稳定合成，再做混音与发布。
- 所以要把系统拆成两层：脚本层（LLM） 与 语音层（TTS/Voice）。
1) 三种接入方式（从快到强）
| 方案 | 你得到什么 | API | 成本/稳定性 | 适合你现在的阶段 |
|---|---|---|---|---|
| A. 无代码（App 内生成） | 文章→双人对话→音频（快速试播） | 通常无公开 API 或能力受限 | 最省事；但不可自动化、可控性低 | 第一周：验证节目风格与听感 |
| B. 半自动（脚本 API + TTS API） | 你掌控脚本结构、两位声线与后期 | 有（主流云 TTS 都有） | 性价比最好；可批量化 | 第一季：把流程跑通并固化模板 |
| C. 全自动（端到端流水线） | 上传资料→自动生成→自动发布 | 有（你自己做编排/队列/存储） | 开发成本高；但可规模化 | 第二季：准备做“内容工厂” |
2) 双人语音播客的“最小可行技术栈”（推荐 B 方案）
- 素材输入：文章全文/要点（+ 证据表，避免爽文）
- 脚本生成（LLM）：输出结构化 JSON：[{speaker:"A"|"B", text:"...", intent:"追问/复述/反驳/总结"}]
- 语音合成（TTS API）：A/B 选择两种 voice；按段落逐条合成音频片段
- 拼接/混音（ffmpeg）：加入片头片尾、轻 BGM、响度标准化（例如 -16 LUFS）
- 发布：导出 mp3 + show notes + 素材链接
关键工程点：不要让 TTS 直接吃“整集长文本”。要让它吃“短段落”，你才能做双人对话、插入停顿、修一段不影响全局。
3) 模型/服务对比：哪些有 API？（以“语音层”为主）
由于本环境对部分站点（例如 OpenAI/Google/ElevenLabs）访问受限，我只对能访问到的官方页面给出“高置信”结论；其余给出“常识判断 + 待你二次确认”的标记。
| 提供方 | API | 双人实现 | 计费口径 | 性价比/效果 | 配置要点 | 来源 |
|---|---|---|---|---|---|---|
| AWS Polly | 有 | 两种 voice + 分段合成 + 拼接 | 按字符（示例表给到 1M characters） | 高性价比；工程成熟 | SSML（停顿/强调）；输出格式；可配 Speech Marks 做对齐 | aws.amazon.com/polly/pricing |
| Azure Speech (TTS) | 有 | 两种 neural voice + SSML；企业合规选项多 | 页面展示 per 1M characters（含不同 voice 类型说明） | 效果稳定；适合企业/多语种 | SSML；voice 类型（neural/HD/custom）差异；区域与配额 | azure.microsoft.com/.../pricing/details/speech |
| 火山引擎（豆包语音） | 有（文档中心） | 两种音色 + 分段合成；中文生态适配 | 需在控制台/文档查具体计费 | 中文听感通常更自然（需你实测） | 鉴权/签名；音色选择；长文本切段策略 | volcengine.com/product/voice-tech |
| OpenAI / ElevenLabs / Google TTS | 通常有（但本环境无法访问其官方页确认） | 同上（两种 voice + 分段） | 通常按字符或时长/秒计费 | 往往“听感更强”，但价格/条款要看当期 | 注意版权/克隆授权；流式/批处理接口差异 | 本环境无法在线核验（建议你在本机浏览器打开官方 pricing） |
4) 价格与性价比：一个可落地的估算方法
- 先生成脚本，拿到总字符数（含标点）。
- 按提供方计费单位换算：例如 AWS Polly 的 pricing examples 明确给出“1 million characters”的示例成本（Standard/Neural/Long-form/Generative）。
- 总成本 ≈ (总字符数 / 1,000,000) × 单价 + （少量存储/CDN/后期工具）。
提示：你做的是“播客”，听感通常比纯成本更重要。建议先用 2–3 家各跑一段 90 秒样音，再决定长期供给。
5) 双人播客脚本：建议的输出格式（强烈推荐）
[
{"speaker": "A", "role": "主持", "text": "欢迎来到我的播客…今天我们聊…"},
{"speaker": "B", "role": "拆解者", "text": "先把一句话机制讲清楚…"},
...
]
- 用 speaker=A/B 作为 TTS 的 voice 映射键。
- 每段建议 1–3 句话；避免一个段落 30 秒以上（不利于改稿与拼接）。
- 主持人的“复述句”是听感关键：把长内容压成一句话给听众跟上。
6) 配置清单（落地时最容易翻车的点）
- 切段：按语义切（不是按字数硬切）；段尾加短停顿（SSML 的 break）。
- 音频规格：统一采样率/声道；避免拼接时出现音色/响度跳变。
- 响度：播客平台常用 -16 LUFS（立体声）/ -19 LUFS（单声道）。
- 中文数字读法：让脚本阶段就把“$516 MRR”改成“每月经常性收入 516 美元”这种可口播表达。
- 版权与授权：如果做“文章复盘”，show notes 明确来源；若用声音克隆，必须获得授权。
7) 推荐你从哪里开始（一步到位）
- 先用你已做出的 EP01 文本稿，切成 A/B JSON 段落（3–5 分钟样音）。
- 用 AWS Polly 跑一版低成本样音（验证流水线）+ 用火山/其它中文 TTS 跑一版“更好听”的样音。
- 选“听感最佳且可持续”的组合，把它写进 SOP，并固定 voice、语速、停顿规则。
来源
收尾总结
先用“分段 + 两声线 + 拼接”跑通一条稳定流水线，再讨论更贵的模型与声音克隆。
- 把双人播客当作“音频编排问题”，而不是“模型玄学问题”。
- 用 90 秒样音做 A/B 测试，最快选出性价比最好的语音方案。
- 脚本的口语化结构（场景/冲突/复述/清单）决定听感上限。
一个下一步动作
用你现有的一期脚本切成 90 秒 A/B 段落，分别用 AWS Polly 与火山引擎合成两版样音后再选长期方案。
“用一句收束全篇的核心引言。
可换行以形成节奏。”
— Name