edge-tts-podcast：让 Agent 替你做播客

发表于 | 分类于

edge-tts-podcast: From search to script to audio, fully automated

以下内容包含AIGC

一年前 fork 并魔改了一个开源项目 edgetts-cloudflare-workers-webui，微软还是太善了，让我们零成本的调用 TTS 服务。最近萌生一个想法：vibe-code 一个专门用于制作双人播客音频的全栈项目，让 AI 负责写稿、人工修订、工程负责调用 Edge TTS 接口，实现文字转语音、合并不同发言人的音频碎片，最终得到完整播客。

正在发愁这个产品的 UI 和交互会有些重… 转念一想，什么时代了，为什么还执着于造 UI 和服务端？为什么不能驱动 Agent 做这件事？播客制作的工作流很清晰，一个 Skill 应该能实现。

于是用 Claude 实现了初版，将 max-search 的正交拆解 Tavily 关键词的最大化搜索逻辑、deep-reader 的模拟微信浏览器 fetch 网页并清洗 HTML 标签的逻辑全都移植了过来。实现用户提需求，Agent 自动从互联网搜索相关语料、写稿。

解决什么问题

制作一期播客的传统流程：选题 → 搜资料 → 写文字稿 → 录音 → 剪辑 → 发布。每个环节都需要人工介入，耗时且重复。

edge-tts-podcast 把这个流程自动化了：

  1. 语料收集：从一个想法、关键词或文章 URL 出发，通过 Tavily 搜索或网页抓取，获取充分的事实性语料
  2. 脚本生成：基于语料生成双人（或单人）播客文字稿，输出为结构化的 CSV 文件
  3. TTS 生成：逐行调用 Edge TTS 服务，生成音频片段
  4. 音频拼合：按顺序拼合所有片段，行间插入静音，输出完整的 MP3 文件
  5. 文字稿导出：同步生成便于阅读的 Markdown 文字稿

整个流程在一个会话里完成，每个阶段可断点续传。用户只需在关键节点确认或修订，其余交给 Agent。

工作流如何串起来

技能分为 5 个严格顺序执行的阶段（Phase 0-5），每个阶段完成前不能跳入下一阶段。工作目录结构如下：

1
2
3
4
5
6
7
{yyyy-MM-dd}_{topic}/
├── meta.md # 播客元信息（随引导阶段逐步更新）
├── sources/ # 可追溯语料（Tavily 原始结果、文章正文、研究笔记）
├── lines.csv # 播客文字稿（tab分隔，done 列标记完成状态）
├── voices/ # 逐行音频产物（1.mp3 / 2.mp3 …）
├── transcript.md # 便于阅读的文字稿（Phase 5 自动导出）
└── podcast.mp3 # 最终拼合产物（Phase 5 生成）

Phase 0 — 前置检查

技能激活后立即执行，检查 TTS 后端连通性（直连微软 Edge TTS 或走 Cloudflare Worker 代理）和 Tavily API Key 配置。如果在已有工作目录中，询问是否继续断点任务。

Phase 1 — 引导式需求收集

引导式对话，边问边更新 meta.md：

  • 明确输入类型：想法/主题、搜索关键词、文章 URL
  • 确认播客基本参数：双人/单人、目标时长、语言风格、音色方案
  • 创建工作目录（使用绝对路径，避免相对路径在多轮对话中因上下文污染导致文件分散）

Phase 2 — 语料搜索与收集

这是整个流程中最关键的环节。没有充分的事实性语料，后续生成的播客就是空洞的 AI Slop。

输入类型 C（URL）：

  • 调用 fetch_article.sh 或 fetch_article.ps1（根据操作系统选择），伪装微信浏览器绕过常见反爬，直接生成 Markdown 写到 sources/article.md
  • 若内容不足（< 300字），自动生成补充搜索查询

输入类型 A/B（想法/关键词）：

  • 查询拆解：将用户输入拆解为 3-4 个正交查询（Definition、News、Data、Opinion、Comparison、Technical），关键词之间尽量不重叠，各自覆盖一个角度
  • 语言策略：按信息源的实际分布决定查询语言。计算机科学、AI、Web3 等领域英文为主；中国本土政策、A股、中文流行文化等中文为主
  • 执行并行搜索：每个查询 num_results=6，总条目 ≤ 24，输出落盘到 sources/tavily-search-results.txt
  • 结果处理：从搜索结果中选取相关度 ≥ 0.7 的 3-5 条，抓取文章正文，创建 sources/research-notes.md 列出将用于脚本的论点，每个论点标注来源文件和 URL

退出门槛：在标记 Phase 2 完成前，必须确认：

  • sources/tavily-search-results.txt 或 sources/article.md 已存在且非空
  • sources/research-notes.md 已存在且至少列出 3 条将用于脚本的论点
  • 已抓取至少 2 篇高价值页面，或在研究笔记中说明为何只能依赖原文/Tavily 摘要
  • meta.md 已更新搜索策略、语料清单和 Phase 2 勾选状态

Phase 3 — 播客文字稿生成

基于 sources/research-notes.md 中标注来源的论点生成高质量、自然流畅的播客对话脚本。

使用 prompts/podcast_script.md 中的完整提示词作为生成指导，输出 tab 分隔的 lines.csv：

1
2
3
done voice_id content speed pitch
0 zh-CN-YunyangNeural 大家好，欢迎收听今天的播客。 1 1.0
0 zh-CN-XiaohanNeural 对，今天我们聊的话题是 AI Agent 的发展趋势。

生成完成后展示前 5 行和后 3 行，告知总行数和预估时长，询问用户是否满意。Phase 3 完成后停下来，等待用户指示，不自动进入 Phase 4（human-in-the-loop）。

Phase 4 — 逐行 TTS 生成

用户确认文字稿后，执行批量 TTS 生成：

1
python scripts/tts.py <workdir>

脚本会：

  1. 自动选择 TTS 后端（默认直连微软；配了 TTS_BASE_URL 则走代理）
  2. 读取 lines.csv，跳过 done=1 的行
  3. 串行逐行调用 TTS（不并发，避免限流并保证状态一致）
  4. 将音频保存为 voices/{行号}.mp3
  5. 每行完成后立即将 done 更新为 1（原子写入，断点续传保障）

支持 --line N 单行重生成，--delay S 调整行间等待秒数（直连模式默认 0.3s，若被限流可加大到 1-2s）。

Phase 5 — 音频拼合

将所有 voices/*.mp3 按顺序拼合为完整的 podcast.mp3，行间插入静音（默认 500ms，可调整为 250/500/750/1000ms）。拼合成功后，脚本还会从 lines.csv 导出 transcript.md：正文使用”云希”、”晓晓”等简短说话人名称，未知音色按首次出现顺序标为”说话人 1 / 2 / 3”，完整 voice_id 保留在文件开头的说话人对照表中。

1
python scripts/concat.py <workdir> --silence 500

迭代重点与技术亮点

从 git log 可以看出，这个技能改了很多次。每次迭代都在解决一个具体问题：

迭代方向 问题 解决方案 价值
fetch_article 改为 sh 脚本 Python 版本依赖第三方库（requests、beautifulsoup4），增加安装成本 改用 bash + curl + sed/awk/grep（系统自带），Windows 提供零依赖的 PowerShell 版本 零外部语言运行时，跨平台兼容
concat.py 增加文字稿导出 音频生成后没有便于阅读的文字稿，用户想回顾内容得打开 CSV 从 lines.csv 解析 voice_id 映射到简短说话人名称，自动生成 transcript.md 提升可用性，文字稿可直接分享
podcast_script.md 提示词优化 Opus 5 写出的播客生成提示词过于平庸，无法很好的避免 AI 腔（”不是…而是…”、”本质上”、”毫无疑问”） 用 GPT 5.6 Terra 优化提示词，增加”避免 AI 腔”、”开场 Hook”规则和可听性指导 生成的播客更自然，信息密度高且易于理解
语料目录规则增强 Agent 有时会跳过语料收集直接生成脚本，导致内容空洞 增加 Phase 2 退出门槛检查，强制落盘语料文件并标注来源 确保播客基于真实语料，可追溯性强
human-in-the-loop 机制 Phase 3 生成文字稿后直接进入 TTS，用户没有修订机会 Phase 3 完成后明确停下来，等待用户确认或手动修改 lines.csv 用户可控，避免生成大量不满意的音频

技术亮点总结：

亮点 说明
正交拆解关键词 从 Definition、News、Data、Opinion、Comparison、Technical 六个维度拆解查询，避免关键词重叠，各自覆盖一个角度
语料可追溯性 所有事实性表述在 sources/research-notes.md 中标注来源文件和 URL，避免 AI 凭记忆编造
断点续传 lines.csv 的 done 列标记每行 TTS 完成状态，跨会话可继续未完成任务
零依赖网页抓取 bash 版本用系统自带工具（curl + sed/awk/grep），PowerShell 版本零依赖，伪装微信浏览器绕过常见反爬
避免 AI 腔 提示词中明确禁止模板化对仗、万能判断、空泛升华，不是…而是… 全文至多一次
TTS 后端自动选择 默认直连微软 Edge TTS（零配置），直连不可用时切换到 Cloudflare Worker 代理
文字稿导出 从 lines.csv 解析 voice_id 映射到简短说话人名称，完整 ID 保留在对照表中

为什么 AI 播客比 AI 长文更有价值

我最近两天重度使用了这套技能，发现 AI 播客与 AI 生成的大段文字相比，由于播客限定了讲话的行数、限定了受众人群、限定了语言风格，特别容易定制出信息密度高同时有益于人类理解的内容。

虽然生成式人工智能的本质是复读机，但通过双人播客这种谈话形式传递出来的内容和知识特别容易留在脑海中。在主持人和嘉宾的一问一答、头脑风暴过程中，带着思考去倾听，更易于理解。

我用双人播客探索了一些之前没想明白的问题。经过 AI 的最大化搜索、可追溯的语料收集、有效的语言组织，我明显感觉到学到了新的知识。虽然它可能是语音版的 AI Slop，但相比文字版的 AI Slop 更有意义——至少对我来说是这样。

快速开始

安装技能：
直接对 Claude Code（或你的任何 Agent）说

https://github.com/icheer/skills 从这个仓库里安装 edge-tts-podcast 技能

配置环境变量（必需 Tavily API Key，可选 TTS 代理）：

1
2
3
4
5
6
# ~/.env 或系统环境变量
TAVILY_API_KEY=tvly-your_key_here

# 仅在直连被墙/被限流时配置
TTS_BASE_URL=https://your-worker.workers.dev
TTS_API_KEY=your_api_key_here

支持多 Key 轮询：

1
TAVILY_API_KEY=tvly-11111,tvly-22222,tvly-33333

使用：

1
/edge-tts-podcast 帮我生成一期关于 AI Agent 发展趋势的播客

Agent 会引导你完成需求收集、语料搜索、文字稿生成、TTS 生成、音频拼合的完整流程。

项目在这里：github.com/icheer/skills

技术栈：Bash/PowerShell + Python + Edge TTS + Tavily Search API + PyDub

如果你也在探索 Agent 驱动的内容生成，希望这个 Skill 能为你带来参考价值。

Buy me a coffee ☕