先看一组压力数据
Anthropic 的 Claude Code 团队在 2026 年 10 月 15 日公开了他们的代码评审流程。背景是：Claude 大约写了 Claude Code 自身九成的代码，而 Anthropic 主仓库每天落地的改动从 5 月的约 2,500 个涨到 9 月的 3 万多个——这个量级下，逐行人肉审查已经不可能。
他们的做法不是取消评审，而是把「读代码」大部分交给机器，把人的时间留给只有人能处理的问题。效果上，6 月到 9 月，Claude Code 仓库合并的 PR 数量翻了一倍多，而需要回滚的比例下降了 40% 以上。
六层检查，底下垫着回滚
一个改动从工程师电脑到用户，要过六层：
第一层，PR 之前。先给 Claude 一个能跑的东西——测试、构建，或一张能和设计稿对比的截图，要求它贴出输出而不是说「做完了」；再用全新上下文的子 agent 评审 diff。Claude Code 的作者 Boris Cherny 把这件事称为最重要的经验：给模型一个自我验证的方式，最终结果能好两到三倍。同类问题反复出现时，他们改的不是代码，而是源头——技能、lint 规则或说明文件。
第二层，每个 PR 都过 AI 评审，它拿 diff 对着整个仓库和 PR 声明的意图看。上线研究预览版时，内部 PR 拿到实质性评审意见的比例从 16% 升到 54%。为压制噪音，findings 要多个 agent 交叉验证、投票后才发出，纯风格与清理类建议直接丢掉，并标注是 Important、Nit 还是 Pre-existing（历史遗留），免得作者替旧代码背锅。
第三层安全评审可以卡住合并——只要有未关闭的 finding，PR 就合不了。第四层是常规 CI：lint、类型检查、多平台测试、构建。第五层才是人，而且按风险分级：文档、文案、开关后的增量改动，自动评审和安全检查都绿了就不用人工批准；普通产品改动与缓存、自动更新这类敏感区，一个人批；最高风险代码和固定名单路径，两个人批。等级由改动本身决定，不由作者决定，由分类器判定。有个细节很关键：agent 的批准永远不算人的批准，而且一个批准只对一个具体提交有效，之后有新提交就得重新批。谁让 agent 干的活，谁就算这次改动的责任人之一。第六层是合并队列与开关：改动合到主干后会重跑全部检查；新行为先用开关发给内部员工，公开发布先走 latest 通道，stable 通道滞后。
他们踩过的坑，比流程更有价值
评审 agent 和编码 agent 会互相刷工作量：有个 CLI 的 PR 一晚上来回审了五十多轮，最后是作者手动叫停的。他们用 git blame 查了评审反复标记的代码，约 59% 是评审第一次跑时就存在的老代码——评审不是在发现新 bug，只是每一轮多挖出几个老毛病。
所以他们加了几条收敛规则：超过三轮，评审要请作者停下来重新想思路；前几轮之后只审新 diff；指出 bug 的类别而不是某一行，让作者一次改干净；已经发过的 finding 不重复发。衡量指标也配了对：既看抓到多少真 bug，也看几轮能过。
对做企业数字化/小团队的实际启发
小团队没有这套基建，但有三件便宜的事能抄：一是让 AI 干活时先给它一个能跑的自检动作，再要求它贴输出；二是把反复出现的评审意见沉淀进一个文件，而不是每次口头重复；三是按「出错了能不能撤」分风险等级，可回滚的放开手，不可逆的才多要一个人看。
还有三条比工具更重要的规矩：等级看改动、不看人；机器人不能替人签字；谁指挥 agent 写的代码，谁承担后果。
评论交流
欢迎留下你的想法