用AI Agent交付产品：人只保留决策权

最近，一个 Agent 只用了几天时间，就做出了 MERIDIAN 的可用原型。它有一个实时页面——展示我去过哪里、现在在哪里、接下来要去哪里——还有一张世界地图。应用会读取照片库中的 EXIF 数据，在设备本地自动绘制地图，全程不需要手动输入。Expo、React Native、一张黑色 SVG 地图。一年前需要密集开发一周的前端功能，现在当天就能进行截图测试。

这种速度带来了什么？它没有消除风险，而是转移了风险。过去代码成本高昂，最重要的问题是：“我们能不能把它做出来？”现在，构建产品几乎不需要成本，只剩下一个代价高昂的问题：我做的真的是正确的东西吗？风险已经从“把它做出来”，转移到了“决定该做什么”。

因此，我重新设计了自己的产品工作方式。重点不再是谁来写代码——现在代码要多少有多少——而是谁来决定哪些代码值得写。我自己几乎不再动手写代码，而是把任务交给 Agent，然后检查并取舍。下面就是这套系统的运作方式。目的不是“看看我的系统多厉害”，而是给你一套可以直接照搬的方法。

Agent 做什么，以及什么事情我绝不交给任何人

整个工作被拆分成多个部分。每个部分都有一个 Agent 负责承担工作量，同时也有一部分由我自己保留。两者之间的界线，就是这份工作的全部意义。

探索。Agent 会搜索市场、竞争对手、用户对话，以及我自己的笔记归档，从中提炼出那些我根本来不及亲自阅读的信息。我只给自己保留一个问题：这些模式中，哪些是我愿意相信的，哪些只是听起来不错。

假设。一个 Agent 产出二十个功能方案的速度，比我写出一个还快。产量归它，品味归我：这二十个方案里，哪两个真正值得碰一碰。

决策与优先级。在这里，Agent 是陪练，而不是裁判。它会根据我真正掌握的信息对假设进行排序，与我辩论，并寻找漏洞。最终的取舍——什么进入 roadmap，什么被扔进垃圾桶——由我决定。这种决定不可逆，所以不能委派。

构建。Claude Code 和其他 Agent 负责写代码、做设计、定义 schema。我审阅它们的产出，就像资深工程师审阅初级工程师的 PR：关注的不是“它能不能运行”，而是“这个工作量评估是不是在撒谎，它是不是偷工减料，埋下了一个月后就会爆炸的问题”。我是从工程领域转到产品的——最初写 JavaScript 和 React，后来做 tech lead 和工程管理——如今这些经历成了一种工具：因为我写过代码，所以能识别代码里的谎言。

审查。另一个独立的 Agent 会专门攻击第一个 Agent 构建的东西。它的职责是找出系统会在哪里崩溃。后面会详细解释——这是整套系统的核心。

编排。这一层负责把前面五个部分组织起来：哪个 Agent 处理哪个任务、按什么顺序执行、需要提供什么上下文。这就是 Yan OS——构建在 Claude Code 之上的一层系统：项目、Agent、schema、hook、定时运行，以及少量 MCP。只有一名指挥者：我。

注意，我没有交给 Agent 的事情包括：决定该相信什么、对 roadmap 做最终取舍，以及检查他人的工作是否在撒谎。其他事情都只是工作量，而工作量现在已经很便宜了。

一个 Agent 如何识破另一个 Agent 的谎言

任由一个 Agent 独立工作，它会自信地撒谎。它生成一个假设，为它寻找理由，然后像陈述事实一样把它端到你面前——语气和陈述真相时没有任何区别。因此，在我的系统中，负责生成内容和负责检查内容的是两个不同的 Agent。它们之间还有一套简单的分类方法。每一项论断——无论来自我、用户还是 Agent——都会被放进以下三个桶之一：

• 已知——真实数据、真实行为，或者能够持续成立的模式。

• 看起来像——一种信号，但不是证据。

• 希望它是真的——一种愿望，目前尚未得到证实。

任何被归入“希望它是真的”的内容，都必须附带一项测试：要么证实，要么否决。没有任何未经标记的内容可以直接进入构建阶段——而且我自己的直觉要接受最严格的检查，因为它的声音最大。

这套方法真正帮我省事的地方在于：一个 Agent 提出某项功能，并写道“用户想要 X”。第二个 Agent 回到信息源进行核查，发现所谓的“想要”，不过是某次聊天中的一个帖子。这其实属于“看起来像”，却被包装成了“已知”。如果没有第二个 Agent，这个“想要”就会披着数据的外衣混进 roadmap。有了它，这项想法就必须先接受测试，然后等待结果。成本只有几分钱，却能捕获代价最高昂的一类错误：伪装成事实、充满自信的谎言。

MERIDIAN 的速度暴露了什么

回到那个原型，因为整件事的关键都在这里。

在 MERIDIAN 之前，我否决了上一个假设——Nomad Bridge，一个面向数字游民的双边 marketplace。它没能通过我自己的拆解：它有供需两端，而且双方从第一天起就必须同时存在，这是会杀死 marketplace 的经典冷启动问题；此外，我能找到的付费需求都只是类比推测，而不是证据。在那个被放弃的产品里，曾有一个我从未认真对待的小功能——一个带有地图的个人主页，用来展示你去过哪些国家。我把它和其他所有东西一起扔掉了。

之后，我花了一个月寻找下一个方向。大约 350 个想法，和 Agent 一起进行了九轮探索，而几乎每一轮都会反复出现同一个主题——那张记录移动轨迹的地图。这个功能其实早已在我手里，只是我没有看见。

关键就在这里。Agent 只用几天就完成了原型——而恰恰是这种速度，让我意识到最困难的部分从来不是代码。真正困难的是，我花了一个月在电子表格中给 350 个想法打分，却差点错过了口袋里已经拥有的东西。代码成本高昂时，缓慢的构建过程会掩盖你头脑里的错误——你花了太久时间构建，以至于根本没有注意到自己做错了东西。当构建速度变快，唯一真正的工作就赤裸裸地显现出来：决定什么东西值得构建。

它会在哪里失效（没有这一部分，前面就只是一则广告）

现在说点实话，否则上面的一切都只是一面漂亮的商品橱窗。

这套系统的客户就是我。只有一个用户，而这个用户同时也是开发者，也是需要使用它的人。这意味着，它带来的收益还没有得到数据证明——唯一能够证明的，只是它更适合我，而这是最薄弱的一种证据。Yan OS 尚未完成，而且说实话，由于它本身的性质，它永远也不会真正完成。

其次，Agent 很喜欢自己提出的想法。由同一个模型生成的第二个 Agent，往往也会比应有的程度更喜欢第一个 Agent 的想法。因此，最终的刀仍然握在我手里，而不是交给第二个 Agent：它可以减少谎言，却无法把谎言降到零。

上下文需要消耗金钱和注意力。要让 Agent 做出良好判断，你必须向它提供正确的上下文；而收集这些上下文并让它们保持最新，本身就是一项工作。没人会计算这项工作，直到它悄无声息地吞掉速度带来的收益。一套能在构建阶段节省数小时的系统，很容易通过后门把这些时间重新拿走——你会把时间花在整理和驾驭上下文上。

最重要的是，在没有任何参照物可供检查的地方，我无法被替代。当存在一个可以用来对照答案的参照时，Agent 的表现非常出色。但如果没有任何东西可以比较——当问题是“我正在构建的东西真的是正确的吗”，而市场尚未给出答案——最终起决定作用的就是品味、承担风险的意愿，以及是否愿意连续多年扛着一个产品走下去。这些暂时还无法移交。整套系统都建立在这一点之上——这里有更进一步的讨论：当构建变得便宜，判断才是真正的工作。

团队雇用一个人时，究竟在购买什么

把这些放在一起看。当设计和代码几乎免费时，一个团队雇用产品人员，买的就不再是一双按照 spec 执行任务的手。现在已经有了用不完的手，而且它们比任何一名员工都便宜。

真正被购买的，恰恰是那些我没有交给 Agent 的能力：决定应该相信什么、有纪律地否决自己的假设，以及识别那些听起来像事实的谎言。团队需要的不是一个能更快写出 PRD 的人，而是一个能管理编写 PRD 的 Agent，并且知道其中哪一个值得真正构建的人。

我独自一人借助 Agent 构建了这套系统——就像我在零广告支出的情况下，独自运营 Unicorn Embassy 三年一样。构建成本降到了几乎为零。唯一变得更加昂贵的，是判断。

我是 Yan Nerovny，Unicorn Embassy 的产品负责人和创始人。我在 nerovny.com/writing 写产品、AI，以及如何在任何地方构建产品。

你也在亲自使用 Agent 做产品吗？这套方法中最值得借鉴的，就是三桶分类法——已知／看起来像／希望它是真的。欢迎通过 Telegram 或 LinkedIn 告诉我，它在你那里会在哪里失效。

你还可以考虑屏蔽此人和／或举报滥用行为。