Addy Osmani 两年前给过一条建议：评审 AI 生成的每一行代码。今天他说不必了。变更仍然需要评审，「人逐行细读」只是不再提供评审的唯一方式，也不总是最好的方式。这篇文章回答两件事：什么有资格接替阅读，以及没有东西接替时会发生什么。
评审从来主要不是为了找 bug
2013 年微软研究者问开发者为什么做评审，答案第一名是发现缺陷。但评论本身讲的是另一个故事：被归类的 570 条评审评论里只有 14% 与缺陷有关，其余是教学、同步上下文、建议更好的做法、维持团队规范。评审的隐性职能一直比抓 bug 宽，「机器会来评审」也因此是个比听起来更弱的答案——机器正在变强的恰好是抓 bug 那一小块。
Anthropic 的内部数据给了一个刻度：自动 Claude 评审员跑在几乎每个 PR 上，工程师标记为错误的比例不足 1%；它上线后，得到实质性评审意见的 PR 占比从 16% 升到 54%。它不批准任何合并——「那仍然是人的决定」。一项回顾性分析估计，对每个变更做全量自动评审，本可以提前拦下 claude.ai 过去事故背后约三分之一的 bug。三分之一的另一面是个不舒服的事实：剩下的 bug 大多穿过了盯着 diff 细看的人。在生产中出事的代码，在 diff 里往往看起来没问题。
两个成本决定一切
这篇文章的分析主线是一对成本：检查没人读过的工作的成本，和撤销检查漏掉的失败的成本。一个团队、一个行业何时停止逐行读代码，取决于这两项各自的斜率，而不是任何一方的宣言。语言模型无法像旧式代码生成器那样通过认证——同样的输入不保证同样的输出——所以信任只能来自围绕它搭起来的检查。软件与自动驾驶的分野也在这里（Karpathy 的「每个 9 都是一份恒定的工作量」）：网页应用可以躲在功能开关后面、盯着错误率、几分钟内回滚，汽车回滚不了一次碰撞。大量软件可以从模型周边的系统里买到它的 9，不必从模型本身买。
作者的预测分层：消费软件、内部工具与多数 SaaS，两年内对常规变更逐行细读会变得罕见，但人仍然批准并拥有它；企业与金融软件，三到五年内审批从 diff 转向证据；飞控与最高风险医疗设备，很多年内继续逐行读——监管者不会只凭合格检查就接受安全关键代码。
当阅读停止而没有东西接替
同一周有两篇刷屏的帖子：Thorsten Ball 说代码评审会死，一位入职大厂两周的工程师自述整天对着没人读的代码按回车。作者认为两者不矛盾：一个描述终点，一个描述公司没修路就开到终点的样子。那个团队把速度放进了信任原来的位置，信任没有挪进任何检查。第一项成本被做成零，迟早连本带利支付第二项。
顺序也不是偶然。工具通常自下而上传播，这种工作方式是自上而下强加的。回想评审在做的事——教学、让人知晓变更、让团队把持自己的质量标准——命令一个团队停止阅读，移走的不只是一道缺陷检查，还告诉他们标准不再由他们把持。可行的版本则无聊得多：每个 PR 先过一遍多智能体评审（找 bug、验证、按严重度排序、给出修法），爆炸半径小的低敏感变更在第一遍干净后做轻量人审，核心路径仍由所有者细读；无论哪种，人批准合并。智能体做第一遍，人类覆盖爆炸半径。赢的团队不是什么都不读的团队，而是知道什么值得读的团队。
把人放进这个循环里却不给权，就得到 Madeleine Clare Elish 所说的道德缓冲区：像车的缓冲区一样，吸收冲击的恰恰是边上的人。按回车十三小时的工程师站在缓冲区里——批准记录上是他的名字；节奏、检查和什么值得读的决定都发生在别处。出事时，事故调查总会找到那个批准的人。
测试的权威从哪来
对 Ball 清单最有力的反问是：单元测试是「你确信的系统行为」对「你不完全信任的未来的自己」的约束——如果写代码的东西连测试也写，测试在证明什么？Anthropic 的奖励黑客研究里出现过模型学会调用 sys.exit(0) 让测试框架在任何断言失败前退出。
被测者写的测试证明不了多少。
出路是问测试的权威来自哪里。航空业的答案是独立性：DO-178C 要求最关键的验证由作者之外的对象完成，合格的工具可以算一个。让一个 Claude 写测试、另一个写代码，能拦住最粗糙的失败，但同一模型的两个副本共享同一批盲区。真正的独立性来自不同的真理源：人写的规格、参考实现、形式化证明。
Nicholas Carlini 用十六个 Claude 智能体、近两千个会话、不到两万美元做出十万行能编译出可启动 Linux 的 Rust 编译器，他最大的教训关于检查器而非智能体：「任务验证器近乎完美，否则 Claude 会解决错误的问题」——内核卡住时，他用 GCC 作为已知良好的参照物逼出每个 bug。SQLite 走得更远：约 15.6 万行 C，测试代码是它的 590 倍。所以作者把 Ball 的话改成：作为「写给未来自己的便条」的单元测试会贬值，因为改代码的不再是你；作为对不完全信任作者的独立检查的测试，将是你拥有的最有价值的代码。
这与本站《代码上道》的结论同构：智能体可以生产一切，但「似是而非」变成「可信」的那道闸必须由人拥有。昂贵缺陷向来住在接缝处——Ariane 5 的规格里没有新弹道，火星气候探测者的两个团队一个用磅力秒一个期望牛顿秒。模型今天最弱的恰是在接缝处选择目标的判断。剩下的工作从打字变成判断；只接工单、转给智能体、汇报结果却不加任何自己判断的角色，才是真正在消失的。
好代码的新定义
纯为人服务的部分——格式化之类——不再重要，但有些性质对智能体比对人类更重要：可 grep 的唯一命名、装得进上下文窗口的小模块、失败方式清晰的测试、部件之间清楚的边界。没有这些，智能体照样能改，只是看不见改动波及什么。好代码现在是：智能体改它时不会弄坏它看不见的东西。
开源会演变而非死亡：curl 在 2026 年 1 月结束漏洞赏金时抱怨 AI 垃圾报告爆炸，三个月后真实漏洞率回归正常而报告量翻倍——垃圾问题变成了容量问题。最值得分享的东西随之转移：生产昂贵、核对方便宜的资产，测试套件、规格、什么坏过过的记录。
如果你是按回车的那个人
- 动手前写下要建什么、不能破坏什么、怎么算成功。不必长，判断力现在放在这里，这也是你日后指得出来的工作。想找回成就感的人，都把成就感放在了决策里。
- 用「我能解释它吗」当测试：不必读过每一行，但要说得出这个改动做什么、碰到哪里、为什么可以发布。人只能为自己能解释的东西负责。
- 诚实标注没读的部分。在 PR 描述里写「智能体评审通过，测试通过，迁移逻辑我没读」。藏起读得少这件事的团队，没法修复它。
- 保持手感。Anthropic 研究者描述过「监督悖论」：监督好 Claude 需要的恰是再也不用就会退化的编码技能。他们的工程师会刻意不时徒手解决问题。早期职业生涯尤其值得照做。
如果你定节奏
- 问责需要授权。要工程师为变更失败担责，就得让他对节奏和「事先理解多少」有发言权。让一个人为自己没定过的节奏、没时间读懂的代码负责，就是帖子里的「人肉代理」：不公平，也起不到控制作用。
- 度量发布了什么，不是发布了多少。合并数和代码行数正是把按回车变成全部工作的那两个数字。看事故、回滚、恢复时间和用户的真实体验。
- 为理解做预算。写代码不再是瓶颈，读和评估才是。逐区域决定每次变更需要多少人类注意力，再围绕它排计划。
- 要求人签署的东西保持人的尺寸。一份一百页的生成报告没人读得完，和五千行没人读的 diff 是同一个问题。要一页纸的版本不是不配合，那就是评审。