Anthropic 的 Claude Code 团队公开了他们的代码审查流程。团队此前说过，Claude Code 自己的代码约 90% 由 Claude 撰写；从 6 月到 9 月，合并进代码库的 PR 数量翻了一倍以上，需要回滚的比例却下降了超过 40%。文章解释这不是靠取消人工审查，而是把大部分阅读工作交给机器，把人的时间省给更高级的判断。核心主张是：”有没有人读过代码”是个模糊的代理指标，应该问的是”这个改动可能出什么问题，哪种检查最适合拦住它”。审查也从终点闸门变成类似拼写检查的连续过程，大多数改动在有人看之前已经被 Claude 至少审过一轮。

背景是合入速度已经远超人工逐行阅读的极限：Anthropic monorepo 每天落地的改动从 5 月的约 2,500 个增长到 9 月的超过 30,000 个。因此度量方式变成人工审批数、人工评论数和 PR 等人时长，回滚率/事故率作为护栏。目标是最多一个人参与就能合入，同时不增加回滚。

流程从 PR 之前就开始了：给 Claude 可运行的验证手段，比如测试、构建或截图，要求它展示输出而不是说”做完了”；再用一个 subagent 以全新上下文审查 diff。Claude Code 创造者 Boris Cherny 认为，给 Claude 验证方法大概是产出质量最重要的一件事，他估计能让最终结果好两到三倍。反复被标记的问题会被修进源头：CLAIM 类指令文件、REVIEW.md、lint 规则。REVIEW.md 要写得短，说明失败长什么样、限制 nit、要求提供文件行号作为证据，而不是只给名字。

每个 PR 都会先经过 Claude 审查，再给人看。公开版 Code Review for Claude Code 已在 Team 和 Enterprise 计划上正式可用，/code-review 可在本地跑轻量版。研究预览上线后，内部 PR 获得实质性审查评论的比例从 16% 升到 54%；千行以上的大 PR 基本都会拿到 findings，小 PR 大多干净。每个 finding 先由多个 agent 找 bug，再由另一组 agent 投票确认，只有足够多 agent 认为是真的才会发出来。风格、诊断、清理类发现会被丢弃，并按严重程度标为 Important、Nit 或 Pre-existing。每个 finding 都必须有回应，要么修复，要么说明理由关闭线程。

安全审查同样可以阻止合并：任何 bug 审查或安全审查的 finding 未解决，PR 就不能合。之后是常规阻塞检查：lint、类型检查、多平台测试和构建。人工审批按风险分层：低风险的文档、内部功能或 flag 后的增量改动，在自动审查和安全检查通过后无需人工；普通产品改动和缓存、auto-updater、系统提示词等敏感区域需要 1 人；最高风险代码和固定路径需要 2 人。风险分级由分类器根据改动内容决定，而不是作者自选；第二个分类器再判断某个改动是否即使分级不高也需要额外的人。只有受信任作者能走轻量路径，agent 的批准永远不能算作人的批准。谁发起改动谁负责，所以 agent 写的 PR 里，指挥 agent 的人算 required reviewer。审批只覆盖特定 commit，新 commit 若未被系统担保，需要重新批准。

合并队列会针对 main 重新跑所有检查，防止两个单独通过的 PR 合起来弄坏主分支。新行为通常先通过 flag 给 Anthropic 员工使用，再走向公开最新频道，最后才进 stable 频道。最后一层是快速发现和快速回滚：flag 不用部署就能关，团队有每周 on-call，事故复盘会问”哪一层应该拦住这个问题”。文章也坦白，目前还没有根据回滚指标自动收紧审批的 circuit breaker，工程师希望在更多代码走向零人工合并之前补上这一点。

审查质量靠 eval 和降噪来维护。团队把历史上引发事故的 PR 及其修复和回滚收集成评测集，每天跑一遍；每次事故都会扩大这个集子。噪音通过观察人对评论的反应来度量：修了、认为是错的、说是有意为之、还是觉得无所谓。作者是 agent 时噪音成本更高，因为 agent 会去修一个 nit，从而产生新的 commit 和又一轮 review。他们遇到过收敛问题：一个 CLI PR 一夜经过五十多轮 review 才被作者叫停；git blame 显示，reviewer 反复标记的代码里约 59% 是第一轮就存在的旧代码。于是团队加了轮次上限：三轮后让作者退一步重新考虑方案；前几轮之后只 re-review 新 diff；标记 bug 的类别而不是单个行；已经发过的 finding 不重复发。

人留在哪些环节？文中列举了几类：做不做这个功能、方向和品味、风险代码如计费、auto-updater 和 CI 工作流、会被别人模仿的架构、亲自读证据——测试输出、命令返回值、截图、reviewer 的 findings——以及对最终结果负责。整个团队的职责从”读每个 diff”变成了”替机器做不了的决定”。

共享上下文的方式也在变。团队没有正式机制，也不要求任何人完整记住 Claude Code。想了解某个模块时，就让 Claude 写一个针对该切片的 explainer，几分钟内得到反映当前代码状态的解释；也有人让 Claude 做一个小 artifact 来可视化代码。用开放的 Slack 频道也帮助团队在看别人 build 的过程中保持上下文同步。

文章最后给出可复制的落地清单：PR 之前把可运行的 checks 和 hooks 写进简短的 CLAUDE.md；用 /code-review 和 /security-review；把重复评论沉淀进 REVIEW.md。每个 PR 加 AI reviewer、自动安全审查，并要求所有 review 线程在合并前解决。审批按风险分级，先从严格开始，用数据证明后再放开；CODEOWNERS 和分支保护确保计费、CI、发布流程永远需要人；bot 的批准不能代替人。合并后用 merge queue、feature flag、内部优先、分阶段发布和一键回滚；把事故变成 eval 集，每次改动 prompt、工具或模型后重新评分。最终目标没有变：每个改动消耗更少人工时间，回滚频率不比以前高。