从 8 月开始，我对自己的工作流程做了很大更新，重建了自己的个人网站 lishuhang.me ，并且开始摸索如何使用 Jekyll 和 GitHub Pages ，还掌握了曾经想过很久要学的 Markdown 语法，写文章和发稿时用于排版的精力和时间因此节省了很多。

这些过程在我有空的时候，会另写文章整理出来，给有需要的朋友参考。

在此基础上，我决定给自己的工作流程添加简单的一两步，从而顺便生成有声读物，保持 Podcast （播客）的更新和分发。今天主要就讲一下播客相关的话题和技术要点。

播客的起源

2008 年前后，正在上大学的我有机会见到一些正在捣鼓 Podcast 的人，他们是中国最早一批播客玩家。

2005 年 5 月 1 日开播的《反波》（AntiWave）播客由“平客”和“飞猪”始创，他们来自正规的广播电台，节目也采购了先进的播音和录音设备。除此之外，两人也具备广播级别的反应和串场能力。

他们要做自己的节目原因只有一个，就是用他们在电台学到的技能，播出在广播电台不太能上的节目。

我觉得要是反播生在今天，它们必须得叫“正波”，不然上不了线。

《反波》获得德国之声 2005 年国际博客大奖的“最佳 Podcast”奖项，这个极高的标杆似乎为后来者指明了道路，此后不管是专业还是业余，有一个标志性的几千块钱的大麦克风成为你专心做 Podcast 的象征。

然而《反波》仅坚持到 2006 年 10 月就宕机了。这同样也是一个预言式的结局：很多基于兴趣而起的播客节目都坚持不下去，因为制作成本太高。

我认为，现在你看到的播客行业经历的一波波潮起潮落，只不过是后来者逐渐有钱玩得起票了以后，开始不断重复他们俩的故事。

我以前的播客尝试

2016 年底，航通社曾经尝试过在蜻蜓 FM、荔枝 FM 和网易云音乐等平台同时开通账号，上传播客节目。但仅仅播出 3 期之后，就中断更新直到今天。

节目从一开始就打定主意要用语音合成的方式，而不是自己“献声”，因为我已经考虑到自己连写文章都很拖延，如果还需要花时间念稿子，不仅坚持不下去，而且我会打心眼里认为这是一种浪费生命——虽然把这个时间省出来我利用生命的效率也高不到哪里去。

然而，仅仅是转换语音这么简单的过程我都坚持不下去。因为我还是高估了自己的懒惰程度，在上次测试播客的过程中仍然有大量需要投入人力劳动的地方。例如，需要按照播客的正方形来重新设计封面，每次都要打开做图软件重新排版，而且要想一些比较适合的引导词。

同时，其实播客最大的分发平台还是苹果的 iTunes，这也是其它一些现在比较流行的播客应用的基础，也是全世界最大的一个播客“应用商店”。但是当时为了寻找一个靠谱的方式来托管我的 iTunes Podcast，我也耗费了不少时间，降低了我继续折腾的兴致。

很多问题都是花钱可以解决的，例如你买个空间然后简单用 PHP 做一个后台，就能输出合乎 iTunes 规格的 RSS 信息。但因为我并不想为可能没有产出 / 回报的项目持续投入金钱，我自始至终都希望整个部署是免费且尽可能自动化的。

我也用过 Buzzsprout 这样的帮你上传提供空间的服务。但毫无例外地，过了免费试用期或者声音文件达到一定数量都要收费。荔枝 FM 提供的免费转 Podcast 服务，一是需要订户数量和节目数量有需求，另外是声音文件地址是随机生成的，万一荔枝倒闭了或者其它什么原因我不能继续用的话，Podcast 用户就会跟我失联。

所以，没有找到一个长期有效的免费托管方案，最终让我放弃了长期更新 Podcast 的想法。

为何要重启播客制作

最近，正好有文章开始讨论播客重新火爆流行起来的问题。腾讯全媒派的编译文章讲了《纽约时报》《卫报》《经济学人》投入资源准备通过上下班、做家务、开车等时间里对用户听觉心智的占领，达到获取新客源的目的。

我注意到，这些所列举的案例都和《反波》一样，采用高标准，高成本的精良制作，有时采集声音的成本甚至超过了制作视频节目。《纽约时报》的自然探索节目可以录制播放火山熔岩增长，植物破壳而出这样的声音，却故意丢弃了画面，实在是暴殄天物。

只有在像广播剧一样对待节目制作的基础上，才能偶尔看到《SERIAL》这样的红火局面，而且就像是文字公众号一样，指望长期产出爆款内容也是不现实的。正因如此，在上面的文章中，最早开始尝试播客制作的 BuzzFeed 也选择了知难而退。《卫报》本身也是在挣扎后停止了好多年更新的，现在重启播客可能更多是跟风竞争对手。

在国内环境下，诸如蜻蜓、荔枝、喜马拉雅、网易云音乐这样的平台就像微信公众平台一样，给任何人提供了几乎平等的音频生产工具，但也催化了更多播客主为了更新和流量考核，而不得不将内容水化，变成定期的清谈节目。假设他们受过专业训练，能把控得住也还算好，但即使是广播电台主持人也需要全职备稿，精心的选材和与嘉宾事先沟通，清谈节目想做的好同样不容易。

最后能剩下来的还坚持用人嘴播出的节目，也就随之变成了让你听他们两三个人连麦，扯一个半小时的闲篇儿，扯到哪算哪。我一位常听科技类 Podcast 的小伙伴时不时会给我传来一些做得很垃圾的节目，吐槽江河日下、漏洞百出的谈话水平。

所以，也就只能在尽量少花成本甚至不花成本的前提下，为文字消息生成一个声音文件。这既能保持内容的质量不缩水，让不擅长临场发挥的作者们少一些 NG 重录，又能提供更多样更方便的格式给读者，还能在音频这个领域“占坑”，等有余力的时候再玩一点新花样。

这也就是我重启播客的思路和预期。

选择一个最合适的 TTS （文字转语音）工具

时代在进步，AI （人工智能）遍地开花。这波通过机器学习实现自我训练，不断优化的 AI 浪潮中，其中一个被公认效果最好的应用就是机器和人类语音之间的双向互转，即语音识别和 TTS （文字转语音）。

就算是 AI 模范生讯飞，它的语音识别在一些专业和冷门的，缺乏训练的场合，还做不到替代同声传译的人类，也因此在前几天爆发了所谓“造假”风波。但事情其实没有大家想象的那么恶劣，只不过是厂家借机稍微夸大了一点儿效用，不是“汉芯”或“红芯”那样彻底的名实不符。

反过来，将电脑文字转为语音的 TTS 技术更成熟一点，效果也相对更好。已经投入使用并且可以马上就用到的产品有讯飞、百度、谷歌等等，而微软和苹果在自己的操作系统内也预置了离线可用的语音引擎，方便视力残疾人使用电脑。

在航通社播客文件的生成流程中，如何确保 TTS 的声音流畅清晰，基本达到人可以听出来，能听完的程度，是重中之重。我考察了 4 家在线和离线的 TTS 工具，并着重看它们的免费版表现如何，收费版又是否值得付费。

百度

百度云的文字转语音服务是对所有开发者永久免费的，截止目前这是唯一一家不限制用量的厂商。很明显，百度希望更多开发者的利用，能收集丰富语料以便 AI 可以自我训练。

彭博曾报道，百度在 2016 年春节期间收集中国各地的方言数据，短短两周内就获得超过 1000 小时语音。

“很多人完全免费提供这些数据，因为他们都对自己的方言感到自豪。一位四川的高中教师对该项目十分热衷，他甚至让全班同学用四川话录制了1000多首古诗。”

（ https://clip.lishuhang.me/2016/12/13/tech-giants-love-the-sound-of-your-voice.html ）

虽然我知道这会关系到我的隐私，但李彦宏说得对——“中国人喜欢拿隐私换便利”。我还是希望这种永久免费的商家将来能更多一点儿。

百度为不懂编程的人提供了一个网页版界面，用户只需要贴入纯文本，选择语音、语调和语速，就可以等待生成和下载 mp3 文件了。

（ https://developer.baidu.com/vcast ）

但在实际使用中，不限 API 用量的百度 TTS 效果并不好，特别是在处理中英文混排的技术文章时，常常会错误分词或者破音。这是利用机器学习试图改善质量的厂家的通病。

事实上，我使用百度的自动生成工具念了一篇稿子，又用了后面会提到的 Balabolka 生成另一篇稿子，后者马上就审核上线了，但百度的这个音频都好几个小时了还在审核，可能是审核员根本听不清这念的是啥。

也许它用来读全都是汉字的新闻或网络小说效果会更好一点，但这里我必须淘汰它。

讯飞

讯飞提供一个全平台的 TTS 工具，名为“讯飞快读”，提供最多 8 种中文播音员和方言、外语、蜡笔小新等特色人物，但使用全部功能，如朗读超过 500 字以上的文章，需要购买会员，一个月 12 元，一年 72 元。

讯飞在开发者网站提供另一个网页版的试听窗口，但奇怪的是其中提供的语音引擎好像不太一样，效果远不如“讯飞快读”里面的好，几乎跟百度提供的免费服务一样磕磕绊绊。

虽然“讯飞快读”的播音效果确实听起来已经非常不错，也能正常处理中英文混排的情况（要选用“播音员”里最上面 4 个带“V”字样的，其中“小媛-小说”效果相对更好一些），但即使付费之后，它转换文本和保存本地 MP3 的过程也还是显得漫长而繁琐，因此也不考虑。

谷歌

谷歌 API 中允许外部调用的文本转语音引擎包括英语、其他欧洲语言和日语，但并不包括中文。要想体验谷歌娘怎么说中文，需要用谷歌翻译网站，好在该网站即使在国内也可以正常访问。

（ https://translate.google.cn/ ）

在左侧输入框贴上需要转换的文字，点左边或右边的喇叭图标都可以听到发音。中英文混排问题也能很好的处理，但这个中文听起来有微微的台湾腔。

同时，鉴于翻译场景假设你并不懂中文，试听语速很慢且不可调节。如果你点击了一下小喇叭之后，再点击第二次，将会有神奇的事情发生：出来的将是一字一顿，像蜗牛一样缓慢的声音。

还存在两个问题：（1）录音不能保存为本地声音文件，即使用 F12 检查器也无法侦测到语音文件的地址；（2）输入框最多只能插入 5000 个字符。

Balabolka

在网上问及有什么比较好的 TTS 工具，很多人推荐一款完全免费的本地应用 Balabolka 。之所以能免费，是因为 Balabolka 实际上就是 Windows 自带的“慧慧”语音引擎的一个调用接口。

（ http://www.cross-plus-a.com/cn/balabolka.htm ）

从 Windows XP 开始，微软就采用了名为“讲述人”的文字转语音服务，以方便视力残疾用户。在 2001 年它能做的事情相当有限，但经过将近 20 年的迭代，这个语音引擎现在已经做的非常好了，几乎跟苹果的 VoiceOver 不相上下。

即使是纯本地，不需要联网的情况下，Balabolka 也是效果最好，远远好于百度、谷歌等在线生成的效果，而且转换速度也比讯飞快，所以最终选定的就是它。

在 Mac 下也有类似的调用系统听写引擎的小软件，方便把文本转换为声音，名字叫 Toau。这个软件和大名鼎鼎的 Mac 端 Markdown 编辑器 Mou 是同一个开发者，但 Toau 不收费。

（ http://25.io/toau/ ）

综上所述，各大语音引擎中只有百度和操作系统自带的可以不限量使用，而系统自带的引擎效果又最好。

确定一个切实可行的播客制作流程

为了充分吸取上一次播客停摆的教训，现在要想以写好的文字自动生成播客文件并上传到服务器，需要一个规定好，并能一气呵成地操作的流程。

在文章定稿后，首先要针对语音转换中一些可能会读错的地方做简单的预处理。我的文章开头和结尾都有版权声明，这个也是机器念出来的，但念到网址和微博 ID 等信息的时候会听不清。因此，我需要单独写一个机器念出来没有问题的段落，并替换文章相应部分。

就像这样：

经过几次调试以后，文章不需要预先试听，完全可以直接点击转换为 mp3 格式音频。然后就像群发到 XX 号一样，可以依次上传到各个国内播客平台了。

此外，我也会手动打开 GitHub 上的空间，上传音频文件，这样就可以通过 Jekyll 自动生成可以被 iTunes 读取的播客 RSS 。我找到一些讲这个的技术文章，但今天时间不够，所以未来两天应该会走完 iTunes 的审核流程。到时我也会写新的文章来讲怎么实现。

GitHub Pages 不仅可以提供无限制的静态页面和文件上传空间（前提是你不存放任何保密的东西），而且还友好的提供 Let’s Encrypt 的 HTTPS 证书，确实可以说是我等省钱党的福音。

最后，附上航通社 Podcast 的几个收听地址给大家：