一、引言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.081.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 审查必须控制误报和循环次数避免陷入无限修改。人类不再需要阅读所有代码但必须掌握架构决策、风险判断和最终责任。