Claude Code团队如何审查Claude写的九成代码：分层评审、人类把关与“谁合并谁负责”

Claude写下九成代码之后：博客发布与@ClaudeDevs的数据

Claude Code是Anthropic推出的AI编程助手。这次引起开发者关注的不是新功能，而是团队自曝的一个事实：Claude Code本身约90%的代码是Claude写的。官方博客文章《How the Claude Code team does code review》于2026年10月15日上线，署名作者为Addy Osmani、Morgan Westlee Lunt和Qing Wang，标注阅读时长14分钟，主题就是在AI产出占绝对多数时，人类该如何审查这么多代码。

文章给出的成果数据集中在2026年6月至9月：合并的PR数量翻了一倍以上，同时被打回（差し戻し）的比例下降超过40%。产出翻倍而返工变少，正是这篇文章被大量转发的原因，它直接回应了“AI写得多但质量没人兜底”的质疑。需要注意，这些数字来自团队自己的统计，并非第三方复现。

X上的官方开发者账号@ClaudeDevs在2026年10月16日发帖介绍此文，收录时数据为浏览183万、点赞12822、收藏10264、转发904。收藏数与点赞数几乎持平，在技术类帖子中并不常见，说明不少工程师把它当作日后对照的参考资料。

原文地址为 https://claude.dev/blog/solving-code-review-at-anthropic/ ，页面顶部有HOME、MODS、DOCS、TERMINAL四个栏目和Try Claude Code的试用入口，全文无需注册即可阅读。

出处[1][2]

从Layer by layer到Where this is going：8个章节讲了什么

正文目录依次为：Layer by layer（分层审查）、How we make the reviewer better（如何让审查者变得更好）、Where humans stay in loop（人类留在回路中的位置）、Sharing context across the team（团队内共享上下文）、You land it, you own it（谁合并谁负责）、When we change direction（何时改变方向）、How you can adopt this process（如何引入这套流程）、Where this is going（未来走向）。

全文的核心是一条优化顺序：先追求高覆盖率和足够深入的审查，在这个基础上，再去寻找“不会让打回和事故变多”的最小人类审查时间。也就是说，人类时间被当作要节省的稀缺资源，但节省的前提是质量指标不能变差，而不是先砍人工再看会不会出事。

团队强调审查要追踪一次改动的完整生命周期，而不是只盯着合并那一刻；审查按层逐步加深，人类保留在关键判断环节。配套的是团队内共享上下文，让审查者知道改动背后的意图，以及“You land it, you own it”这条责任原则，明确合并者要对后续结果负责。

• 优化目标：先覆盖与深度，后压缩人类审查时间，红线是打回率和事故数不能上升。
• 审查对象：一次改动从提出到上线后的全过程，而非单个PR的合并瞬间。
• 人类的位置：留在需要重大判断的环节，具体边界在Where humans stay in loop一节展开。
• 责任归属：谁把改动合入谁负责，配合团队上下文共享减少信息差。

出处[1]

想在自己团队试用：先读How you can adopt this process

文章倒数第二节How you can adopt this process专门写给其他团队，最后一节Where this is going则讨论这套做法的走向。照搬之前，建议先确认自己团队能否量化同样的两个指标：PR被打回的比例和线上事故数，因为整套方法都以“这两个数字不变差”为前提来压缩人类审查时间。

落地顺序可以参考文章本身的逻辑：先把审查覆盖面和深度补齐，再逐步减少人工介入，同时观察打回率和事故是否上升；责任规则和上下文共享则可以单独先试，比如在团队里明确“谁合并谁负责”。想直接体验工具本身，可以通过页面上的Try Claude Code入口。

局限也要说清楚：90%代码由Claude编写、PR翻倍、打回率降四成，都是Claude Code团队在自家代码库上的自述数据；文章摘要中没有列出具体使用了哪些自动化工具及配置，其他规模、其他技术栈的团队能否复现同样效果，目前无法从原文直接得出结论。

出处[1]