信任不在代码审查里

信任不在代码审查里

原文：*Trust Doesn't Live in Code Review*

作者：TennyZhuang (@zty0826)

发布时间：2026-07-01 10:57 UTC

互动数据：💬 4 🔁 9 ❤️ 72 🔖 80 👀 15570

核心判断

这篇文章的主张很硬：在 agent 写代码已经快过人类阅读代码的时代，传统 code review 不再是信任的主要容器。人继续逐行读 diff，看起来是在守住质量，实际上往往只是把自己变成整个团队排队等待的节流阀；如果放行得太快，review 又退化成橡皮图章，制造一种更危险的假信任。

作者不是说人类责任消失了，也不是说代码没人读了。他的区分是：不能外包的是控制权和可信判断；可以外包的是逐行阅读这件低层动作。 diff 审查曾经只是获得信任的代理手段，不是信任本身。agent-native 项目需要的不是“更努力地读下一份 diff”，而是持续读取系统信号，判断系统整体是否仍然可预测。

译述

1. 你曾经是那道闸门

过去的代码审查隐含一个前提：人写代码和人读代码的速度大体处在同一个量级。资深工程师读一个初级工程师的 diff，通常能跟上。这让 review 自然承担了两件事：抓 bug，以及让团队共享对系统的理解。

agent 改变了这个速度结构。一个 agent 下午能产出的代码，可能比一个团队一周能认真读完的还多。于是团队面前只剩两个坏选项：坚持逐行读完，自己就成了全队吞吐的瓶颈；直接放行，review 就变成盖章。真正糟糕的不是漏掉某个 bug，而是团队以为自己仍然“有审查，所以可信”。这种感觉会按节奏批量生产假信心。

作者把核心问题重新定义为：你真正需要的不是阅读动作，而是对项目的控制感和有根基的信任。阅读 diff 只是一个代理指标。现在代理指标失效了，就要回到真正目标：你是否知道自己正在发布什么，系统是否仍然在你的判断范围内。

2. 如果你已经写不了它，也就读不了它

一个人之所以能做好 review，不是因为他天生仔细，而是因为他的手长期在代码里，足够多的实现细节还活在脑子里。阅读只是这种“活理解”的外在表现。如果他不再亲手构建这套系统，那么逐行阅读就容易变成眼睛扫过文本的空动作。

agent 时代的问题不是人类代码质量突然变差，而是人类和 agent 的成本模型不同。agent 迭代的边际成本接近零；人类手写代码会变成慢车道。更深一层，代码库会逐渐结晶成某种成本模型下的一千个小判断：哪里值得抽象，哪里该加日志，重复到什么程度必须重构，边界该落在哪里。agent 如果持续主导实现，代码库会长出 agent 的颗粒度；人类偶尔插手写一段“按另一种成本模型优化”的代码，可能会破坏这种一致性。

因此，在作者设想的特定 regime 里，一旦项目真正 agent-native，且 agent 在该领域至少和人一样强，人类就不再真正“能写”那套代码。既然不能以同样的节奏和颗粒度写，也就很难保有足够的现场理解去审。方向、目标、风险、取舍仍属于人；底层实现颗粒度则会落到实际支付代码成本的一方。

3. 更快的代码，也会带来更快的软件腐烂

作者把软件腐烂解释为一种熵。一个年轻、紧致的系统里，能通过同一组测试的实现空间还比较小；一个长期无照料的系统里，越来越多相互不一致的实现也能通过同样的测试。绿色检查并不意味着系统仍然清晰，只可能意味着测试还没有描述出真正的行为边界。

这并不是新现象。Lehman 早在 1970 年代就讨论过使用中的程序会持续增加复杂性，除非有人投入真实工作把复杂性压回去。agent 没有发明软件熵，它只是升高了温度：过去限制熵增速度的是人类写和读代码的速度；现在这个限速器被移除了。

信任在这里被重新定义为预测能力：你能不能在改动这里之前，大致判断那里会发生什么。diff 只能展示一次局部变化，而预测是系统整体的性质。所以真正的问题不是某个 diff 是否正确，而是整个系统的熵是否正在上升。

4. 别再只读 diff，开始读系统

如果信任来自系统整体的可预测性，那么信号也必须来自系统整体。作者列出了一组比 diff 更适合读取“系统是否仍然收得住”的信号：

• bug 列表：bug 在哪里聚集，哪里就是系统已经泄漏的位置。同一个模块反复出事，同一份契约不断长出新边界条件，往往说明接口、约束或规格没有表达清楚。
• agent 失败：agent 的错误通常能反指输入不干净的位置。人类会凭习惯补洞，agent 会径直踩进去，把模糊契约、遗漏 case、误导性边界暴露出来。
• mutation testing：把一个条件翻转、删掉一个分支，看测试是否变红。存活下来的 mutant 表示测试仍然祝福了一个错误版本的程序。
• 静态结构：分支过厚的函数、重复的事实来源、长期冲突的边界，都是未来破裂的起点。
• 多 agent 冲突：真正重要的不是两个 agent 同时改了相邻代码，而是它们反复争夺同一个边界；这通常说明边界本身画错了。

这些信号还会告诉你该把测试框架指向哪里。bug 密集、分支最深、边界最混乱的区域，也是未知 bug 最可能藏身的区域。测试的目的不是堆 coverage 数字，而是把那些纠缠区域里的失败逼出来。一个 bug 只有在对应测试经历红到绿之后，才算真正被钉住。

但作者也警告：绿色测试不是免费的质量。测试只有在断言够硬时才有意义：它必须检查真实行为、真实 payload，并覆盖行为真正经过的路径。只检查代码形状而不检查效果的测试，只是一盏没有接线的绿灯。安静的 bug 列表也可能只是没人用那个模块，或者监控本身失明。任何信号都必须先证明“它在该响的时候会响”，才值得信任。

5. 审查是事件，信任是状态

文章标题的关键句落在这里：review 是一次事件，trust 是一种状态。事件发生一次，留下一个 verdict，然后消失；它不会自动累积成你对系统的持续预测能力。信任需要连续信号来累积，而不是一次次盖章。

所以，阅读代码并不会消失，而是移动到理解真正所在的地方。在 agent 时代，最贴近实现细节的是写代码的 agent，而不是站在 gate 前的人类。高风险场景也不是靠疲惫的人类扫一眼更安全：安全边界、不可逆发布、生产回滚，更应该依赖类型系统无法违反的性质、硬断言、分阶段发布和能抓到回归的监控。

作者进一步把失败视为诊断输入，而不是模型能力的判决。一个 surviving mutant 指向无人钉住的行为；一个漂移的边界指向不再表达单一含义的契约；一个 bug cluster 可能说明模块接口在误导任何试图使用它的系统。失败的尽头通常不是“模型太弱”，而是某个输入条件不够干净：规格不够清楚、验证面没搭好、边界画得太软。

6. 人的工作变成读信号、追因、收紧输入

作者最后把新实践压缩成一句话：停止守门，开始阅读系统，并一轮轮收紧它的输入。

有时这意味着写更锋利的 spec；有时意味着重构误导模型的接口；更强的时候，意味着改变设计，让坏状态在类型或结构上不可表示。并非所有失败都能这样消掉：外部服务不响应、凭证问题、竞态和时序问题仍然需要硬检查、监控和分阶段发布。可方向是明确的：系统变得更可信，不是因为有人读了更多行代码，而是因为每一次失败都被花出去，用来让下一轮条件更真实。

这也留下了下一篇文章的问题：如果人不再是 gate，甚至不再是读代码的那个人；如果人的一天变成读取系统、收紧输入、设计约束，那么人类在软件工程里的工作究竟是什么？

对我这里最有用的抽象

• code review 不是信任本体，只是旧时代的信任代理。 当写入速度和阅读速度脱钩，代理会失效。
• 信任 = 可预测性。 一个系统是否可信，取决于你能不能预测它在跨模块、跨版本、跨输入下的行为。
• 测试必须证明自己会失败。 没有经历过“该红时会红”的测试，只是装饰性绿灯。
• agent 失败是输入质量诊断器。 它经常不是暴露“agent 笨”，而是暴露 spec、接口、测试面和边界不干净。
• 人的位置上移。 人不该消失，而应该从逐行 gatekeeper 变成系统信号、边界、输入和不可外包判断的拥有者。

与本 vault 的关联

• [[wiki/Harness Engineering]]：本文把“验证与实现同速”“结构化信号”“确定性流水线”推进到 code review 领域，说明 harness 的核心不是让 agent 多写，而是让系统持续可预测。
• [[wiki/Agent Loop]]：作者的实践其实是把 review 从一次事件改造成连续 loop：读取信号、定位熵增、收紧输入，再进入下一轮。
• [[wiki/Oracle（判定者）]]：mutation testing、硬断言、类型系统、监控和分阶段发布，都是比人工扫 diff 更可靠的 oracle。
• [[raw/翻译/Agentic 代码审查 — Addy Osmani]]：Addy 关注“AI 时代怎样重构 code review 流程”，本文更进一步：当项目 agent-native 后，review 本身可能应该从 diff gate 迁移到 system-reading。