AREX Feed Article
Claude 开发者账号称 Claude 编写了 Claude Code 自身约 90% 的代码，并称 6 月至 9 月合并 PR 增加逾一倍
10 月 16 日，Claude 开发者账号 发帖称，Claude 编写了 Claude Code 自身约 90% 的代码；6 月至 9 月，Claude Code 代码库中合并的 PR（拉取请求）数量增加了一倍以上，需要回退的变更占比下降超过 40%。帖文附了一篇说明的链接，称团队讲述了如何改造代码审查得到这些结果，以及其他团队如何采用。
这篇题为 的说明于 10 月 15 日发表在 Anthropic 的 claude.dev 博客，署名 Addy Osmani、Morgan Westlee Lunt、Qing Wang。文章以 Anthropic 的 Claude Code 团队第一人称写成，文中说：「我们之前说过，Claude 编写了 Claude Code 自身约 90% 的代码。」90% 是团队此前已公开的说法；这三个数字在说明中都能找到对应表述。
团队自报三个数字
这三项说法都来自 Claude 开发者账号和 Claude Code 团队，属于第一方说法。回退占比的降幅超过 40%，这是相对降幅，不是 40 个百分点。
范围也有限定：说明写的是 Claude Code 的代码库，包括命令行（CLI）、桌面端与 Web 应用、移动应用，并不等于 Anthropic 的全部代码。博文用 Anthropic 单体仓库（monorepo）的压力作背景：据 ，2026 年 5 月日均合并约 2,500 次代码变更，到 9 月日均超过 30,000 次。Claude Code 位于独立仓库，这组数字不能当作 Claude Code 的 PR 数。
团队给这套流程定的目标是：Claude Code 各仓库的大多数 PR 最多只有一个人参与审查和批准，这个人可以是作者，同时不让回退率和事故率上升。说明把回退与事故率当作护栏：如果它们上升，省下的人工时间只是转移到了修错上。
团队把变更检查拆成六层，批准按风险分档
变更量上升后，逐行人工审查变得难以维持；团队把大部分阅读交给机器，把人的注意力留给高风险部分。说明把一次变更的路径拆成六层检查，底层还有回滚。提交 PR 之前，Claude 先跑测试、构建和 linter（代码检查工具），给出输出而不是只说「做完了」；另一个子代理在全新上下文里再审一遍 diff（代码差异）。PR 打开后，必需的持续集成（CI）跑 lint、类型检查、各平台测试、构建与打包，检查失败就挡住合并。
接着是 Claude 审查：多个代理并行找 bug，另一组代理对每条发现投票，票数不够的不发布；只涉及风格、诊断或清理的发现被丢弃；留下的按严重程度标成 Important、Nit 或 Pre-existing。安全审查单独跑一遍，任一审查有未关闭的发现都不能合并。
人工批准的档位由变更决定，作者身份不决定档位：低风险变更在自动审查与安全检查通过后不需要人，中风险要一个人，高风险要两个人。分类器判定风险档，第二个分类器判断是否还需要额外的人；代码所有者标记为敏感的路径和任何 CI 工作流文件始终要人。只有仓库信任名单上的作者能走轻路径；代理的批准永远不能算作人的批准；在代理写的 PR 上，发起变更的人算作所需审查人之一；系统无法确认的新 commit（提交）进来，需要重新批准。
合并队列会在最新的 main 上带着这次变更重跑全部检查；新行为通常先放在开关后给 Anthropic 员工用，公开发布先走 latest 通道，stable 通道随后。说明还给出一个覆盖度数字：研究预览上线时，内部 PR 中获得实质性审查意见的比例从 16% 升到 54%。
五十轮之后，团队给审查设上限
机器审查也会陷入循环。博文举了一个 CLI PR 的例子：一个晚上经过五十多轮审查和修复，最后作者叫停。团队对审查反复标记的代码跑了 git blame，约 59% 是审查者第一轮时就已存在的代码；审查者很少在找新 bug，只是每一轮多找几个旧 bug。
改法有四条：三轮之后，审查者要求作者停下来重新考虑方案；最初的几轮之后只审新增 diff；标出一类 bug，让作者修掉所有实例，不只一行；已经发过的发现不再重复。
博文给出一组内部 PR 的前后对比：一轮审查加修复就通过的占比从 65% 升到 78%；需要五轮或更多的从 8.9% 降到 1.5%；平均通过所需审查次数从 2.08 降到 1.32。
团队还按 PR 作者对评论的反应给审查质量分类（改了、说它错了、说行为是故意的、还是觉得不重要），并用已知干净的 PR 统计审查者会报出多少可能导致有害改动的发现。团队把造成事故的 PR 连同后续修复与回退记录做成评测集：由熟悉那段代码的工程师确认 bug 与位置，审查者每天跑一遍；提示词、工具或模型一改，就重新打分。说明把优先级写成：先抓真 bug，其次减少审查轮次。
团队把人的工作改成五类决定
这五类决定是：这个功能该不该做；高风险代码，比如计费、自动更新器和 CI 工作流；会被别人复制的架构；读证据，包括测试输出、跑过的命令、截图和审查者的发现；以及对结果负责。
团队的原则是「你合并，你负责」：小到中等的变更出问题，通常由合并者自己修。支撑这条原则的是：变更小、可逆；影响范围决定审查强度；回归能被遥测和内部使用快速发现；事故复盘看系统，不追责个人。
文章说，读代码学代码这件事没有正式流程；团队里没人把 Claude Code 完整装在脑子里，也不认为需要。想弄懂某一块时，就让 Claude 针对那一块写一份讲解，几分钟完成，反映的是当下的代码。
团队公开了一份采用清单
提交前，给代理可运行的检查，写进简短的 CLAUDE.md，加上格式化与 lint 的 hooks（钩子）；本地跑 /code-review 和 /security-review，或用全新上下文的子代理审 diff；加一份 REVIEW.md，把重复出现的审查意见写进去。
PR 层面，要求 CI，在模板里加「测试方式」「风险」「如何回退」三项；先在一个仓库接入 AI 审查，花几周调整 REVIEW.md，再扩大范围；加自动安全审查，要求合并前关闭所有审查线程；按风险匹配审查力度；给审查轮次设上限，之后只审新增 diff。
批准层面，把风险档写下来，先严后松；轻路径只给信任的作者；用 CODEOWNERS 和分支保护确保认证、计费、CI 与发布工作流、安装器始终要人；不让机器人的批准替代必须由人给出的批准，新 commit 进来就作废旧批准。
合并之后，用合并队列、功能开关、先内部使用、分阶段发布和一键回滚；把事故与回退变成评测集；审查者的提示词、工具或模型一变就重新打分；衡量人工时间，同时把回退率和事故率当护栏。
这套流程里的 AI 审查有一个公开产品版本：Code Review for Claude Code。博文称它已在 Team 与 Enterprise 套餐正式可用（generally available），Anthropic 的 则仍称其为 research preview（研究预览），两处口径并不一致。
文档页还写明，Code Review 的发现以行内评论的形式发布，不会批准或阻止 PR；博文则说，Anthropic 自己的仓库走得比公开产品更远，代码所有者可以决定哪些低风险变更只靠自动检查就合并。
团队缺一个自动收紧的开关
文章写明了这个缺口：团队还没有能在回退或事故数字变化时自动收紧审批的断路器（circuit breaker）。工程师希望在更多代码转向零人工合并之前把它做出来。文章还引述一位同事的话：放慢速度确实会降低错误率，但主要是因为每件事都做得更少；团队宁愿更快地发现和修复问题。
回退和事故数据已经被当作护栏，但审批门槛不会随这些数字自动变化。