第 6 章：廉价失败的原则

论点：当一次尝试从几小时降到几分钟，探索的整个经济学就翻转了。best-of-N 不再是奢侈品，而是默认动作——以及它带来的反模式。

相变

AI Agent 之前，每一次"试一下这个功能"都要一个人好几个小时。这个成本塑造每一个决定：你挑最安全的路，你不做冒险的 spike，你不"只是为了比较"再写一版。探索被定量配给。

Agent 跑在三把钥匙上时（第 3–5 章），一次尝试从几分钟到一小时。成本曲线整体挪了一到两个数量级。当执行成本降了一个数量级，"再试一个方案"的决策成本开始超过实际去做的执行成本。

这就是相变。听着像量变，其实是质变。一类以前不合算的策略变得合算了。

以前：决定做什么便宜；做出来贵；所以想清楚再做，一次做对。现在：决定做什么还是要钱；做出来便宜；所以试几个，挑一个。

best-of-N 作为日常动作

直接后果：best-of-N 从偶尔的技巧变成默认动作。

best-of-N 工作流里，你把功能对齐一次（第 3 章）、写一次测试计划（第 4 章），然后启动 N 次并行尝试——可能用不同的 Agent、不同的 prompt、不同的架构假设。每一次尝试都对着同一份测试计划跑。你读赢家、对比、挑一个。

听起来 Agent 成本很贵。是的。但在你的成本上便宜得多，因为：

三次尝试里几乎总有一次先通过测试，你就审那一个。
另外两次给你一份便宜的对比——你看到同一契约下的三种设计选择，三十秒就能看出哪个更顺眼。
三次都失败，那你就学到了关于这个需求的真实东西——一次尝试会把它藏起来。

flowchart LR
  subgraph once["对齐一次"]
    SP[Spec]
    TP[测试计划]
  end
  SP --> W1[Worktree / 尝试 1]
  SP --> W2[Worktree / 尝试 2]
  SP --> W3[Worktree / 尝试 3]
  TP --> W1
  TP --> W2
  TP --> W3
  W1 --> P[对照契约挑胜者]
  W2 --> P
  W3 --> P

best-of-N 尤其好用在：

架构选择模糊时。 不知道对的抽象是什么，让三次尝试告诉你。
风险重构。 安全路径和激进路径并行跑，按测试计划比较。
"我要好那个。" 文案语气、UX 流程——任何你识别质量比指定质量快的地方。

它不好用在：

只有一个对答案的任务（CRUD、有已知成因的 bug 修）。N 次尝试只是浪费算力。
契约本身不清的任务。 best-of-N 在实现上找变异，不在 spec 上找变异。spec 错了，N 次尝试全错。

具体例子——用 git worktree 做并行尝试

今天在真实功能上跑 best-of-N 最便宜的办法，是把廉价失败和第 7 章模式 2 组合起来。具体：

# 对齐需求一次，产出 spec.md 和 prompt_plan.md。
# （见第 3 章的范例——Harper Reed 的流程。）

# 然后对同一功能启动三次并行尝试。
git worktree add ../feature-attempt-a attempt-a
git worktree add ../feature-attempt-b attempt-b
git worktree add ../feature-attempt-c attempt-c

# attempt-a 里：给 Agent spec.md + prompt_plan.md，不加额外指令。
# attempt-b 里：一样的输入，但前置一条把它推向不同架构选择的
#   暗示（"这里偏好状态机，即使重一点"）。
# attempt-c 里：一样的输入，但换一个完全不同的 Agent——
#   例如用 Codex 而不是 Claude Code——获取真正独立的尝试。

每个尝试对同一份测试计划跑。并行启动；墙钟时间大约是一个尝试的时间。当两三个产出绿套件时，你并排读、挑。

多样性诀窍很关键。三次同 Agent、同 prompt、同 spec 的运行会收敛到几乎一样的产出；你学不到东西。真正的杠杆是每次尝试在一个轴上变——Agent、架构暗示、或 temperature——这样尝试之间的差异才承载信息。

Simon Willison 的 Embracing the parallel coding agent lifestyle 和 Mitchell Hashimoto 的 Vibing a Non-Trivial Ghostty Feature 都描述了对着同一 spec 跑并行尝试，目的正是看不同 Agent 的方差——哪一个实现更干净，哪一个抓到了别的漏掉的边缘情形。那份方差就是你用额外算力买来的商品。

"探索成为默认"这个转变

廉价失败还有第二个、更隐蔽、在我看来更重要的后果。

旧经济学里，你有一个模糊想法——"不知道是不是该从方案 A 切到方案 B"——找出答案的成本是写一版 B，那意味着几天到几周，那意味着你几乎总不做。问题就没了答案。方案粘住是因为没人查得起。

新经济学里，找答案是一次三十分钟的 Agent 跑。大多数模糊想法都能查。这改变了决策的节奏：你不再用辩论来解决"要不要"，你用便宜的实验。一个第四阶段的工程师一天里就能用实际证据解决的架构辩论，比过去团队一个季度还多——不是因为工程师更聪明，而是因为"找出来"的成本曲线塌掉了。

这才是真正的生产力增益，它不会被任何"每天写几行代码"的指标捕捉到。它被"每周带实际证据做多少决定"捕捉。

廉价失败带来的反模式

每一次相变都制造新的失败方式。这里最常见的两个：

反模式 1：跳过需求对齐，因为"试几次就行"

这是第一阶段的失败。"干嘛花三十分钟对齐需求，我跑三个 Agent 挑最好的不就行了？"回答：因为三个 Agent 都会对着模糊需求的不同误解产出自洽的工作。你会得到三份能跑的实现，分别对应三个微妙不同的功能，而三选一是在三个你都不想要的东西里选。

廉价失败是好对齐之上的杠杆。它不替代对齐。 第 3 章没做好，第 6 章反而有害。

反模式 2：用 best-of-N 代替测试计划

"我挑看起来最好的那个。" UI 语气上行，正确性上不行。没有测试计划，"最好"塌成"能编译且看起来熟悉的"——那是 Agent 最喜欢的尝试，不是对的那个。第 4 章是第 6 章的前置；跳过它让 best-of-N 退化成审美投票。

反模式 3：永远跑 N

N 次可以。N + M 次、追逐完美实现，是一种烧算力的坏习惯，边际回报递减。实践里，方差重要的场景，N = 2 或 3 覆盖 90%；超过 3，边际尝试几乎不改变选择。经验法则：如果前两次尝试有实质分歧，跑第三次破平票；如果它们一致，一次就够了。

反模式 4：忘了人的瓶颈还在

三次并行尝试产出三个你仍然要比较的东西。如果比较时间等于读一版的三倍，你刚把审查负担翻了三倍。修复是要么（a）让测试计划替你比较（三个都绿了；按测试结果或代码美学信号挑）要么（b）别在你没法快速比较的任务上用 best-of-N。

成本估算，粗略

给一个第三阶段及以上的工作工程师，粗略数字：

一次 Agent 尝试在一个中等功能上：30–90 分钟 Agent 时间，约 1–5 美元算力。
三次并行：同墙钟、3 倍 Agent 时间、3 倍算力、同人类在对齐 + 测试计划阶段的注意力、选阶段多 20%。
"三次尝试里有一次教你关于问题的新事"的期望值：难量化，但经验上，新颖工作上高、常规工作上低。

主导成本不是算力。是你的人类注意力预算里有没有"看三个东西而不是一个"的空间。相应规划。

与调度模式的关系

best-of-N 是第 7 章四种并行模式之一，但它和另外三个有一个关键差异：另外三种模式并行的是不同任务；best-of-N 并行的是同一任务的替代尝试。

实践中，成熟的并行工作流会同时用两者。你可能有三个 Agent 在三个不同功能上（第 7 章模式 2），并且在其中一个功能里有三次 best-of-N 尝试（本章）。那就是九个 Agent 运行同时在跑。第 8 章会讲这造成的产出洪水。

外部声音

支持：ML 从业者在模型输出上做 best-of-N 采样已有多年；把同样模式应用到任务级是自然推广。Chase-Lambert、Anthropic 等讨论过"多稿一选"的工作流；Geoffrey Huntley 关于 agent-of-agents 模式的帖子触及同一领域。
反驳：一些从业者警告 best-of-N 可能掩盖系统性错误（如果 N 次尝试都共享模型的盲点，你高置信度地选了"最好的错"）。这是真实批评，缓解是多样性——不同 Agent、不同 prompt、不同起始架构——而不是同 prompt 跑 N 次。

第 7 章讲四种并行 Agent 调度模式——从跨项目协调（最粗）到 Agent 内部并行（最细）——以及哪种模式匹配哪个磨合阶段。

并行开发：如何让多个 AI Agent 并行推进而质量不崩塌