撷声 Xiesheng｜把小宇宙播客转录为结构化文稿
本地转写结合大模型校订，平衡质量、速度与成本
运行机制
整套链路由四个模块协作：抓取模块负责小宇宙节目元信息与音频，转录模块在本地完成转写与说话人区分，校订模块把长文分块交给 LLM，渲染模块按固定结构组装 Markdown。各阶段产物独立保存，原始转录可回查；分块缓存按来源、模型和提示词版本隔离，单块失败回退原稿，遇到限流退避重试，断点可续跑；支持 API 与会话内两种后处理链路。
为什么做
小宇宙自身的会员服务只有内容概要、速览亮点和章节大纲，没有我想要的导出文稿和说话人区分等功能。市面上的播客转录服务通常按月订阅，最低档也要约 70 元/月。对于不定期转录的我来说，为几集付一整份订阅费是明显的价格错配。同样的钱，换成按需调用大模型 API，可以用很久。
一份覆盖 12 款国内外转录工具的市场调研进一步印证了这一点：订阅制对于低频用户是明确的价格错配，而「低成本、校订干净的完整稿」在市面上没有直接对标物。市场调研全文。
目标
市面工具要么贵、要么需要自己再加工，我要解决的问题是，如何低成本且高质量地得到播客转录文稿，在准确率、处理速度与付费成本之间取得平衡。
关键判断
语音转写和语义整理应该分别由不同能力承担。
语音识别需要处理长音频和本地算力，语义整理则需要理解专名、上下文和内容结构。因此，我用本地 ASR 完成转写和说话人区分，LLM 只负责校订、分段、人物信息和内容提炼。原始转录始终独立保存，模型不会成为唯一事实来源。
转写后端的选择是逐步试出来的，不是一次选定的。
最初基于 GitHub 开源项目选用 Faster-Whisper Tiny，但准确率低；又换到 Small 和 Medium，准确率上来了，转录速度却非常慢。于是我重新做技术选型，做了一次三模型基准对比——用 Faster-Whisper、SenseVoice-Small、Paraformer-Large 分别转写同一期播客并做同一套校订：Faster-Whisper 约 1 倍实时、繁体字形混入 178/万汉字；SenseVoice-Small 约 9 倍实时、繁体混入降到 4/万；Paraformer-Large 约 4 倍实时，支持热词与字级时间戳。最终移除 Faster-Whisper 路线，默认 SenseVoice-Small，Paraformer 保留为可选后端。说话人区分同样实测对比后，采用 SenseVoice 自带的说话人模型一站式产出标签，从 Show Notes 解析说话人数并强制聚类，避免独立说话人模块与转录文本对不齐。
在长链路处理中设置恢复节点。
从播客链接抓取到最终转写文稿需要经过多个阶段。我保留原始转录，并按来源、模型、Show Notes 和提示词版本隔离分块缓存。分块校订完成后仍按原始顺序拼接，单块失败时回退原稿，遇到限流或服务过载则退避重试。这样既提升长文处理效率，也避免一次异常让整条链路从头再来。
当前结果
实测一期 60 分钟播客约 10 分钟完成转录（约为原时长 1/6）；单期 API 成本不超过 0.1 元，走免费会话校订链路时成本为 0。
关键迭代节点：
- 转写准确率低 → 将 Faster-Whisper Tiny 改为 Small，再到 Medium，叠加 LLM 校订，完善项目脚本
- 原始转录混乱 → 增加说话人区分与固定输出结构（内容提要/闪光语句/大纲/人物简介/全文转录）
- 长链路失败中断 → 分块缓存、失败回退、限流退避、断点续跑
- 转写慢、中文繁简混杂 → 用三模型基准对比后，选定 SenseVoice-Small 并移除 Faster-Whisper
- 自动校订依赖 API → 增加免费会话内校订链路，两条链路产出同构
- 转录文稿语病多 → 强化 LLM 校订提示词
GitHub: https://github.com/Joyyi-11/xiesheng-tool
局限与下一步
当前主要支持小宇宙，依赖本地转写模型（SenseVoice-Small）与 Python 环境；页面结构变化可能影响抓取，说话人身份仍需人工复核。最大外部风险是小宇宙官方补齐转录/摘要能力或收紧反爬，因此在架构上把「小宇宙抓取」隔离为可替换适配层，保留 RSS/本地音频入口作为逃生通道。
下一步邀请少量重度播客用户验证安装成本、异常提示与输出可用性，重点验证外部用户能否低门槛稳定使用。