先跑通核心

最近我一直在用 AI 重建一个前数字时代的想法：一个你可以坐下来听的电台。它后来变成了 echofm 和 huisheng.live。这个想法很小，也很有人情味。人们给电台写信，电台挑出值得回复的信，写一封温暖的回信，再配一首符合情境的歌，让写信的人感觉自己真的被听见。

三个月。300 多个合并的 PR。一期节目。然后我依然不知道，到底有多少人真的想参与这个想法。⁺我确实刷过 Reddit，想看看人们会写什么样的信。但我还没有正式访谈过一个潜在听众。

这篇文章不是在讲这个产品本身，而是在讲一个更尴尬的错位：编程智能体（coding agent）帮我一路写代码，让我越做越快，也越容易绕开最该先验证的问题。智能体移除了工程上的痛感，而那种痛感，本来会保护我不要过早地开始规模化。

看起来像进展的工作

做这个东西的过程非常爽。Claude Code 和 Codex 这样的编程智能体让每一块都变快了。我写了前端。我写了后端和远程生成音频的 worker 节点。我写了后台管理界面，因为数据库里的节目数据对人来说根本不够直观。我不只做了一套生成流水线，而是做了两套。我还加了一套 eval 流程，用来评估节目质量。

陷阱在于，这些东西没有一个听起来很蠢。我确实需要一个让用户提交信件的地方。我确实需要一套基础流水线，把一封信变成一期完整节目。我也确实需要 eval，因为如果节目本身不好，就根本没有产品可以测试。真正过早的部分不是“用 AI 做产品”。真正过早的部分，是在产品还没有形成运营节奏之前，我已经开始围绕它搭建一整套自己的运营系统。

远程 worker 池、自定义后台管理界面，把发布文案、渠道包装、素材和数据记录都系统化，这些一开始都不必存在。在这个阶段，Codex 可以打理一切。我完全可以让它帮我跑流水线、检查数据、准备上传、写发布文案，把那些围绕产品的笨拙手工活先做起来。

那 300 多个 PR 里，有太多是在自动化我还没有资格自动化的工作：运行节目的机器，管理节目的机器，分发节目的机器。它们都假设了一个我还没有证据会抵达的规模。每一次合并都像一次胜利。仓库在变大，架构在变干净。按照我当时盯着的所有指标，我都非常高产。

反省开始的地方

裂缝出现在我最得意的那台机器上。远程 worker 池负责生成音频，两封信的时候它运行得很好。到了六封信，它就撑不住了。¹1.修复方法几乎有点讽刺。同一套流水线，如果我只是打开一个本地 Codex session，让它帮我一封一封跑，反而更容易运行，也更容易控制。花了几周搭起来的远程基础设施，输给了一个我可以手动完成的流程。

这个失败让我看清了问题。最自然的工程反应，是给机器加资源，把队列做扎实，继续打磨基础设施。但那只是在重复同一个错误。worker 池确实失败了，但更深的失败是，我依然把基础设施质量当成瓶颈。在这个阶段，真正的业务问题不是“我能不能搭出一套漂亮的远程生成系统？”真正的业务问题是：“我能不能拿到真实的信，把它们做成好节目，并且让陌生人愿意等下一期？”

手动跑完流程之后，我终于问出了那个我一直忙到没空问的问题：这一切到底是为了什么？

电台是一家媒体公司，而媒体公司很容易描述，也很难真正做起来。它靠两件事活着：一边是值得回复的信，一边是愿意收听的人。除此之外，代码、服务器、流水线，全都只是为了连接这两件事。成功不是系统跑通。成功是形成留存：有人愿意投信，也有人愿意持续收听。

我花了三个月做供给和需求之外的几乎所有东西。我还没有验证，能不能让十个陌生人在我不用逐个解释完整愿景的情况下提交信件。我还没有验证，十个不认识我的人会不会听完一期节目、分享它，或者问我下一期什么时候出。我已经给供给和需求搭好了连接机器，但供给和需求本身还没有存在。

我跳过的核心环节

我本来应该先做的东西很小。一个可以提交信件的页面。一条能把信变成节目的流水线。一点足够判断节目好坏的 eval。一个手动发布的方式。就这些。

它不需要自动化。我本来可以手动收集真实信件，一封一封跑流水线，用 AI 修音频、写营销文案，然后自己把节目上传到 YouTube 或 Spotify。整个业务都可以先手动跑起来，大概一周就够了。而且它会同时测试供给和需求：人们会不会写？人们会不会听？

所以错误就在这里，用工厂这个比喻会变得很明显。我在还没有做出一期陌生人愿意听完的节目、也还不知道有没有人愿意等下一期之前，就先建了一座美丽的自动化工厂：机器、传送带、控制室，一应俱全。自动化是用来放大已经成立的东西的。我却把它当成了避免验证它是否成立的方式。工厂是需求被证明之后的奖励，不是验证需求的替代品。

我之所以会掉进去，原因只有一个：建工厂太便宜了。放在以前，我根本不会尝试做这些东西。每一块都太耗时间，而这种成本会逼我取舍。智能体把成本拿掉了。当逼你排序优先级的摩擦消失之后，就没有什么能阻止你把所有东西都做出来。于是我把所有东西都做出来了，并把这种运动感叫作进展。

我学到的东西

如果你现在也在用智能体做东西，我希望你认真想一想这一点。

用智能体一路往前 ship 的感觉，可能是你这辈子最“高产”的时候，而且这种感觉并不是假的。这些工具真的很强。但也正因为它们太顺手，它们会移除过去保护你不要过早规模化的工程痛感。Vibe coding 可以变成有史以来最舒服的拖延方式。它看起来像最硬的工作，所以你很难意识到，你其实是在用它逃避更硬的工作：去发现到底有没有人想要这个东西。

代码从来不是产品最核心的瓶颈，现在就更不是了。所以不要再用代码数量给自己打分。在 0 到 1 的阶段，生产力应该是你了解市场的速度。让智能体去生产真正的内容、发布它、把它放到真实的人面前。让市场，而不是 backlog，决定下一个 PR。

人们会告诉你要 “do things that don't scale”，他们是对的。但这句话通常被讲成一种技巧，一段你通往“真正产品”之前必须经过的阶段。²2.Paul Graham, Do Things That Don't Scale (2013).

这次我终于明白，这句话真正重要的地方不只是“先用笨办法撑过早期”，而是它指出了做产品真正发生的地方。工厂不是产品。产品是你做出来的东西和想要它的人之间的匹配，是一边的信件和另一边的听众之间形成的关系。而这种匹配，只能通过接触市场找到。

Paul Graham 在 2013 年讲的这件事是对的。到了 2026 年，它更重要了，而不是更不重要。因为智能体已经把那条错误的路，也就是去建机器，变得几乎免费，而且真的很好玩。盯住供给和需求的纪律，从来没有像今天这样容易丢掉。

我还在学习。接下来，我要手动跑通最小核心循环：拿到真实的信，做出一期好节目，把它发布到人们真的能听到的地方，然后看看有没有人回信。剩下的东西，等市场要求我时，我再建。