Agent 代码评审 · 精华速读
四个改进里，三个是少让人看代码
Claude Code 团队 6 月到 9 月合并 PR 翻了一番，回滚占比反而降了 40% 以上。他们没取消评审，而是把阅读交给机器、把人的时间留给只有人能做判断的地方，同时把「撤销」做得足够便宜。代价是：评审从终点前的一道闸门，变成写作过程中持续运行的拼写检查。
30 秒速览
记住这 5 句就够了
- 换问题
别问「有人读过代码吗」，改问「这次改动可能怎么坏，哪道检查能抓住它」。这一问把评审从终点闸门挪到了写作过程里。
- 机器读
大多数改动在人看之前，已经被 Claude 至少审过一轮：多 agent 找 bug，另一组投票，够票才发出来。
- 按险配
风险档由变更本身定，不由作者定：低风险自动合并、中风险 1 人、高风险 2 人；敏感路径永远要人。
- 会失控
agent 作者 + agent 审查能互相耗不完。一个 PR 一夜跑了 50 多轮，最后是作者手动叫停。
- 看护栏
省下的人工时间必须用回滚率、事故率验收；这两个数一涨，时间没省，只是搬了家。
第 1 层
评审的目的变了，时机也跟着变了
Anthropic monorepo 每日落地变更：5 月到 9 月
内部 PR 获得实质性评审意见的比例（研究预览上线时）
Claude Code 自身代码中由 Claude 撰写的比例
原文把评审拆成两件事：发布前发现并修复问题，以及让团队共享对代码库的理解。前一件机器能做，后一件不能——文章前半讲机器怎么接，结尾回来讲人怎么学。
We think "did a human read the code?" is an imprecise proxy for "what could go wrong with this change, and which check—automated or human—is the right one to catch it?"
原文 · Rethinking the purpose of code review
换掉这个问题之后，评审的时间点也换了：以前是写完代码、开 PR、等同事看；现在评审持续运行，更像边写边做的拼写检查，多数改动在人被叫来看之前已经审过并改过一轮。
第 2 层
人工批准按风险分级，多给一层就多花钱
| 风险 | 典型变更 | 需要几个人批准 |
|---|---|---|
| 低 | 文档、文案、仅内部的功能、开关后面的增量改动 | 自动评审与安全检查通过后，零人 |
| 中 | 普通产品改动；缓存、自动更新、system prompt 等敏感区域 | 1 人 |
| 高 | 最高风险代码，以及一小批永远需要两人的路径 | 2 人 |
两个分类器配合：第一个读变更定档，第二个再问「即便档位说不用，这一次是否仍需多一个人」。另有三条硬规则把它锁住——永远需要人的路径（owner 标记为敏感的、任何 CI workflow 文件）；只有仓库受信名单上的作者能走轻路径，其余人要第二个人；agent 的批准永远不算人的批准，AI 可以清掉一个低风险改动，但填不了需要人的那个格子。
批准只对某一个具体 commit 有效；来了系统无法背书的提交（比如 agent 推送、有人手工解冲突），批准要重给。另外，驱动 agent 干活的那个人，算必需评审人之一，和他自己敲代码时一样。
第 1 层到第 7 层的分工见 Fig. 1。值得注意的是这两处失败闭环：安全审查和代码审查的任何未解决意见都可以阻止合并，你只能修掉，或者写一句理由把 thread 关掉（这是清掉误报的方式）；后续提交若真的修好了，意见会自己消失。每条意见都必须有回应——经常是 agent 夜里就把修复做完了，作者回来时 PR 已经又过了一轮。
审查者常年抱怨同一件事时，改源头而不是重说一遍
原文的做法是把重复意见前移到三层配置里：skill、lint 规则、以及像 CLAUDE.md 和 REVIEW.md 这样的说明文件。
CLAUDE.md
告诉 Claude 项目是什么：技术栈、约定、目标与非目标。每次评审都会加载，所以大代码库里要保持短，其余指向别的文档。审查者也会标出破坏约定的代码，以及让某一行过期的改动。
REVIEW.md
由 code owner 写：这份代码里什么算失败（文档是「它在说谎」，配置是「它路由错了」）、限制 nits 数量、列出可跳过的路径、要求给出文件与行号而不是凭名字猜。摘要以数量开头，没东西可修就直说。
Skill 与 lint
内部有三个常用 skill：一个专门找 bug，一个简化 diff，一个端到端验证行为。UI 改动还要按设计规范检查一遍。
原文在这里给了一条最有杠杆的习惯：给 Claude 一个它能跑的东西（测试、构建、可与设计稿对比的截图），并要求它拿输出说话，而不是说「我做完了」；然后让一个 subagent 用全新上下文再审这个 diff。创建者 Boris Cherny 称这是拿到好结果「大概最重要的一件事」，估计能让最终结果好两到三倍。
第 3 层
评审必须收敛，否则两个 agent 会互相耗着
失控的形态很具体：agent 写、agent 审，两边可以永远忙下去。一个 CLI PR 过夜跑了五十多轮评审和修复，作者才叫停。团队对反复被标记的代码跑 git blame，发现约 59% 是首轮评审时就已经存在的旧代码——审查者并不是在发现新 bug，只是每轮又多翻出几条老的。
而且团队自己加重了这个问题：他们习惯了默认多跑几轮，因为每一轮总能抓到点什么。这在有风险的改动上值得，但不是每个 PR 都值得。他们把「通过轮次」和召回率一起盯着，改了四件事：三轮封顶后请作者回头重想方案；之后的复审只看新 diff；发现某类 bug 就标出类别，让作者一次修完所有实例而不是改一行；已经发过的意见不再重发。另外还有每晚在既有代码上跑的评审，专门提前抓老 bug。
噪音也要量化：如果不在乎误报，多抓 bug 很容易。他们把审查者留下的每条评论按人的反应分类（改了、说错了、说这是有意为之、判断不重要），还在已知干净的 PR 上跑审查者，统计它报出「会让人做出有害改动」的频率。写下来的优先级是：先抓真 bug，其次减少评审轮次。噪音在作者是 agent 时代价更高——人能一句话挥开一个 nit，agent 会去改，于是又多一个 commit、多一轮评审。
审查者本身也在被 eval：把过去引发事故的 PR 连同修复与回滚一起收集，请熟悉那段代码的工程师确认每个 bug 及其位置，形成每日回归集；审查者的任何改动都跑这套集，分数涨了才留下。
第 4 层
人留在机器做不好的判断上
还有一个容易被忽略的失守点：关掉一票批准比想象中容易。原文的解法是流程而非提醒——批准绑定单个 commit，受信名单之外的人必须第二人批准，bot 的批准不占人的位置。
「你合并的，你负责」靠的是便宜，不是纪律
中小改动出问题时通常由本人修，这条团队规范能成立，是因为它背后的东西都很便宜：改动小，好审好调好回滚；一切可逆，开关、回滚、分阶段发布几分钟就能撤销大部分错误；影响面决定规格，贵的代码自然有更多人和更多检查；回归通过遥测和内部使用很快显形。原文特别强调这不是追责——你拥有修复，是因为你最了解上下文，事故复盘看的是系统。
同一层意思还有一条：agent 让启动变得便宜，所以有些工作本来就不该落地。做法是在频道里尽早提出另一个方向，而不是在成品 PR 上留一条阻断性评论。因为代码写得快，关掉 PR 不觉得是损失。
知识怎么扩散：没有正式流程，靠按需解释
评审的第二个职能是让团队理解代码库。机器读掉大部分 diff 之后，没人再靠读 diff 学习。团队的做法是：想理解哪一块，就让 Claude 为那一小片写解释——几分钟就能拿到、反映的是今天的代码；有人还会让 Claude 做一个小工具把这块代码可视化，按自己习惯的方式学。原文的对比很直接：一行文案改动逐行读完几乎学不到东西，而为即将改动的模块写解释学到的很多。默认在公开频道协作，也让人看见别人在做什么，帮上忙。
第 5 层
照搬清单：分四个时点配
PR 之前
给 agent 它能跑的检查，写进简短的 CLAUDE.md，配 hooks 跑格式化和 lint；本地跑 /code-review、/security-review，或用全新上下文的 subagent 审 diff；建 REVIEW.md，把重复出现的评审意见搬进去。
每个 PR
必需 CI；PR 模板加「怎么测的」「风险」「怎么撤销」三栏。接一个 AI 审查者到一个仓库，调几周 REVIEW.md 再铺开；加自动安全审查；要求所有评审 thread 合并前解决；按风险配审查力度；限制轮次，几轮之后只看新 diff。
批准
写下风险分档，由变更定档而非作者；先严后松，靠证据放宽；轻路径只留给受信作者；用 CODEOWNERS 和分支保护让鉴权、计费、CI 与发布流程、安装器永远需要人；绝不让 bot 批准替代必需的人工批准，新 commit 上作废旧批准。
合并之后
合并队列、特性开关、内部先用、分阶段发布、一步回滚；把事故和回滚变成 eval 集，审查者的 prompt、工具或模型一改就重新打分；量人的时间，并用回滚率和事故率当护栏。
边界：原文自己写明的空白
还没有「数字一动就自动收紧审批」的断路器——工程师希望在更多代码走向零人工合并之前把它做出来。坏合并的发现仍然依赖作者、值班工程师和回滚与事故看板。公开的 Code Review 产品只发意见、不批准，是否合并仍是人的决定；团队自己的仓库更进一步，让 owner 决定哪些低风险改动可以只凭自动检查合并，而这条线一直在移动。
对「降速能不能降错误率」原文的回答很克制：一位同事说放慢确实会降低错误率，但那主要是因为整体做得更少了。他们选择的是更快发现、更快修复。
来源
原文：How the Claude Code team does code review（claude.dev，2026-10-15，作者 Addy Osmani、Morgan Westlee Lunt、Qing Wang）。本篇为 5 分钟精华版，删去了原文的图注细节、内部工具链接与致谢；数量与限定条件均按原文保留，未引入外部信息。URL 里的 solving-code-review-at-anthropic 只是路径，不是篇名。
口径说明：原文的百分比与轮次数据都来自 Claude Code 团队自己的仓库与内部流程，属于内部观察，不是通用性能承诺。