Claude Code 团队公开了一套审查 AI 生成代码的流程。官方称，Claude 约完成自身代码的 90%；6 月到 9 月，合并 PR 翻倍以上，被回滚的 PR 占比下降四成多。机器先跑测试、审查和安全检查，人工审批按改动风险分配。
90%
代码由 Claude 完成。
2×+
合并 PR，6—9 月。
40%+
回滚占比下降。
代码量上升后，审查先处理“会不会出问题”
Claude Code 团队把自己的代码审查经验写成了一篇工程文章。文章的起点很具体：当代理能持续提交代码，人工逐行阅读每个 diff 很快会变成瓶颈。团队把审查目标改成判断一项改动可能带来什么风险，再决定由哪一层检查接手。
这套流程从提交 PR 前就开始。Claude 先运行测试、构建和 lint，并把输出交给人看；随后由一个新的上下文代理审查 diff。团队还会调用 /code-review 和 /security-review，分别检查代码问题和安全问题。
同一类问题反复出现时，团队会把规则写入 CLAUDE.md。这一步把一次审查发现变成后续任务可以读取的项目上下文。
Claude Code 团队公开的流程，核心是把机器检查前置，再把人工时间留给风险更高的改动。
原帖信息图：Claude Code 团队公开的 AI 代码审查流程与内部数据。
审查轮次超过三轮，就先停下来重想
团队遇到过一个 CLI PR：它在一夜之间经历了 50 多轮审查和修复。后来用 git blame 追踪反复被指出的代码，约 59% 的问题代码在第一轮审查时就已经存在。审查代理每一轮都继续找到旧问题，作者则不断提交新的修复。
因此，团队给审查设置了三轮上限。超过三轮，审查者会要求作者退一步重新考虑方案；前几轮之后，复查范围收缩到新的 diff；如果问题属于某一类缺陷，就要求作者一次性处理同类位置，而不是逐行追着修。
信息图还列出了内部 PR 的变化：一轮通过率从 65% 上升到 78%；需要五轮以上的 PR 从 8.9% 降到 1.5%；平均审查轮次从 2.08 降到 1.32。图中这些数字来自原帖引用的官方博客，正文按该来源口径呈现。
人工审批跟着风险走
低风险改动包括文档、文案、只供内部使用的功能，以及藏在开关后的新增改动。对受信任的作者，这些改动在自动审查和安全检查通过后可以不再增加人工审批。普通产品改动通常需要一名人工审批者；风险最高的代码以及少数指定路径需要两名人工审批者。
登录鉴权、计费、CI 和发布流程、安装程序等路径始终需要人批。Claude 的批准不能替代人工名额，驱动代理完成改动的人也要对最终结果负责。
合并队列会在主分支上重新运行检查，新行为通常先通过功能开关向内部员工发布，再逐步进入稳定渠道。仍然漏过检查的问题，则依靠快速发现和回滚收尾。
对 Builder 的直接启发。让代理展示测试输出；把重复出现的缺陷写进项目说明；为审查设置轮次上限；把文档和低风险改动交给自动检查；把计费、权限、CI 和发布路径保留给人工审批。
这套流程把“谁写了代码”转成了“哪一层检查负责什么”。代码由代理生成时，人工工作的重点落到方向、风险、证据和最终责任上。
SOURCES。
Claude Code 团队官方博客。
社区帖子及配图。