要点
- Anthropic 工程博文（Addy Osmani、Morgan Westlee Lunt、Qing Wang，2026-10-15）称 Claude 约写 Claude Code 自身代码的 90%；6–9 月合并 PR 翻倍以上，回滚占比下降逾 40%。
- 公司 monorepo 日落地变更从 5 月约 2,500 升至 9 月逾 30,000；目标是多数 PR 最多一人在环（可为作者），且回滚/事故不升——用人审批数、评论数、等待时间测「人时」，用回滚与事故作护栏。
- 流程分层：提交前自检与子代理复审、每 PR 的 Claude 审查（研究预览期实质评论率 16%→54%）、可阻断的安全审、CI、按风险分级的人批、合并队列与灰度，以及快速回滚；机器人批准永不顶替人批。
Claude.dev 在 2026 年 10 月 15 日刊出一篇工程长文，作者是 Addy Osmani、Morgan Westlee Lunt 与 Qing Wang。开篇几乎不掩饰矛盾：团队自称 Claude 写下约 90% 的 Claude Code 自身代码；从 6 月到 9 月，合并进 Claude Code 代码库的 pull request 翻倍以上，而不得不回滚的份额下降逾 40%。问题因此不是「还有没有人读代码」，而是：在 agent 把变更量推到人手线审几乎不可能的地方，审查究竟还在干什么。
答案写得很硬：他们没有取消审查，而是把大部分阅读交给机器，把稀缺资源定义为人类时间与注意力，并大力投资「快速撤销错误」。这是公司自述，不是第三方审计；但它给出一组可被后续事故与回滚数据证伪的操作主张。
[1]文中把代码审查拆成两项工作：一是发版前找问题并修；二是在团队里建立共享上下文。主文聚焦第一项。Anthropic monorepo 的日落地变更从 5 月约 2,500 升到 9 月逾 30,000；Claude Code 虽在独立仓库，也承受同类压力。传统「人是否逐行读过」被视为不精确代理；更准的问题是「这次变更可能错在哪，哪一层自动化或人工检查最适合抓住它」。
目标函数也改写了：在 Claude Code 各仓库（CLI、桌面/网页、移动）里，多数 PR 合并时最多一人在环——且可为作者本人——同时不以回滚或事故上升为代价。度量是每 PR 的人类批准数（中位与 P95）、人类评论、以及 PR 等人的时间；回滚率与事故率是护栏：「若它们上升，我们就没有省下人时，只是把成本挪到后面。」
[1]分层机制是文中最可操作的部分。变更在 PR 前就要可运行验证（测试、构建或对照设计的截图），再由新上下文的子代理复审；Boris Cherny 被引述称，给 Claude 可验证其工作的方式「大概是」拿到好结果的最重要一点，并估计能让终稿好两到三倍。每 PR 必经 Claude 审查：对照整仓与 PR 意图问「是否解决问题、是否契合系统、是否弄坏别的」；研究预览阶段，内部 PR 收到实质审查评论的比例从 16% 升到 54%。发现要经其他 agent 投票后才贴出；风格/诊断/清理类噪声在自家 PR 上做过 A/B 后丢弃。
安全审查可阻断合并；常规 lint、类型、多平台测试与构建同样阻断。人批按风险分级：低风险（文档、文案、旗标后的加性改动）在自动化与安全绿灯后可不要求人批；中风险一人；高风险与指定敏感路径两人。分级由变更（含分类器）决定，不是由作者身份决定；仅受信作者名单可走更轻路径；agent 的批准永不算作人批。合并队列对 main 重跑检查，行为常先对内员工开旗，再走 latest 再 stable。事故被收成每日跑的评审 eval；噪声用「人是修了、否认、说是故意、还是觉得无关」来标定。一轮 CLI PR 曾过夜来回五十多轮，git blame 显示约 59% 反复被标的问题在评审首次通过时就已存在——于是设三轮上限、之后只审新 diff、禁重复贴出已发过的 finding。
对 Anthropic 最强的钢人论证是：在变更量级下，坚持人人线审会同时抬高等待成本与漏检成本；把常规缺陷前移到可运行验证与多 agent 投票，把人留给方向、品味、计费/自动更新/CI 等工作流与架构范式，并用旗标与回滚吸收剩余错误，比假装「每行都有人读过」更诚实。文中「你落地，你负责」与「blast radius 定门槛」也试图避免把自动化变成无人负责。
钢人之外的硬缺口同样明确。全部核心数字——90% 代码由 Claude 写、monorepo 日变更量、PR 翻倍与回滚降 40%、16%→54%、59% 旧码重复——均为公司自报，文中未附可复现的公开仪表盘或外部复现。产品侧仍强调「Code Review 贴 findings 不贴 approvals」，自家仓库却已允许所有者对部分低风险变更仅靠自动化合并，「那条线还在移动」；文中承认尚无在回滚/事故恶化时自动收紧批准的断路器，工程师希望在更多代码走向零人合并前先有它们。换言之，主张的可证伪点被作者自己写进了护栏，但外部读者目前只能信其事后诚实，而不能独立核验当期曲线。
[1]对工程团队，这篇博文的可迁移部分不是「把审查全交给 Claude」，而是一整套制度清单：CLAUDE.md / REVIEW.md、本地 /code-review 与安全审查、风险分级与 CODEOWNERS、合并队列与一键回滚、把事故做成 eval，以及明确禁止 bot 顶替人批。对采购与合规读者，关键信号是 Anthropic 把「人在环」重定义为按风险配置的责任槽，而不是仪式性的逐行阅读——若你的合同或内控仍把「人类审过 diff」写成合规要件，你们说的「审过」与他们说的「审过」已经不是同一个对象。
对劳动与组织议题，共享上下文那一节同样尖锐：若机器做了大部分阅读，团队靠「向 Claude 要切片解释」与开放频道观察来补认知，而不是靠读琐碎 diff。这可能更有效地分配注意力，也可能削弱「只有读过代码才算懂系统」的师徒路径——文中承认没有正式替代流程。
[1]未来六个月，要比对的不是又一篇「AI 写了多少代码」的宣传，而是两条曲线是否仍同向：人类批准/等待时间继续下降的同时，回滚与事故是否保持不升（或继续低于其 6–9 月叙事中的高点）。若零人合并路径扩大而断路器仍缺席、事故却抬头，则「省下的人时」只是延期账单；若护栏守住且 eval 随事故增长仍压住噪声，则 Anthropic 描述的分层审查，至少在自家仓库里，把「审查」从阅读仪式改写成了风险分配系统。
【No.2】
[1]