让不确定的 Agent 产出确定性的结果
用确定性的基建，把不确定的 Agent 包围起来
前言
几十个 Agent 在一个三百多万行、二十六个客户端产品的仓库里并行改代码， 单日峰值合入五十二次，没有人逐行看过 diff。
在没有人逐行看的情况下，凭什么敢合。
这个问题不是一开始就有的。一个人写、一个人审的时候， 产出和判定花的是同一个人的同一段时间，两者天然匹配。 Agent 把产出那一侧的成本压掉了一个数量级，判定那一侧没有跟着降 —— 于是瓶颈从”写不写得出来”变成了”敢不敢合”。 第一章讲这个转移在实测数据上长什么样，以及它连着撞过的两堵墙。
这件事能成立，靠的不是 Agent 变可靠了。它每次给出的代码都不一样， 你也没法要求它一样 —— 一个功能有很多种正确实现，逼它收敛到一种， 等于把它降级成模板引擎，那还不如直接写模板。
靠的是换一个承诺：不承诺同样的代码，只承诺同样的判定边界 （3.2 承诺同样的判定边界）。每一次产出都用同一套证据判断它算不算数， 而这套证据不依赖任何人当时的状态 —— 不依赖谁记得、谁在场、谁今天累不累。
“同一套证据”不是比喻，它是一组能跑的东西：一次测试的执行结果、 一次依赖图查询、一条规则扫过的文件数、一个不为零的退出码。 它们的共同点是结论跟谁来跑无关 —— 换个人、换台机器、隔一个月，答案一样。 十几万字讲的就是这条边界怎么建、怎么让它自己不腐化， 以及它在哪里按定义就够不着。
这些机制是撞出来的
没有一条是设计出来的。所以书里会反复出现同一个句式： 先描述一次真实的失败，再讲那次失败留下了什么。 你会看到失败，也会看到我当时错误的判断 —— 后者比前者有用， 因为一个错误的诊断会把你带到一个看起来合理、实际没用的修法上， 那种弯路比失败本身更贵。
数字都取自那个正在运行的系统，样本窗口和样本量我会随手标出来。 里面也包括我自己没做到的几处：一个挂了四个月没人发现的崩溃、 一处违反我自己纪律的轮询代码、一个在七次事故里重复了五次才被提上来的机制。 它们留在书里，是因为它们恰好是最结实的几段证据 —— 它们证明的正是我想讲的那条规律。
还有一件得先说清楚：书里所有的数字都是过程指标 —— 拦截率、失败率、从红灯到转绿的时长。 真正能验证这套体系的那个数，是合并之后才被发现的问题占多少， 而它不在，因为它没有被测量（21.1.1 一、缺陷逃逸率没有被测量 会摊开讲）。 所以我能给你的是一套可以照着建的机制， 加上它们在一个真实系统上按设计工作的证据 —— 不是”它让质量变好了”的证据。这两者的差别值多少，你自己判断。
有一层是后加的。这套东西我最初解释成一套”检查”， 用了很久才发现因果讲反了：检查不产生质量，它只是让质量变得可以确认。 再往后才意识到整件事是一个标准的闭环控制系统，只是我当时没有那套语言。 第四部补的就是这一层。它是全书唯一不从事故里长出来的一部， 价值在于预测那些我还没撞过的墙。
我不讲什么
提示词怎么写。 它重要，但不是这里的问题 —— 如果一个系统只能靠提示词把质量托住，那它还没建好。
哪个模型更好。 这里的每一条结论，换一个模型仍然成立。
做什么产品。 那个问题按定义就在这套系统的能力之外， 20 参考输入在环外 会说明为什么。