Anthropic 公开 Claude Code 团队的代码审查流程：机器先读，按风险决定要几个人批准
01为什么要改审查方式
Agent 写代码以后，改动数量涨得很快。Anthropic 主仓库每天合并的改动，从 5 月约 2,500 个增加到 9 月超过 30,000 个（见 Anthropic 工程博客 ）。Claude Code 有自己的独立仓库，压力同样存在。
团队的看法是，“有没有人读过这段代码”只是一个粗略的替代指标，真正要问的是：这次改动可能出什么问题，该由哪道检查（自动的或人工的）来发现。他们的目标是让大部分 PR 最多经过一个人（可以就是作者本人），同时撤回率和事故率不上升。衡量方式是每个 PR 的人工批准数、人工评论数和等人的时间；撤回率和事故率是底线，一旦上升，说明省下的人力只是换了地方花。
02一次改动要过哪些关
| 阶段 | 做什么 | 没通过会怎样 |
|---|---|---|
| 开 PR 之前 | Claude 跑测试、构建或截图对比并展示输出，再由一个新上下文的子 Agent 审 diff | 作者继续改 |
| CI | lint、类型检查、各平台测试、构建和打包 | 不能合并 |
| AI 审查 | 多个 Agent 并行找 bug，另一组 Agent 对每条发现投票，通过的按严重程度贴出 | 有未处理的意见就不能合并 |
| 安全审查 | 单独一轮自动安全检查 | 有未处理的意见就不能合并 |
| 人工批准 | 分类器按风险定为 0、1 或 2 人 | 不能合并 |
| 合并队列 | 在最新 main 上带着这次改动重跑全部检查 | 不能合并 |
| 合并之后 | 功能开关、先给 Anthropic 员工用、先发 latest 渠道再发 stable | 关开关或回滚 |
所谓“新上下文的子 Agent”，是另开一个没看过写代码过程的 Agent 来读 diff，类似找一个没参与的同事复核，避免写代码的那个 Agent 替自己的思路辩护。
每条 AI 审查意见都必须回应：修掉，或者写明理由后关闭讨论，误报也是这样清掉。后续提交修好了问题，意见会自动消失。意见分 Important、Nit、Pre-existing 三类，Pre-existing 表示问题在这次 PR 之前就存在，不算作者引入的；只涉及风格、诊断信息或清理的意见在贴出前就被过滤掉。
03人工批准按风险分级
| 风险 | 例子 | 需要几人批准 |
|---|---|---|
| 低 | 文档、文案、仅内部使用的功能、藏在功能开关后的新增改动 | 自动审查和安全检查通过后不需要人 |
| 中 | 普通产品改动；缓存、自动更新、系统提示词等敏感区域 | 1 人 |
| 高 | 风险最高的代码，以及少数固定要两人看的路径 | 2 人 |
这张表有几个前提：
- 等级由分类器根据改动内容判定，与作者是谁无关；另有一个分类器判断个别改动即使等级低是否仍需要人看。
- 只有仓库信任名单上的作者（主要是负责该仓库的团队）能走较轻的路径，其他人都需要第二个人批准。
- 负责人标为敏感的路径和所有 CI 工作流文件，始终需要人工批准。
- Agent 的批准不能顶替必需的人工批准；让 Agent 写代码的人，本身算作一名审查人。
- 批准只对应某一次提交。之后出现系统无法担保的新提交（比如 Agent 推送的代码、手动解决的合并冲突），要重新批准。
人的精力留给机器不擅长的判断：这件事该不该做、计费和自动更新这类高风险代码、会被别人照抄的架构、读懂测试输出和截图等证据，以及为上线的改动负责。
04AI 审 AI 停不下来的问题
Agent 写、Agent 审，双方可以无休止地互相制造工作。团队有一个 PR 一夜之间审了改、改了审五十多轮，最后作者手动叫停。用 git blame 查看后发现，被反复指出的问题约 59% 在第一轮审查时就已经存在：审查器很少发现新 bug，只是每轮多挑出几个老问题。人会跳过无关紧要的意见，Agent 则照着改，于是又触发新一轮审查。
团队承认问题部分出在自己：他们习惯了默认多跑几轮。之后做了四项调整：
- 三轮之后，审查器请作者退一步重新考虑方案。
- 前几轮之后，只审新增的 diff。
- 指出问题时标明类别，让作者把同类位置一次改完。
- 已经贴过的意见不再重复。
| 指标（Anthropic 内部 PR） | 调整前 | 调整后 |
|---|---|---|
| 一轮审查和修复后通过 | 65% | 78% |
| 需要五轮以上 | 8.9% | 1.5% |
| 平均审查轮数 | 2.08 | 1.32 |
05审查器本身怎么变好
过去引发事故或被撤回的 PR 被整理成评测集，由熟悉相关代码的工程师确认 bug 是什么、在哪里，审查器每天在上面跑一遍。改了提示词、工具或模型，分数上升才保留。
多报问题很容易提高命中率，所以还要量误报：按 PR 作者对每条意见的处理方式（修了、认为有误、属于有意为之、不重要）分类统计，另外在已知没问题的 PR 上跑审查器，看它多常给出会诱导别人做出有害改动的意见。团队写明的优先级是：先抓到真 bug，其次减少审查轮数。
审查器反复指出同一类问题时，就从源头改：写进 CLAUDE.md（项目的技术栈、约定和目标）、由代码负责人维护的 REVIEW.md（这部分代码最怕出什么错、哪些路径跳过），或者加一条 lint 规则。
06能拿来用的部分
Anthropic 内部的风险分类器、合并队列等属于团队级基础设施，原文末尾给出了完整的落地清单。以下是有公开工具对应、门槛较低的几项：
| 工具 | 做什么 | 谁能用 |
|---|---|---|
| /code-review | 在当前会话里审查分支上的改动，找正确性 bug；加 --fix 让 Claude 直接改，加 --comment 把意见贴到 GitHub PR | 任何套餐，消耗计入会话用量 |
| /security-review | 检查 SQL 注入、XSS、鉴权缺陷、依赖漏洞等常见安全问题；也有开源 GitHub Action 版本 | 帮助文档列出 Pro、Max 和 API 用户 |
| Code Review | 托管服务，自动审查 GitHub 仓库的每个 PR，按仓库设 Quick、Standard 或 Deep | Team 和 Enterprise 计划，需组织 Owner 开启 |
/code-review /code-review --fix /security-review
两点容易混淆。第一，本地的 /code-review 只读 CLAUDE.md，不读 REVIEW.md，后者只对托管的 Code Review 服务生效。第二，按官方文档，公开的 Code Review 服务只贴意见，从不批准或阻止 PR，合并与否由团队决定；文中“有未处理意见就不能合并”“低风险改动无需人工”是 Anthropic 在自家仓库上额外配置的规则。
个人项目可以先做的几件事，均来自原文清单：
- 在简短的 CLAUDE.md 里写清楚 Agent 能跑的检查，比如测试和构建命令，要求它贴出输出，而不是只说“完成了”。
- 开 PR 前在本地跑 /code-review 和 /security-review。
- 在 PR 模板里加“如何测试”“风险”“如何回滚”三项。
- 给 AI 审查设轮数上限，前几轮之后只审新增改动。
按风险分级批准、信任名单这些规则，前提是有多人协作和分支保护（如 CODEOWNERS），对单人仓库的意义有限（本站推断）。
DeepSeek
Hy-Memory
Timestral