一、引言
2026 年 10 月 15 日，Anthropic 团队发布了一篇技术文章：《How the Claude Code team does code review》—— Claude Code 团队是如何进行代码审查的？
全文主要介绍了一个非常值得关注的问题：当 AI Agent 已经能生成大量代码时，团队应该如何重新设计代码审查流程来保证代码质量？
文章不仅介绍了 Claude Code 团队实际使用的工作流，还给出了量化数据、踩过的坑，以及其他开发团队可以直接借鉴的方法。
二、核心观点
传统的开发模式：
开发人员写代码 -> 提交 PR -> 人工逐行审查 -> 修改 -> 合并。
Claude Code 团队的新模式：
AI 写代码 -> AI 自动验证 -> 多 Agent 审查 -> 安全检查 -> 按风险决定是否需要人工审批 -> 合并 -> 逐进式发布 -> 监控与回滚。
这套流程的目标就是：让 AI 承担大量重复性的代码检查，让人专注于架构、风险、产品方向和最终责任。
文章还给出了两组重要数据：
- 2026 年 6 月 至 9 月，Claude Code 仓库合并的 PR 数量增长超过一倍。
- 同期需要回滚的 PR 比例下降超过 40%。
这说明在他们的实践中，代码交付速度提高的同时，回滚比例反而下降了。
三、Claude Code 的完整代码审查流程
整个流程可以分为七个阶段：
AI 编写代码并自行验证 -> 多 Agent 代码审查 -> 独立安全审查 + CI 检查 -> 按风险等级决定人工审批 -> Merge Queue 合并前复检 -> Feature Flag + 渐进式发布 -> 监控、快速回滚、复盘。
1. AI 开发完成后，必须提供验证证据
Claude Code 团队不接受 Agent 仅仅说“代码已经完成”。他们要求 AI 真正执行测试、构建等检查，并提供输出结果。例如：
- 后端代码：运行单元测试、集成测试和构建。
- 前端代码：运行构建，必要时通过截图检查界面。
- 代码规范：运行 Lint 和格式检查。
- 功能修改：验证端到端行为。
然后，使用一个拥有全新上下文的 Subagent 对修改进行独立审查。
2. 使用多个 Agent 审查，而不是只用一个
Claude Code 团队采用多 Agent 审查机制：
- 多个 Agent 并行检查代码，寻找潜在 Bug。
- 另一组 Agent 对发现的问题进行验证和投票。
只有得到足够支持的问题才会作为审查意见发布，并按严重程度排序。这实际上就把 AI 分成了不同职责：代码生成者、Bug 发现者、Bug 验证者。
3. 根据代码风险决定人工介入
| 风险等级 | 典型场景 | 人工审批 |
| 低风险 | 文档、文案、内部功能、受功能开关保护的增量修改 | 0 人 |
| 中风险 | 普通产品功能、缓存、自动更新器、系统提示词 | 1 人 |
| 高风险 | 最高风险代码及制定敏感路径 | 2 人 |
不过，零人工审批是有前提的：自动检查通过、作者值得信任且修改不涉及必须人工审批的路径。文章还特别强调：风险等级由代码变更本身决定，而不是由开发者身份决定。AI 审批不能冒充人工审批。
4. 不把合并成功当做开发结束
Claude Code 团队认为：再完善的审查也无法保证所有 Bug 都在上线前发现。因此，他们非常重视：
- Feature Flag：出现问题可以快速关闭功能。
- 内部优先使用：员工先体验新版本。
- 渐进式发布：最新渠道先发布，稳定渠道稍后跟进。
- 快速回滚：发现严重问题立即撤销变更。
他们不只是想办法避免错误，还会降低错误发生后的影响。
四、最值得学习的四个工程实践
1. 使用 CLAUDE.md 和 REVIEW.md 约束 AI
| 文件 | 作用 |
| CLAUDE.md | 告诉 AI 项目技术栈、编码规范、目标和限制 |
| REVIEW.md | 告诉审查 Agent 应重点检查哪些问题、什么算缺陷、需要哪些证据 |
例如，REVIEW.md 可以要求 AI：
- 每条 Bug 报告必须提供文件位置和行号。
- 不要根据函数名称猜测存在问题。
- 限制无关紧要的建议。
- 没有发现问题时明确说明。
对于反复出现的审查问题应当沉淀为规则，而不是每次都重新提醒 AI。
2. 限制 AI 审查、无限修改
文章举了一个很有代表性的例子：某个 PR 在一夜之间经历了超过 50 轮 AI 审查和修改。原因是审查 Agent 不断提出问题，开发 Agent 不断修改，导致循环无法收敛。
为了解决这个问题，Claude Code 团队采取了四项措施：
- 三轮审查后，要求重新考虑实现方案。
- 后续主要审查新增的 Diff。
- 发现一类 Bug 时，要求一次性修复所有同类问题。
- 不重复提出已经报告的问题。
优化审查机制前后的效果
| 指标 | 优化前 | 优化后 |
| 一轮审查与修复后通过 | 65% | 78% |
| 需要至少五轮 | 8.9% | 1.5% |
| 平均审查轮数 | 2.08 | 1.32 |
这说明：AI 开发不是审查次数越多越好，而是应该让审查流程尽快收敛。
3. 用真实 Bug 构建 Agent 的评测集
文章还介绍了一个持续改进机制：
每次出现线上事故或代码回滚，就将相关 PR 和 Bug 整理成测试案例，由熟悉代码的工程师确认。之后每天运行代码审查 Agent，检查它是否能够发现这些历史 Bug。如果修改了 Agent 的 Prompt、工具或模型，就重新运行整个评测集。这相当于给代码审查 Agent 建立一套不断扩大的回归测试。他们不仅评估 Bug 发现能力，也评估误报和审查轮数。
4. 人类负责 AI 不擅长的决策
文章明确列出五类仍然需要人的工作：
- 产品方向：这个功能究竟该不该做？
- 高风险代码：涉及计费、更新器、CI 等关键功能。
- 架构设计：是否会建立不合理的长期设计模式？
- 证据判断：测试覆盖了什么，有遗漏了什么？
- 最终责任：谁推动代码上线，谁就要对结果负责。
文章提出一种团队文化：You land it, you own it. 意思就是你推动的变更上线了，就需要你承担后续维护和修复责任。
五、对个人开发者的启发
个人 AI 开发工作流：
- 需求阶段：明确功能范围、验收标准、风险点和不做什么。
- 开发阶段：AI 编写代码，并根据项目规范执行实现。
- 验证阶段：运行测试、前端构建、必要的集成测试，保留执行结果。
- 独立审查阶段：使用新的 Agent 上下文检查 Diff、业务逻辑、权限、安全和回归风险。（本人习惯开一个新会话进行独立审查）
- 修复与复审阶段：只修复有证据的问题，原则上控制在三轮内；仍不通过则重新分析方案。
- 人工验收阶段：自己重点检查业务正确性、架构合理性、用户数据隔离以及验收证据。
- 交付阶段：确认通过后再提交、合并或部署，并准备回滚方案。
本人之前经常使用的提示词“开发完成后自行审查和测试，直到通过为止，不通过就修复问题并重新审查和测试。”现在可以把这段提示词升级为：
开发完成后，必须执行以下验证与审查流程：
自动验证：运行项目适用的构建、静态检查、单元测试和集成测试，提供真实执行结果，不得仅声称测试通过。
独立审查：使用独立上下文审查本次代码 Diff，重点检查业务逻辑、边界条件、异常处理、安全性、并发问题和回归风险。
问题验证：每个问题必须提供文件位置、触发条件、影响及证据；不得将猜测当作确定的 Bug。
修复与复审：修复已确认的问题，并重新运行受影响的测试。复审优先关注新增修改，不重复报告已处理的问题。
收敛控制：原则上最多进行三轮审查与修复。若仍存在问题，应重新评估实现方案，明确阻塞原因，不得无限循环。
风险检查：涉及认证、授权、用户数据隔离、数据库迁移、敏感配置等高风险变更时，必须明确列出需要人工确认的事项。
最终报告：输出修改摘要、测试命令及结果、审查发现、已修复问题、剩余风险和回滚方式。
所有检查通过且不存在未解决的阻塞问题后，才视为开发完成。未经明确授权，不提交或推送代码。
注意，这是我根据文章原则整理的个人开发模板，并不是 Anthropic 官方提供的原始提示词。
六、总结
我认为整篇文章可以浓缩成五句话：
AI 生成代码的速度已经不再是主要瓶颈，代码验证与审查正在成为新的瓶颈。
Code Review 应从人工逐行阅读，转变为自动化、多 Agent、风险分级的分层验证。
让 AI 证明代码正确，比让 AI 反复保证代码正确更重要。
AI 审查必须控制误报和循环次数，避免陷入无限修改。
人类不再需要阅读所有代码，但必须掌握架构决策、风险判断和最终责任。
