开发日志4: 做播客给自己听

我听过完成度特别高的 AI 合成语音，连北京腔也模仿得淋漓尽致，甚至可以区分什么地方需要重音读，什么地方需要停顿一下，价格也不贵，一万字大概 3 块钱左右。按正常人类演讲语速 180-240 字每分钟来算，一小时的稿子，花费也不超过 5 块钱。重点是没有口音、没有口误，甚至音色也能随便选。再看我订阅的一档节目，说是讲 AI 的，但我更愿意把它称之为 AI 睛雨表。因为现在的内容生产者似乎已经达成了某种默契，“语不惊人死不休”，每次听到圈里面大佬又达成了某个了不得的成就，或者哪个模型又赶超了人类某项能力的时候，我总是一边默默觉得惭愧，特别有那种“生而为人，我很抱歉”的感受，一边又觉得，我们在各方面都大力发展“新智”生产力，我这种又“老”又不“智”的，还真是被后浪要拍在沙推上了。

当时另一节课里面“熵”的理论对我有很大的启发。这本是个物理学的概念，讲的是一个系统中混乱的程度。但放到个人成长中，就有了更具体的意义。一个人，如果不接受一些新的信息，只用已经积累的经验来面对不断刷新的新时代，就会造成个人认知的“熵”不断增大，思维变得越来越混乱和无序。就像南方夏天不开窗，如果没有空调送来冷空气，会变得越来越热，或者一片常年没人打理的草坪会变得杂草丛生一样。

我心想，既然别人靠不住，AI 这么强大的能力触手可及，为什么不手搓播客给自己听呢？不但可以定制你想要的口吻，还能够挑选你觉得可信的观点，再加一层门控把虚假消息过滤掉，简直就是理想中的信息秘书。不过，按照上节所讲的步骤，一档好的播客自然也没法一步到位。

凡事不能“空穴来风。如果把播客比作是一道菜，那么最重要的是凑齐它所需要的素材。

在没有 AI 之前，Python 开发的网络爬虫比比皆是，这一点无须科普。所不同的是，现在可以更进一步，让自动化编程工具帮你来完成这些脚本的开发和调试，你只需要想清楚自己要的是哪些网站的内容，甚至你可以只说你想了解的领域，让 AI 帮你调研这个领域有哪些重量级的人物开了个人博客，有哪些领军企业有自己的官方 RSS……诸如此类。不过，如果你是一个经常在家做饭的人，自然是明白食材新鲜度的重要性。如果 AI 给你捞来的都是几个月前的文章，假如是论文，如果在一个发展缓慢的领域倒也没什么问题，但放在日新月异的当下，隔周、隔天的消息都已经沦为废纸，更遑论以月为单位。

收集素材这一步，需要一些工具操作基础，但没什么技巧。况且，我也没有严格记录自己的操作流程，并不能提供一些可以直接粘贴的提示词。再加上这里面有个悖论：假如我知道怎么做我就不需要教，假如我需要别人教我本身则不需要自己做这样的播客。故而，我的理念也和古代的琴谱一样，只身教不言传，要不就是，我做了你听便是。

到这一步，寻常厨子便觉得已经可以开火上油把食材下锅了。的确，寻常情况下，有了收集来的素材后，就可以让任何一个 AI 工具把这些内容进行整理，然后生成一个适合口播的稿子。ChatGPT 月活 10 亿人，我想这一步对每个人都是手到擒来。而且自不必说，收集，融合，转语音（aka, TTS test-to-sound），这三步本来就是一档播客的灵魂手法。

不过，如果每个厨子都是这种鬼画符的灵魂手法，想必你每天吃到的不是番茄炒蛋，就是蛋炒番茄。我们下馆子坐定后第一件事就是拿菜单，而一张菜单不仅仅是菜品的展示页，它更是食材和口味的一张关系图，也即是消费食材而生产口味的一个账本。

得有一个账本记录你采了哪些信息源

对于食客来说，菜单是多巴胺和食物的账本；而对于厨师，它既限制了菜品的制作、销售范围，也限制了食材的购入范围。对于自己给自己做播客，首先作为听众，你需要知道你想听哪些方面的消息以及用什么样的方式来陈述。比如，我要听科技相关的，但是不能机械播报，要讲故事。这里的“科技相关”加上“讲故事”，就是你想要吃到的“菜”，这个菜转换成“菜谱”就是：“搜索科技相关的近期新闻，然后以讲故事的方式做成逐字稿”。

简单来讲，我们拿到了两个字段。“行业：科技”和“目标格式：讲故事”，加上之前 AI 给找出来的信息源、新鲜度，更有点类似是后厨的供应商和供货要求。有了这个账本，这份契约后，把它写成格式化的文本，JSON、YAML 任意你觉得看起来顺眼的格式。这个看起来不起眼的文件，连接了整个播客生产过程最重要的两个部分。如果把 AI 比作是一杆枪，那这个文件就规定了这杆枪要打哪些靶，每个靶多久打一次。如果你也跟我每一样每天追着 AI 新闻，总觉得一天落下就再也跟不上潮流了的话，“Harness”这个词必不陌生。但是回顾我们刚刚做的这份契约，如果这还不叫 Harness，那什么叫 Harness 呢？

AI 的使用过程中，Prompt Engineering、Agent Engineering、Harness Engineering，再到最近异军突起的 Loop Engineering，这些所谓的红极一时的概念，如果我们足够耐下心来把自己做过的项目拆解开，再回头瞅一眼这些熟悉又陌生的丑八怪，你顿时就明白了，它们不过是我们在使用 AI 的过程中，适时要解决的一些问题。Prompt 解决的是 AI 刚普及的时候理解语义不达标的问题，Agent 解决的是多个 AI 线程互相配合的问题，Harness 解决的是 AI 行为规范的问题，而 Loop 要解决的是，上述问题都解决了之后，让 AI 稳定产出的问题。

不过，话到此处，我们会发现另一个问题，账本之外，是不是还缺个库存登记？每天多个供货商给你送来你需要的食材，如果没有相应的管理，如何保证每一样食材的供需都恰到好处？

契约不止有账本，还有状态记录

之前记录的几个字段，有点像你在刷某音、小某书的时候关注的那些大 V，它们限制了你能接触到的内容（平台推荐按住不表）。但你有没有发现一个你从来不关心的问题，平台从来不会给你推荐你看过的东西（同质不算）。为什么？因为平台也有自己的状态管理。

说起来，还真有点符合一句话的描述：“铁打的营盘流水的兵”。想让这条流水线上每一批次的 AI 都一目了然地知道之前抓到了哪些信息，哪些已经用过了给哪一期用的，没有用过的且不过时的还有哪些，近期又有什么最新的数据，这样一顿分析和记录之后，就可以（几乎）保证每期播客的素材都是不一样的，每一期的产出都有新东西。

以前的系统，稍微有点规模，都会用到数据库。按我的理解，它们也不过是为了记录信息本身，以及使用这些信息的状态和边界。前者是数据流转的通行证，而后者是数据合规的栅栏。而对于一档播客这样的规模来说，几个文本文件足矣。甚至于说，连文件存哪，里面写什么，也不需要关心。你只需要知道“冬天出门要戴手套”并告诉 AI，它会自己等“冬天”然后自己找到“手套”并“戴上”。

听说最近胡彦斌用 AI 给自己的粉丝做了一个社群网站，还在机场修 Bug。有人说，代码和编程之间的墙被推倒了。我却觉得，只是我们现在利用能量的效率更高了。

从计算机发明到现在，从汇编到高级语言，从面向过程到面向对象，这整个过程，我们要实现的只有一件事，那便是，人和计算机的沟通。我们编码自己的想法为语言，计算机解码二进制为自己的电路开关，而从语言到二进制，就是这整个编程语言的演变过程。自然地，随着计算机编码能力地一再提升，它承担了越来越多的中间过程，直到现在，自然语言成为了这道桥梁。所以并不是说代码的墙被推倒了，而是计算机从墙里面走了出来，变得和人类更近了而已。

所以，说回到播客，我们可以把这个制作流水线的过程也叫作编程，因为顾名思义，编即“制作”，程即“程序”。我们制作了一个自动生产播客的程序化的流水线，这为什么不叫编程？

我以前不负责任地说，“代码已死”。其实更准确地来讲，代码只是信息传递（人和计算机双向）的中间过程，它所承担的只是信息的传输作用。代码死不死，只取决于中间过程还需不需要他者来中介，而对于如何把一件事通过计算机做出来，这才是工程师的根本。