Claude Code 团队公开代码评审流程：约 90% 代码由 Claude 编写，6 月至 9 月合并 PR 翻倍、回滚占比降 40% 以上

核心背景与行业痛点

当代理写代码的速度远超人工阅读速度，逐行 Code Review 就成了瓶颈。Anthropic 在 claude.dev 工程博客（10 月 15 日，Addy Osmani 等三位作者）中称，Claude 已编写 Claude Code 自身约 90% 的代码；其 monorepo 每日落地变更从 5 月约 2,500 个涨到 9 月超过 30,000 个（见 源码管理重构一文）。团队的目标是：多数 PR 最多一人参与即可合并，且回滚与事故率不上升。

架构亮点与底层机制

流程是多层叠加而非单一关卡：提 PR 前 Claude 先跑测试、构建与 lint，再由新上下文的子代理复查 diff；每个 PR 由多个代理并行找 Bug，另一组代理投票核验，只有达成共识的问题才会发出，并标注 Important / Nit / Pre-existing；安全评审单独进行，未关闭的问题会阻断合并；分类器按变更（而非作者）判定风险，低/中/高分别需要 0/1/2 名人工审批，CI 工作流等路径始终需要人。合并后还有合并队列、功能开关、内部先用、latest→stable 渐进发布和快速回滚。

权威 Benchmark 与实测跑分对比

以下均为团队内部数据，文章未公开原始数据：6 月至 9 月合并 PR 翻倍以上，回滚占比降 40% 以上；有一个 PR 曾通宵来回评审修复 50 多轮，git blame 显示约 59% 的反复告警是首轮就存在的旧代码。加入三轮上限、仅审新 diff、不重复告警后，一轮通过率从 65% 升至 78%，平均轮数从 2.08 降至 1.32。

开发者实战落地与开箱指南

可直接照抄：写一个简短的 CLAUDE.md 列出可运行的检查；用 REVIEW.md 写清本仓库的“失败长什么样”；本地运行 /code-review 与 /security-review；在一个仓库启用 Code Review（Team/Enterprise 已 GA）并选 Quick/Standard/Deep；PR 模板加上 Testing、Risk、How to revert；把历史事故与回滚整理成每日评测集。更多做法见 最佳实践。