一个早上，和三件不该存在的东西
有一天早上我起来，泡咖啡，打开笔记本，看到夜里跑的几个 agent 都停在了完成状态：一个给我的小工具加了完整的多语言支持，中英日三套文案，抽了 i18n 层；一个给博客做了阅读进度统计；一个把我半年前写的 CLI 重构成了插件架构。代码都很干净，测试都是绿的。
我坐在那儿看了大概十分钟，然后把其中两件回滚了。那个工具的用户我认识一大半，全是中文用户，没有一个人问过英文版；那个 CLI 一共有三个命令，半年没加过新功能，我给一个没有生态的东西建了一套生态基础设施。留下的那一件也不是因为它对，是因为回滚它比留着更麻烦。
这不是 AI 干得不好——这三件事拿去做 code review，每一件都能过。它们的问题不在实现层面，在更早的地方：它们根本不该被排进队列。 而排进队列这件事是我自己干的：前一天晚上，我花了二十分钟，一边刷手机一边跟模型聊天，把几个模糊的念头「整理」成了三个结构清晰、听起来很专业的工单。整个过程愉快得像在做规划。
这是《超级个体的装备栈》系列的第三篇。总纲 里我把装备分成四层，判断标准只有一个：这层装备的进步，是只帮你，还是同时帮你所有的竞争者。上一篇 讲生产层，结论是「配到够用就停手」，因为它的每一次进步都是全行业同步发放的公共品。
这一篇讲第三层，判断层。整个系列如果只读一篇，我希望是这篇。
执行成本趋零，放大的是做错方向的代价
先说一个我认为被系统性搞反的因果关系。大部分人对「AI 让执行变便宜」的直觉反应是：那试错成本就低了啊，多试几次呗，反正错了也不亏。这个推论听起来天经地义，但它漏掉了一个关键变量。
在旧世界，建一个东西要三个月。你在第 0 天判断错了方向，接下来的三个月里你会不停地撞到现实：第 3 周发现某个核心假设需要用户配合而用户不配合，第 6 周拿半成品给人看对方礼貌地「嗯」了一声，第 9 周你自己开始怀疑这件事的意义。漫长的建造过程本身，就是一个持续给你送反馈的通道——很多方向错误是在中途被自己发现并中止的，从来没有变成完整的沉没成本。三个月的建造周期不只是成本，它同时是缓冲。
在新世界，建一个东西要三小时。你在第 0 分钟判断错了，三小时后它建完了，中途没有任何一个时间点让你停下来问「等等，这事儿有意义吗」——因为根本没有中途。你的错误判断以全额、无损耗的形式，直接变成了一个完成品。 更糟的是第二阶效应：因为速度快，你会同时排三五个任务，等第一个错误的产出摆在你面前、你意识到方向不对的时候，另外几个已经跑完了。你不是错一次，你是在醒悟之前已经错了五次。
画成图是这样，它是这一层所有推论的起点：
旧世界（建造 = 3 个月）
判断 ──┬──────────────────────────────────────┬──► 交付
│ 第3周 第6周 第9周 │
│ ▲ ▲ ▲ │
│ 撞墙 冷场 自我怀疑 │
└── 建造过程本身在持续送反馈 ───────────┘
→ 大量错误方向在中途自动夭折
→ 沉没成本 = 部分
新世界（建造 = 3 小时）
判断 ──────────────────────────────────► 交付（当晚）
└─ 无中途、无撞墙、无冷场、无怀疑 ─┘
→ 错误方向 100% 走完全程
→ 沉没成本 = 全额
而且它是这样的：
一次错误判断
├──► agent A ──► 完成品（错）
├──► agent B ──► 完成品（错）
├──► agent C ──► 完成品（错）
└──► agent D ──► 完成品（错）
▲
并行度把单次判断失误乘了 4 倍
所以我的结论跟流行说法是反的：执行变便宜没有降低试错成本，它把试错成本从「建造成本」转移到了「判断成本」，而且转移的过程中还放大了一次。 试错成本从来不只是「建它花了多少钱」，它还包括你付出的注意力、留下的维护负担、以及最贵的一项——它占掉的那个本来可以用来做对的事的时段。
DORA 2025 的报告里有一句话我一直记着，大意是：AI 不修复团队，它放大团队。这句话对个人同样成立，而且更狠。AI 放大的是你已有的判断质量——包括你判断里的糊涂。
需求通胀：这套系统最危险的一环
在旧世界，「提需求」这件事本身是有成本的。你要把一个模糊的念头写成别人能理解的东西：要解决什么问题、边界在哪、怎么算做完。这件事累到很多念头在写成文档的过程中就自己死掉了——你写到一半发现，哎，这事儿好像也没那么重要。「把想法写清楚」这个动作，长期以来兼职扮演着需求过滤器，它靠的是摩擦力，而摩擦力不是 bug，是这个系统里唯一免费的筛子。
AI 把这个摩擦力抹掉了。现在你只需要一句「我想给这个工具加个多语言支持」，模型就会返回一份结构完整的规格，写得比你自己写的好，三分钟一份，一晚上能生产二十份。这就是需求通胀，机制和货币通胀几乎一样：当发行成本趋近于零，发行量会失控，而每一单位的含金量会下降。
危险的地方在于，通胀里的每一张「钞票」看起来都是真的。如果 AI 生成的需求都是明显的胡说八道，那你一眼就否了；问题在于它们全都合理——多语言支持、阅读统计、插件架构，每一条单独拿出来看都站得住，甚至有点专业。合理和值得做，是两件完全不同的事，而 AI 只保证前者。
模型被问「这个功能该怎么做」的时候会认真地帮你做，它不会反问「你确定要做这个吗」。它没有你的机会成本函数，它只有你给的那个上下文，而那里通常已经预设了这件事要做。
再叠加一层机制，通胀就完成了闭环：
模糊的念头
│
│ ← 旧世界：这里有一道摩擦力（写清楚很累）
│ 很多念头死在这一步
▼
AI 三分钟整理成规格
│ ← 摩擦力被抹平，念头 100% 通过
▼
看起来很专业的工单 ← 「专业的外观」本身产生了合法性
│ 你会因为它写得好而高估它的价值
▼
排进队列（几乎无阻力）
│
▼
agent 忠实执行 ← agent 不怀疑，它只交付
│
▼
完成品 + 维护负担 + 你的注意力被占用
│
└──► 你的系统变复杂了，但你没有变得更接近目标
最后那个箭头是这套东西真正的代价。不是「浪费了几小时算力」，是你的系统在无声地变复杂：每一个不该存在的功能都在给未来的每一次改动加税。我踩过的最实在的坑是那个 i18n 层，回滚它比加它麻烦得多，因为它已经渗进了十几个文件——加一个东西是 agent 的活，去掉一个东西是你的活。
图里那句「专业的外观本身产生合法性」也值得单独强调：你会不自觉地把「这份文档质量高」翻译成「这个需求经过论证了」。但文档质量来自模型，论证来自你，而你只花了三分钟。
需求闸门怎么守
下面这几个方法是我这一年试下来留下的——不是因为它们高明，是因为它们够笨，笨到我在最想偷懒的时候还执行得下去。
一份「不做什么」的清单
我现在有一份文件，叫 NOT-DOING.md，放在项目根目录，和 README 平级。里面写的不是待办，是明确决定不做的东西，每条附一句为什么。比如我的博客项目里躺着这么几条：
- 不做评论系统。理由：我要的是写作，不是运营互动；有邮件和 GitHub 就够了。
- 不做站内全文搜索的自建索引。理由：站点体量下，用户实际路径是搜索引擎进来，不是站内找。
- 不做多语言自动翻译。理由：英文版要的是重写不是翻译，自动翻译会污染质量信号。
这份清单的作用不在写的那一刻，在三个月后。三个月后我一定会重新想起评论系统——人的念头是循环的，同一个想法会在你脑子里反复投胎；没有这份清单，我会把它当成新想法兴致勃勃地重新论证一遍，可能这次就通过了。不做清单的本质是给未来的自己留证据，防止同一个坏想法靠着遗忘反复入侵。
要写得具体。写「不做过度工程」没用，任何人都能把想做的事解释成「不是过度工程」；要写「不做评论系统」这种能被证伪的。
in-flight 数量上限
第二条更简单粗暴：同时在跑的任务，设一个硬上限。 我给自己定的是 2。不是 5，不是 10，是 2。
这个数字听起来低得可笑——尤其在到处都在讲「并行编排十个 agent」的语境里。但我是这么算的：瓶颈不在 agent 那边，在我这边。我一天能真正认真 review 的产出，大概就是两到三件。 不是「扫一眼看着没问题」的那种，是真的把它读懂、想清楚它对系统影响的那种。上一篇提过：执行速度上去之后瓶颈会转移到 review 带宽，而 review 带宽几乎无法用同样的方式扩张。如果我同时开五个，结果不是「我做了五件事」，是「我用扫一眼的质量 review 了五件事」。
宁可少而准。 操作纪律是：想开第三个任务的时候，先关掉一个，要么合并要么放弃，不许挂着——挂着的任务会腐烂，两周后回来看它就成了一个陌生人写的东西。
上限还有一个隐形好处：它把选择的痛苦提前了。当你只能同时做两件事，你就必须在排队的时候真的做取舍。闸门的价值恰恰在于它必须让你难受一下。不让你难受的闸门不是闸门，是走廊。
「这件事不做会怎样」
第三个是提问方式的调整，成本最低，效果最好。排任何一个任务之前，我强迫自己回答一个反向问题：如果这件事永远不做，会发生什么？
不是问「做了有什么好处」——这个问题永远有答案，任何事情做了都有好处，这就是它没用的原因。拿那天早上的阅读进度统计试试：不做会怎样？答：我不知道读者读到哪儿了。那我知道了会怎样？答：呃……我大概会调整文章长度？那我现在不知道，就不能调整长度了吗？答：也能。判决：不做。
这个问法的特点是：它逼你说出一个具体的、坏的后果。 说不出来，或者要绕两层才能编出来，那这件事就是可以不做的。
它还有个变体，对付「架构类」需求特别有效：这件事推迟三个月做，成本会变高吗？ 如果答案是「不会」，那就推迟。软件里绝大多数「早晚要做」的架构改造，推迟的成本是被严重高估的——因为你在推迟的三个月里学到的东西，会让你做得比现在好。真正不能推迟的只有那些会造成数据丢失、安全漏洞、或者需要用户迁移的东西。
把 AI 定位成「把想法结构化」，而不是「决定做什么」
最后一条是定位问题，也是最重要的一条。我很清楚地划一条线：
AI 负责把我已经决定要做的事，变成一份严谨的规格。它不负责决定做什么。
线的这边（我的活）：这件事该不该存在、为谁做、不做会怎样、在我这三个月的方向里排第几。线的那边（AI 的活）：既然要做，那么它的边界在哪、有哪些我没想到的情况、验收标准怎么写才可证伪。
在线的那边，模型强得离谱。 它比我更能穷举边界条件，更能把一句「加个导出功能」拆成十二条明确的行为描述。而在线的这边，模型的输出对我几乎没有价值。 不是因为它笨，是因为它缺的是信息而不是能力：它不知道我这三个月想站在哪，不知道哪个用户的抱怨让我记了半年。这些东西我没法完整地喂给它——不是懒得喂，是我自己也说不清楚。
所以我把这两件事在时间上分开：决定做什么的时候，不开 AI。 先自己在一个空白文档里写下要做什么和为什么，写完了再打开模型说「帮我把这个变成规格」。
顺序颠倒过来的后果我领教过：先开着 AI 聊，聊着聊着它给我列了五个「可以考虑的方向」，我从五个里挑了一个，然后有种「我做了选择」的感觉。但那五个选项是它给的。它设定了选择集，我只做了从选择集里挑一个的动作，而真正的判断发生在选择集被设定的那一刻。
验收标准是判断的具体形态
上面讲的都是「做不做」，这一节讲「做成什么样」。我的规则是：一个工单，如果我写不出验收标准，我就不派给 agent。 不是「先派下去，边做边想」，是不派。
理由很直接：写不出验收标准，说明我没想清楚这件事做完之后世界应该长什么样。这个状态下派给 agent，它会替我把没想清楚的部分猜完——它必须猜，因为它得交付一个完整的东西，而它的猜测会以「已完成的代码」的形式呈现出来，看起来跟想清楚了的部分没有任何区别。这就是把糊涂放大：我的模糊变成了它的具体，我的犹豫变成了它的确定，经过一轮转换之后，我甚至看不出哪部分是我想的、哪部分是它猜的。
所以验收标准不是流程官僚，它是判断的可验证形态。判断这个词很虚，虚到你没法知道自己有没有做；验收标准把它落到地面上：写得出来，说明你想清楚了；写不出来，说明你没有。
好的验收标准长什么样
先说坏的。坏的验收标准长这样：
- 用户体验流畅
- 代码质量良好
- 性能没有明显下降
- 兼容现有功能
这四条的共同问题是不可证伪：任何产出都能被论证成满足了它们，也都能被论证成不满足。它们看起来像标准，实际上是四句祝福。好的验收标准有三个特征。
第一，可证伪。 「导出 1 万行数据在 3 秒内完成」是可证伪的，「导出速度快」不是。可证伪的意思是做完之后能得到「是」或「否」，而不是一次讨论。
第二，包含负面用例。 大部分人写验收标准只写「输入 A 应该得到 B」，不写「输入非法的 C 应该拒绝并给出什么提示」。而 agent 的行为特点是：没被要求处理的情况，它会用一种看似合理的方式默默处理掉。 比如吞掉异常返回一个空数组——功能上「正常工作」，问题三周后才以数据不一致的形式冒出来。
第三，包含 AI 不会自发关心的维度。 这一条有实证支撑。Veracode 2025 年的 GenAI 代码安全报告里有一组数据：45% 的代码样本没有通过安全测试；更值得注意的是他们的另一个观察——模型在写「功能正确」的代码上一直在进步，但在写「安全」的代码上没有改善，且跟模型规模无关。这暴露了训练目标和你的目标之间的错位：「能工作」有大量正反馈信号，「不会被利用」的反馈稀疏、延迟，往往根本不出现在训练数据里。
所以「AI 不会自发关心」的那些维度，必须由你显式地写进验收标准。 除了安全，我的清单里通常还有：可观测性（agent 默认写的日志是给自己 debug 用的，不是给三个月后的你用的）、可回滚性（涉及数据结构变更的必须写清楚回滚路径）、依赖增量（「不引入新的运行时依赖」，确实需要就单独论证）、删除量（这个改动能不能顺带删掉点什么——默认情况下 agent 只会加不会减，长期下来系统会单调地膨胀）。
这几条的共同点是：它们的收益是延迟的、分散的、不体现在「这个功能能不能用」上。 而这正是它们不会被自发满足的原因——任何以「交付这个功能」为目标的优化过程，都会自然地把这些东西压到最低。
一个副作用
写验收标准还有个我没预料到的好处：它会杀掉一部分需求。有几次我准备给一个想法写验收标准，写到「做完之后什么变了」这一栏卡住了——不是不知道怎么表达，是发现真的没什么变。那个念头就在写验收标准的过程中死了。这恰好补回了 AI 抹掉的那道摩擦力，只不过这次是我自己重新装上去的。
把判断外化成规则：这一层唯一能复利的部分
到这里为止，讲的都还是「个人能力」：你的品味、你的取舍、你的自律。这些东西的问题在于——它们不复利。 你今天的判断力不会因为你昨天做过判断而自动变强，你也没法把它交给任何人（包括 agent）。总纲里我把判断层称为「半资产」，指的就是这件事。这一节讲能变成资产的那部分，下一节讲不能的。
能变成资产的那部分，方法只有一个：把判断写下来，写到 agent 每次开工都会自动读的地方。
两种东西要分开放
不变的东西，进规则文件。 代码风格、命名约定、测试要求、架构边界、技术选型的红线、错误处理的统一模式。这些是你判断的结晶，它们跨任务成立，不会因为这次做的是导出功能还是登录功能而改变。这次特有的东西，进工单：这个功能要做什么、边界在哪、验收标准是什么。
这个区分带来一个非常实际的好处：当规则文件到位之后，工单可以写得很短。 我现在很多工单就是三五行，因为背景在规则文件里，agent 每次都会读，我不用再重复「记得写测试」「不要引入新依赖」。这些话说一次，永久生效。
这就是复利的具体形态。你每次 review 时发现的问题，如果只是当场改掉，它下次还会出现；如果把它写成一条规则，它就再也不出现了。 前者是消耗，后者是积累。我自己的习惯是：同一个问题纠正第二次的时候，就必须写进规则——第一次可能是偶然，第二次就是模式。这条纪律的好处是它不需要我预先想清楚所有规则，规则是被现实一条条打出来的。
规则要分层，不要堆在一个文件里
规则文件最常见的失败模式，是它变成一个越来越长、什么都往里塞的垃圾场：三个月后它有八百行，一半是过期的，真正重要的红线淹没在噪声里。Claude Code 的官方口径给了一个挺清楚的分层：
CLAUDE.md：每次会话全量加载，所以它有代价——占上下文、占注意力，官方建议控制在 200 行以内。我只放跨所有任务都成立的红线和最高频约定，这个文件应该给人一种「每一条都值得每次都读」的感觉。.claude/rules/：条件加载，可以在 frontmatter 里写paths，按文件路径匹配决定这次要不要加载。规则的相关性本来就是有作用域的，这个机制让规则文件的作用域和它的实际作用域对上了。- Skills：按需加载。适合放那种「偶尔要做、但做的时候有一整套固定流程」的东西，比如发版流程。
分层的核心逻辑是加载成本和使用频率要匹配：把偶尔用的东西放进全量加载区，代价是它稀释了天天用的东西。
一个大量文章写错的细节
顺带说一个坑，因为我看到中英文都有不少文章弄反了：Claude Code 读 CLAUDE.md，不读 AGENTS.md。 AGENTS.md 是 OpenAI 在 2025 年 8 月发布、2025 年 12 月捐给 Agentic AI Foundation 的跨工具约定，采用规模 6 万多个开源项目；官方给的桥接方案是在 CLAUDE.md 里用 @AGENTS.md import 它。
这个细节本身不重要，重要的是它背后那件事：规则文件正在从「某个工具的配置」变成「项目的一部分」。 一旦规则跟着仓库走而不是跟着工具走，它就真的变成资产了。
最后补一句提醒：规则会过期，留在文件里会持续消耗上下文，还会误导 agent 基于过时前提做判断。规则文件的删除操作，和代码的删除操作一样重要，而且一样没人愿意做。
规则装不下的那一半
接下来必须诚实地说清楚边界，否则这篇会变成一个虚假的承诺：能被写成规则的只是判断的一部分，而且很可能是不那么重要的那部分。 我试着把这条界线画清楚：
判断层
┌────────────────────────────────────┐
│ │
│ 可外化（能进规则文件、能复利） │
│ ───────────────────────────── │
│ · 代码风格、命名、目录约定 │
│ · 测试要求与覆盖底线 │
│ · 架构边界（谁不能依赖谁） │
│ · 依赖引入的红线 │
│ · 安全 / 可观测性 / 回滚的检查项 │
│ · 「做过一次的错」→ 规则 │
│ │
│ 特征：跨任务成立、可证伪、 │
│ 能被文字完整表达 │
├────────────────────────────────────┤
│ │
│ 不可外化（只能长在人身上） │
│ ───────────────────────────── │
│ · 这个东西值不值得存在 │
│ · 该为谁做、不该为谁做 │
│ · 什么时候该停、什么时候该砍 │
│ · 简洁和完备之间怎么取 │
│ · 什么算「好」 │
│ │
│ 特征：依赖具体情境、随时间变化、 │
│ 写下来就失真 │
└────────────────────────────────────┘
│
└──► 这一半是 AI 抹不平的原因，
也是它没法被交出去的原因
上半部分能复利，下半部分不能。而下半部分决定的事情，比上半部分大得多：代码风格写错了，代价是每个文件多几个不好看的地方；「这个东西该不该存在」判断错了，代价是三个月。但只有前者能被写进文件。
为什么后者写不下来？答案大概是：这类判断的输入是无穷维的，而文字是有限维的。「这个功能值不值得做」依赖于你现在的用户是谁、他们真正的痛点在哪（而不是他们说的）、你三个月后想站在什么位置、以及你今天的状态。这里面大半是隐性知识——你能用它做判断，但说不清它是什么，也就是波兰尼说的：我们知道的比我们能说出来的多。
你可以写一条规则叫「优先做用户明确要求过的功能」，听起来不错。但有时候用户要求的功能是错的——他们描述的是想象中的解法，不是他们的问题，这时候你要违反自己写的规则。而**「什么时候该违反规则」本身没法写成规则**，写了就变成新规则，需要新例外，无限递归。
所以我对这一层的态度是：规则是判断的沉淀物，不是判断的替代品——它不是让你不用判断，是让判断集中在还需要判断的地方。
agent 需要有人照料
Every 的做法在这件事上是个很好的例子，因为它是一个真实的组织在真实规模上试出来的结论，而不是谁的观点。
Dan Shipper 在 2026 年 5 月的一篇文章里复盘了 Every 的 agent 实践。他们最初给每个员工配一个 agent——这完全符合「超级个体」的直觉。后来他们把这个做法撤回了，改成 agent 归属团队或者公司，由专职的 AI 工程师维护，原因很朴素：个人 agent 会迅速腐化。Shipper 的核心主张大意是：现在的 AI agent 要想真的有用，它需要有一个在乎它的人；agent 离那个负责让它工作良好的人越远，它工作得越差。
这跟「AI 让每个人都能拥有一个团队」的叙事是拧着的，但非常符合我自己的体感。agent 的效果不取决于模型有多强，取决于有没有人在持续照料它的上下文——规则有没有更新、过期的东西有没有删掉、新踩的坑有没有沉淀进去。没有人做，agent 就会慢慢退化成一个执行着三个月前过时约定的东西，而且退化是无声的：它不报错，只是产出越来越偏离你想要的东西。
顺带说一句，Every 那期播客的标题是「We Automated Everything With AI and Tripled Our Headcount」——自动化没有减少对人的需要，它把人做的事情从「执行」变成了「照料判断」。
命中率：判断力唯一诚实的检验标准
最后一节讲一个更根本的问题：你怎么知道自己的判断力好不好？ 大部分人的答案是回顾成功案例——我做的这个成了，说明我判断对了。这个答案不成立，理由太熟了，幸存者偏差。但这个概念被说得太多以至于失去了力量，所以我想用一组更硬的材料来讲，硬在它是由成功者本人给出的。
一个 5% 的命中率
Pieter Levels 大概是这个时代最被当作「超级个体」范本的人。他有一条推文，大意是：他做过的 70 多个项目里只有 4 个赚到了钱并且长起来，他做过的一切里超过 95% 都失败了，命中率只有大约 5%；所以——多发布。
这是我见过的最有说服力的反幸存者偏差材料，因为这句话不是失败者的自我安慰，是一个已经站在山顶上的人回头指着山下那一堆残骸说：那些也都是我。
5% 意味着，即便你的判断力已经好到能长期把这件事做下去，你依然会在 20 次里错 19 次。 如果你的心理预期是「我要判断准」，那你会在第 3 次失败的时候开始怀疑自己，在第 8 次的时候放弃。而按 5% 的命中率，第 8 次失败什么信息都没有提供。很多人不是判断力不行，是他们对自己的判断力有一个错误的基准线，然后按这个错误的基准线过早地退出了。
fly.pieter.com 和一个必须说清楚的细节
同一个人身上还有一个更常被引用的案例。2025 年 2 月，Levels 用 Cursor 加 Claude 加 Grok 3，在大约三小时里做出了一个飞行模拟器的原型。这个东西从 0 做到 100 万美元年度经常性收入用了 17 天，月收入到了 8.7 万美元，32 万人玩过。这个故事被引用了无数次，用法通常是「看，AI 时代三小时能造出百万美元生意」。
但这个案例里有一个几乎从不被提及的细节，而它恰恰是最重要的：这个东西的收入模式主要是游戏内的广告位，不是订阅。 广告位收入依赖的是注意力峰值——那段时间它在社交媒体上极度火爆，32 万人涌进来，广告位因此值钱。它卖的其实不是软件，是一个短期的注意力窗口。
所以这个案例真正证明的是：当你已经有了巨大的分发能力和声誉存量（恰好是这个系列的第二层和第一层），一次成功的注意力捕获可以在极短时间内变现。 三小时那部分是这个故事里最不重要、也最容易被复制的部分。
我特意不去引用这个产品一年之后的收入数字，因为我找不到可靠来源。在一个大家都在用数字讲故事的领域里，「我不知道」是一个需要被保护的答案。
54% 挂零，以及这个数字本身的幸存者偏差
再补一组更冷的数据。ScrapingFish 抓取过 Indie Hackers 上 937 个接入了 Stripe 营收验证的产品，结果：超过 54% 的产品营收为零，只有大约 5% 的产品月收入超过约 8333 美元。这个 5% 和 Levels 给出的命中率是同一个量级——两个独立来源指向同一个数量级，多少说明点什么。
但更值得说的是这个数据集本身的偏差。 它统计的是已经做完了产品、已经主动上架、并且愿意接入 Stripe 做营收验证的人，这三个动作里的每一个都是一道筛子。绝大多数「我要做个产品」的想法根本走不到第一道筛子面前——它们死在了「做了一半放弃了」「做完了没上线」这些阶段，根本不在分母里。
所以「54% 挂零」不是悲观的数字，是乐观的下限。这个元层面的观察比数据本身更有价值：你能看到的所有关于成功率的数据，都已经经过了至少一轮筛选，而筛选的方向永远是让数字变好看。 这不是谁在造假，是数据的生成机制本身就带着这个偏向——失败的人不发帖，放弃的项目不接 Stripe。
所以目标不是「每次都对」
如果命中率的天花板就在 5% 附近，那么把判断层的目标设成「提高命中率」是很低效的——能改善的空间有限，而且反馈周期长到你根本没法从中学习。我认为正确的目标是三件事。
第一，错得便宜：让每一次错误的方向消耗尽可能少的资源——更简单的架构、更小的初始范围、更少的前置投入。Levels 那套单文件 PHP、无框架、SQLite、单机部署的技术栈在工程审美上会被很多人嫌弃，但在 5% 命中率这个前提下它极其合理。这也是极简架构真正的论点：不是「简单更优雅」这种审美主张，是在高失败率的游戏里，架构的第一目标是降低单次失败的成本。复杂架构做的恰恰相反——它提高了每个项目的沉没成本，从而提高了你放弃一个明显不行的项目的心理门槛。架构复杂度会转化成沉没成本谬误的燃料。
第二，错得快：让错误尽可能早地暴露，这意味着尽早接触真实用户，而不是尽早写完代码。「三小时做完」和「三小时知道它不行」是完全不同的两件事，后者才是有价值的那个。 很多人用 AI 加速的是前者，结果是错误的暴露时间没变，只是错误的产出变多了。
第三，能从错里回收资产。 这一条最重要，而且它把这篇文章接回了总纲 ——四层之间是有方向的：生产层的每一次产出，都应该往下沉淀成分发层和声誉层的资产，而这个方向在「失败」的场景下才真正显出价值。
一个项目失败了，如果你只有那个项目本身，那你就是归零。但如果你在做的过程中写了一篇复盘文章、抽出了一个能复用的组件、把踩的坑沉淀成了规则文件里的三条约定——那么这个项目在「产品」这个维度上是零，在其他三个维度上不是零。
一次失败的项目
产品维度 ─────────────────► 0 （95% 的情况）
│
├──► 判断层：规则文件 +3 条 （下次不会再犯）
├──► 分发层：一篇复盘文章 （带来读者）
├──► 声誉层：一次公开的诚实 （讲失败比讲成功建立更多信任）
└──► 生产层：一个可复用组件 （下次冷启动更快）
→ 命中率还是 5%，但每次未命中的净损失显著变小
→ 而且第 N 次尝试的起点，高于第 1 次
这才是「多发布」这个建议真正成立的条件。 Levels 说 ship more，很多人理解成「多做几个碰运气」——但如果每次失败都是纯粹的归零，那只是在同一个 5% 上多抽几次签，期望值不变。多发布之所以有意义，是因为每一次发布都在给非产品的那三层充值。
所以判断层最终指向的不是「我这次判断对不对」，而是「我这次判断错了的话，还剩下什么」。能诚实地回答这个问题，比提高命中率现实得多。
一些我还没想清楚的地方
按惯例，把这篇里我自己不确定的部分摊开说。
第一，in-flight 上限设成 2 可能只是我的 review 能力上限，不是普遍规律。 一个有更好自动化验收体系的人可能安全地跑到 5 或者 8。真正该被推荐的不是这个数字，是那个方法：找到你自己认真 review 的上限，然后按那个数字设闸门，而不是按 agent 的并行能力设。
第二，我可能低估了模型在「决定做什么」这一侧的潜力。 这条线是基于我现在给模型的上下文画的。如果一个模型真的能读到我全部的项目历史和过去的决策记录，它的方向判断会好多少？我的直觉是会好不少但仍然不够——因为最关键的输入是「我想成为什么」，而这个东西连我自己都在变。但直觉不是论证。
第三，「不可外化的判断」这个界线可能在往下移动。 我五年前会说「代码风格是品味，写不下来」，现在它明确在可外化那一侧。我接受这个可能性，但不会因此在今天放弃这一层——界线正在移动的时候，站在它前面比站在后面更危险。
第四，5% 命中率这个数字的适用范围可能很窄。 一个做垂直行业工具、有稳定客户来源的人命中率可能高得多。判断力的检验标准应该按你所处的游戏调整。
第五，也是最让我不安的一条：把判断外化成规则，会不会反过来削弱判断力。 当所有已经想清楚的东西都被写进文件、不再需要每次重新思考，我会不会慢慢丧失重新思考它们的能力？规则文件里那条「不引入新依赖」，三年后我还记得当初为什么定它吗？我倾向于认为收益大于风险，但没有办法验证。
写在最后
写这篇的过程中，我删掉过一整节。那一节讲的是「怎么用 AI 帮你做需求优先级排序」，有打分维度、有权重、有模板。写完之后我读了一遍，然后意识到：我在写的东西，正是这篇文章批判的东西。 它的本质是把「决定做什么」包装成一个流程然后交出去，看起来很有操作性，但它做的是让你产生「我判断过了」的感觉——打分表最擅长的，就是把一个艰难的取舍变成一次算术，让人跳过那个必须难受一下的时刻。
删掉它之后我才想明白这篇文章真正的主张是什么：判断这件事，没有办法被减轻。
你能减轻的是它周边的东西——把已经想清楚的固化成规则，把重复的检查变成清单，把结构化的工作交给模型。但中间那个核心「这个东西值不值得存在」不能被减轻，只能被承担。 任何声称能减轻它的方法，大概率是在帮你把它藏起来。
这也是为什么这一层在总纲里被称为「半资产」：一半能沉淀，一半只能长在你身上，而后面那一半，恰好是决定你去哪儿的那一半。
AI 抹平了执行。它把成本从「建它要多久」转移到了「该不该建」，而后者不接受外包。在一个执行免费的世界里，你为之付费的东西，是你的方向感。
下一篇讲分发层——四层里唯一还在复利的产能。好产品在建造成本高的时代是稀缺的，所以「酒香不怕巷子深」有几分道理；在建造成本趋零的时代它不再稀缺，稀缺的变成了被看见。我会讲怎么把做产品的过程本身变成内容管道，以及你的内容能不能被模型读到、理解、并被引用。
那一层跟这一层有个隐蔽的连接：判断错了的项目，正是分发层最好的原料。 讲成功的人太多，讲清楚自己为什么错的人太少，而后者建立的信任更结实。
下一篇 见。
读者回响