agent 写代码之后，审查要问哪一层检查能接住哪类错

agent 写代码的速度提上来之后，第一个撑不住的环节就是代码审查。Anthropic 的 monorepo 在 2026 年 5 月每天大约合并 2,500 个改动，到 9 月已经超过 30,000 个。在这个量级下，“每一行都有人读过”已经不再现实；继续把它当成目标，只会让人越审越累。

我现在的判断是：审查要问的问题得换掉。不再问“有没有人读过”，而是问“这次改动可能坏在哪里，哪一层检查（自动化的或人工的）最适合接住它”。与 agent 协作时，信任也要建立在它交出来的证据上，而不是建立在你陪它聊了多少轮上。

人的时间要算两笔账

Claude Code 团队把人的时间算作双向成本：一笔是审 PR 的时间，另一笔是修坏代码的时间。如果只压缩第一笔，而第二笔没降下来，人的时间其实并没有省下，只是从审查挪到了事后救火。

所以他们的目标是两句话连在一起说的：在 Claude Code 的各个仓库里，大多数 PR 合并时最多只有一个人在环（这个人可以就是作者本人），同时 revert 率和事故率不能上升。后半句是护栏。一旦护栏指标变差，就说明人力只是换了个地方消耗。

结果是，6 月到 9 月合进 Claude Code 的 PR 数量翻了一倍多，而需要 revert 的 PR 占比却下降了 40% 以上。他们并没有停止审查，而是把大部分“读代码”的工作交给了自动化流程，同时投入精力让回滚变得又快又容易。

先交出证明，再谈审查

审查的重头戏其实发生在 PR 提出来之前。不要让 agent 只说一句“做完了”，而是让它跑出看得见的结果：跑测试、执行构建、拿截图和设计稿做对照。然后再用一个上下文干净的子 agent 审一遍 diff。Claude Code 的作者 Boris Cherny 估计，给 Claude 配上验证流程后，产出质量大约能提高两到三倍。

Thorsten Ball 在《How I work with Agents》里把这件事说得更直接：要拿到不可反驳的证明。端到端的演示、录屏、改动前后的对比数字，这些都是 agent 很擅长的。他还建议在 AGENTS.md 里明确写清楚“什么不算证据”。

与这一条相配套的，是别陪着 agent 来回试错。不要说“试试这个……不行，再试试那个”，而是让它一次性生成 20 个变体，再附带一个能组合、对比的小页面；排查性能问题时，让它先给出 4 个变慢的假设原因，再把这 4 个原因逐一验证一遍。让迭代发生在 agent 自己搭建的实验工具里，而不是发生在你的聊天回合里。

这里还有一个前提：agent 看不见的东西，它就会瞎编。工具调用之所以能压住幻觉，正是因为它让 agent 接触到了真实环境。所以凡是人能看到的东西——生产日志、部署状态、发布流程、feature flag、bug 报告——都要尽量让 agent 也能看到。

一条改动要穿过好几层检查

在 Claude Code 团队，一条改动从作者的开发环境到最终上线，大概要过下面这些关：

1. PR 前验证：跑测试、构建、截图对照，外加找 bug、缩小 diff、端到端验证等内部 skill。
2. 每个 PR 先过 AI 审查，再给人看。由多个 agent 并行找 bug，再通过投票过滤误报，纯代码风格类的意见会被直接筛掉。
3. 能阻断合并的安全审查，只要有未关闭的问题就不能合入。
4. 阻断式的自动化检查：lint、类型检查、全平台测试、构建。
5. 按风险分档的人工审批。
6. merge queue、feature flag 和分阶段发布。

在这六层之外，还有最后一道防线：快速发现问题，快速回滚。

每一层都会漏掉一些问题，但很少有问题能同时穿透所有层。这里最值得借鉴的是第五层的原则：审查档位由改动本身决定，而不由作者身份决定。改文档和改自动更新器，风险根本不在一个级别。计费逻辑、CI 配置、被负责人标记为敏感的路径，永远需要人工批准。bot 的批准不能代替人的批准；只要有新提交进来，之前的批准就自动作废。

如果同一类问题被反复标出来，就要去源头解决：改 skill、加 lint 规则，或者更新 CLAUDE.md 和写给审查器看的 REVIEW.md，而不是每次都指望靠人再读一遍来发现。

agent 互审必须能收敛

agent 写代码、agent 审代码，很可能会陷入无限循环。他们就遇到过一个 CLI 的 PR，一夜之间来回拉扯了 50 多轮，最后还是靠人手动叫停的。用 git blame 一查，审查系统反复标出的问题里，大约 59% 在第一轮时就已经存在了。它几乎没在找新 bug，只是每一轮多翻出几个老问题而已。

人关掉一条 nit 只需要一秒钟，但交给 agent 去处理，就会变成一个新 commit 外加新一轮审查。为此他们修改了规则：三轮之后，要求作者重新评估整体方案；前几轮过后，只审新增的 diff；报问题时要说明属于哪一类错误，让作者一次性改完同类问题；已经报过的问题不再重复提出。

人留下来做什么

人不再逐行去读琐碎的 diff，但有几件事仍然只能由人来做：

• 判断这件事该不该做。方向、品味、产品目标，是由人来定的。
• 审高危代码：计费、自动更新、CI 工作流。
• 审架构，因为架构选择会变成后续其他人跟着走的约定。
• 核对证明材料：测试输出、跑过的命令、截图、审查意见。如果说不清这些检查会漏掉什么，就不该轻易只给一个 👍。
• 承担责任。每一个上线的改动都要有具体的人负责，不管代码是谁敲出来的。

Claude Code 团队的说法是 "You land it, you own it"：谁合进去的，出了问题就由谁来修。这套机制能运转起来，是因为单次改动小、任何改动都能回滚、爆炸半径越大的代码看的人越多，而且回归问题也能通过内部重度使用和遥测数据被迅速发现。

Thorsten Ball 的标准则更个人化：他只审少于 5 个的核心文件以及数据库迁移。至于用闭包还是用类、类型写得漂不漂亮、变量怎么命名、甚至有没有重复代码，他都不再在意。他只问几个问题：能不能跑通？我能不能在“框和箭头”的架构层面上理解它？agent 有没有做过端到端测试？一个月后我还能不能改得动它？

理解代码库不再靠读 diff

代码审查原本还有一个附带作用：读同事的 diff，是大家熟悉和了解代码库的主要途径。当机器替人读了大部分代码之后，人又该如何理解代码库呢？

Claude Code 团队给出的答案是按需生成说明。没有任何人脑子里装着 Claude Code 的完整代码模型，他们也不认为有人需要这样做。当要修改某一块代码时，先让 Claude 针对那一块写一份 explainer，几分钟就能生成好，而且永远是最新的。逐行去读一行文案改动，其实学不到什么东西；但在改动一个模块之前先读一份针对它的结构说明，反而能收获很多。

我自己的做法

perryOS 也是按这个思路维护的。我让一个主 agent 负责拆解任务、派活和验收，具体的执行交给其他 agent。验收时由主 agent 读 diff，整合时跑一遍全量测试、lint 和类型检查，再抽查一两张关键截图；至于构建、截图、测量尺寸这类机械性的验证，则全部交给负责测试的 agent，只要求它交回最终结论、关键数字和截图路径。

在这套做法里，最管用的就是要求执行方交回切实的证据，而不是只回一句“改好了”。最容易出问题的环节，则是任务描述写得太空泛：执行方会在整个仓库里串行盲目探索，曾经有一个只改单个文件的任务，竟然跑了 23 分钟、发起了 94 次模型请求。所以我现在派活时，都会明确写清楚目标文件、每个改动点要达到的效果、范围边界以及验收标准。这其实和“先说清楚哪一层检查接住什么错”是同一回事，只是把它前置落在了派活这一步。

我还不确定的地方

“大多数 PR 最多一人在环”是 Claude Code 团队在自家仓库里的做法，但这有一个前提：他们拥有完善的 merge queue、feature flag、分阶段发布、一键回滚机制，以及一大批每天都在重度使用自家产品的内部员工。小团队或个人项目如果缺少这些基础设施，靠减少审查省下来的时间，很可能会以线上事故的形式连本带利还回来。

对于 Thorsten Ball 说的“别担心 slop”，我只部分赞同。不逐行去审代码风格问题，这一点我认同；但重复代码和随手增加的抽象层，会让下一个接手的 agent 读错上下文。可维护性的成本，有一部分会转移到 agent 的上下文窗口和 token 消耗上，并不会凭空消失。

低风险改动自动合并，这条边界目前还在继续往前推移。到底哪些改动真的可以完全没人看就合入主干，我手里还没有跑出自己的数据。

接下来想弄清楚的问题

• 一个人维护的项目，最少需要配置哪几层检查，才能安全地少看代码？
• AGENTS.md 里的“什么不算证据”具体应该写哪几条，才能真正挡住 agent 用一句“测试通过”来敷衍了事？
• 怎么通过对照实验来验证 AGENTS.md 和 skill 里写的规则，看看 agent 到底有没有在实际执行？

参考

• 《How the Claude Code team does code review》：Addy Osmani 在 X 上发表，2026 年 10 月 26 日，整理并核对了 Claude Code 团队的代码审查流程。人的时间是双向成本、六层检查加快速回滚、按改动风险分档审批、agent 互审必须收敛、人保留的职责、用 explainer 理解代码库，以及文中所有数字，都来自这篇文章。
• 《How I work with Agents》：Thorsten Ball（Amp）在 X 上发表，2026 年 10 月 25 日。要不可反驳的证明、让 agent 自己搭实验工具而不是陪它来回试、让整个开发流程对 agent 可见、只审高爆炸半径的代码，这几部分观点来自这篇文章。