人不必看每一行：Claude Code 团队的代码审查流程，你的团队明天就能抄
Claude 写了 Claude Code 约 90% 的代码之后，团队怎么审：七层流程、按风险分级的人工批准、三轮封顶，以及一份明天就能照抄的清单。
01
先说一组反常识的数字。
据 Anthropic 在 claude.dev 上 10 月 15 日发布的博客，Claude 写了 Claude Code 自身约 90% 的代码。
6 月到 9 月，Claude Code 代码库合并的 PR 数，翻了一倍多。
按常识，代码写得越多、合得越快，出事应该越多。
可是，需要回滚的比例，反而下降了 40% 以上。
为什么？
再看一组更大的数字。Anthropic 主仓库每天落地的变更，5 月约 2,500 个，9 月超过 30,000 个。
这么多代码，人看得过来吗？
看不过来。
看不过来，还能更稳，靠的是什么？
不是靠人更努力，而是靠一套重新设计过的流程。
这篇博客的作者是 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang。我把它拆开，看看里面的底层逻辑，和你的团队明天就能用的几条。
02
要理解这套流程，我们必须首先理解：代码审查，到底在审什么？
是在审代码吗？
不完全是。
审查的本质，是用人的注意力，去换上线后的确定性。
人的注意力，是有限的。代码，现在是近乎无限的。
我把它写成一个简单的式子：
人工审查成本 = PR 数量 × 每个 PR 消耗的人工注意力
PR 数量，已经不由人决定了。Agent 写得多快，它就涨得多快。
那么，能控制的只剩后一项。
怎么控制？
不是每个 PR 都平均少看一点，而是把人的注意力，只花在风险高的地方。
这就是 Claude Code 团队的目标：多数 PR 最多一个人参与，这个人可以是作者本人；同时，回滚和事故率不能上升。
怎么知道做到了没有？他们定了几个指标：每个 PR 的人工批准数（看中位数和 P95）、人工评论数、PR 等人的时长。回滚和事故率，当作护栏。
注意这个设计。
效率指标是油门，事故指标是刹车。只踩油门不看刹车，是莽；只踩刹车不踩油门，是怂。
03
那么，人不看的那些地方，谁来看？
答案是：七层流程，层层过滤。
提 PR 前先验证 → 每个 PR 都有 Claude 审查 → 能阻断合并的安全审查 → 阻断式自动检查 → 按风险分级的人工批准 → 合并队列、功能开关、灰度发布 → 快速发现、快速回滚
一层一层看。
第一层，提 PR 前先验证。给 Claude 能跑的东西：测试、构建、对比设计稿的截图，让它把输出亮出来。然后，再让一个新上下文的子 Agent 去审这份 diff。
为什么要“新上下文”？因为写代码的那个 Agent，脑子里装满了自己的思路，容易看不见自己的错。换一个没参与过的去看，才像真正的第二双眼睛（这是我的理解）。
第二层，每个 PR 都有 Claude 审查。
第三层，能阻断合并的安全审查。
第四层，阻断式自动检查：lint、类型、全平台测试、构建。
第五层，按风险分级的人工批准。这一层最关键，后面单独说。
第六层，合并队列、功能开关、灰度发布。先发 latest，stable 跟进。
第七层，快速发现、快速回滚。
你会发现，人工批准只是七层里的一层。
前面几层负责“拦”，最后几层负责“兜”，人只负责“判”。
04
再说 AI 审查本身。
据博客，AI 审查的研究预览上线后，内部 PR 收到实质性审查意见的比例，从 16% 升到了 54%。
它是怎么做的？
多个 Agent 并行找 bug，另一组 Agent 投票确认，票数够了才发出来。纯风格类的意见，直接丢弃。每条评论标上 Important、Nit 或 Pre-existing。
还有一条规矩：每条意见都必须回应。要么改，要么写清楚理由关掉。
这条规矩，我觉得特别值得抄。
为什么？因为审查意见如果可以被无视，审查就会变成噪音；噪音多了，真正重要的那条也会被一起无视。
05
现在回到第五层：人工批准怎么分级？
博客给了一张风险分级表。
低风险：文档、文案、内部功能、功能开关后面的新增。自动检查全绿即可，不需要人工。
中风险：普通产品改动，以及缓存、自动更新、系统提示词这类敏感区域。需要一个人批准。
高风险：需要两个人批准。
这张表本身不复杂。复杂的是配套的几条规则，每一条都在堵一个漏洞。
风险等级由分类器读变更来决定，不看作者是谁。——堵的是“老员工的代码不用看”的人情漏洞。
只有仓库信任名单上的作者，才能走轻路径。——堵的是“谁都能走快车道”的漏洞。
Agent 的批准，永远不算人的批准。——堵的是“机器给机器盖章”的漏洞。
指挥 Agent 写代码的那个人，算作必需审查人之一。——这一条最有意思。它的意思是：代码是 Agent 写的，但责任是人的。
批准只对某一个 commit 有效，新推送要重新批。——堵的是“批完再偷偷改”的漏洞。
这几条规则背后，是同一个逻辑：流程可以变轻，但责任不能变空。
06
流程设计得再好，也会遇到新问题。
博客很坦诚地讲了一个案例：有一个 CLI 的 PR，一夜之间，被 Agent 作者和 Agent 审查者来回改了 50 多轮，最后是作者自己叫停的。
Agent 审查者挑错，Agent 作者改错，谁也不累，谁也不停。
更有意思的是，团队用 git blame 一查，发现审查反复标记的东西，约 59% 是第一轮就存在的老代码。
也就是说，审查者一直在挑“本来就有”的毛病，作者一直在改“本来不归这次改”的地方。
怎么办？
他们给的对策是：三轮封顶，三轮之后请作者重新考虑方案；几轮之后，只审新的 diff；标出 bug 的类别，让作者一次全改；已经发过的意见，不再重复。
这里面有一个很深的道理。
人和人之间的审查，有一个天然的刹车：累。来回审上几轮，大家都烦了，自然就会停下来想一想，是不是方案本身有问题。
Agent 不会累。所以，刹车必须写进规则里。
07
还有一招，我认为是整篇博客里最聪明的。
用历史事故做评测集。
把引发过事故的 PR 收集起来，每天拿审查器跑一遍。
为什么聪明？
因为事故，是一个团队最贵的学费。交过一次，就应该变成一道永久的考题。审查器每天考一遍，考不过，就说明它又退步了。
这和我们常说的复盘，是一个道理。复盘不是为了写报告，是为了下次不再犯。
08
最后，说一说你的团队明天就能用的几条。下面是我根据博客整理的清单。
第一，写一份 CLAUDE.md。说清楚项目是什么，保持简短，指向其他文档。
第二，写一份 REVIEW.md。由代码负责人来写，说明这块代码“坏了长什么样”。比如，文档坏了，是“说谎”；配置坏了，是“路由错”。同时限制 nit 的数量，要求每条意见给出文件和行号作为证据。
第三，改 PR 模板。加上 Testing、Risk、How to revert 这几栏。
第四，立一条团队规范：You land it, you own it。谁合进去的，谁负责。
第五，照 Claude Code 团队的做法，安排每周轮值的 on-call，事故复盘时追问一句：本该由哪一层拦住它。
如果你不想自己从零搭，产品也有。据 Anthropic，Code Review for Claude Code 已经对 Team 和 Enterprise 计划正式可用。管理员可以按仓库选 Quick、Standard（默认）或 Deep。正式可用之后，多数审查从约 20 分钟降到了 6–10 分钟。
注意一个边界：它只发意见，不批准，也不阻断 PR。批不批，还是人说了算。
另外，任何计划都可以在本地用 /code-review，还有 /security-review，以及开源的安全审查 GitHub Action。
博客也承认，有一件事还没做到：指标出现异常时，自动收紧审批的熔断机制。
这说明，这套流程不是终点，还在演化。
结语
回到最开始的问题。
代码多了那么多，回滚反而少了，靠的是什么？
不是让人多看，而是让人少看、看准。
机器负责拦，流程负责兜，人负责判断和担责。
Agent 可以替你写代码，但不能替你担责任。
把这句话想清楚，你的团队就知道审查流程该怎么改了。
来源：Anthropic 博客（claude.dev，2026-10-15）；Code Review 正式可用公告；Code Review 文档。文中数字均为 Anthropic 自报的内部数据，未经第三方核实；“每周轮值 on-call”对应原文 “Claude Code has a weekly on-call rotation”。