企业官网建设流程全解析

当AI写下90%的代码：拆解Claude Code团队的七层评审体系

原文：Anthropic Claude.dev Blog - 《Solving code review at Anthropic》（https://claude.dev/blog/solving-code-review-at-anthropic/）

前言

做 Agent 开发的同学都遇到过同一个焦虑：模型生成的代码越来越能跑，但评审跟不上产出速度。逐行人审变成了流水线上最慢的一环，要么拖着合不进去，要么闭着眼睛点批准。

Anthropic 的 Claude Code 团队把这个问题推到了极限——Claude Code 仓库里约九成代码由 Claude 自己写。他们的做法不是加强人审，而是把整个评审体系重构成七层漏斗：机器分层过滤，人类只在高风险处介入。结果很直接：今年 6 月到 9 月，合并 PR 数量翻倍以上，需要回退的 PR 占比下降超过 40%；整个 monorepo 的日变更量从 5 月的约 2500 涨到 9 月的 3 万以上。

这篇笔记按原文拆解这套体系的每一层，重点讲清楚：每层抓什么问题、人类保留在哪几个决策点、以及我们自己的项目能搬走哪些东西。

一、评审问题被重新定义了

原文里最值得记住的是这句转变：评审不再问「人类是否读过这段代码」，而是问**「这个变更可能出什么问题？哪个检查——自动的还是人工的——适合捕获它？」**

这个转向意味着评审从「合并前的终点闸门」变成了类似拼写检查的持续过程：AI 评审在 PR 创建之前就已经开始，人类注意力从通读代码转为集中在高风险决策上。后面六层都是这个思路的展开。

二、七层评审漏斗

原文把整个流程画成一个漏斗图：每层捕获一部分问题、放过另一部分，极少有问题能穿透所有层，漏网的最后靠回滚兜底。逐层看：

第 1 层：PR 创建前的验证

给 Claude可运行的验证物——测试、构建、和设计稿对比的截图，要求它展示输出而不是声称完成。另外有子代理用全新上下文审查 diff，避免被生成代码时的上下文「带偏」。团队还沉淀了内部技能：一个找 bug、一个简化 diff、一个端到端验证行为。

原文引用 Boris Cherny 的判断：给 Claude 提供验证方式，是提升最终结果质量最重要的单一因素，估计能让结果好 2 到 3 倍。

第 2 层：每个 PR 的 AI 评审

人看之前，Claude 先对照整个仓库和 PR 意图读 diff。公开版已经 GA：Claude Code 的 Code Review（Team/Enterprise 可用），本地可用轻量的 /code-review 命令。

机制上有两个细节值得学：

• 多代理并行找 bug，独立小组对每个发现投票，足够多的代理同意才发布评论；
• 纯风格、诊断、清理类的发现被直接丢弃——这是 A/B 测试后保留的过滤策略。

发现的评论按严重度行内标注为 Important、Nit 或 Pre-existing，每条必须被答复（修复或说明理由），代理经常在夜间自动接手修复。

第 3 层：可阻断的安全评审

独立的自动安全评审，有未解决的安全发现时 PR 无法合并。这一层有开源的 security review GitHub Action 和 /security-review 命令可以直接用，是七层里迁移成本最低的一层。

第 4 层：可阻断的自动化检查

lint、类型检查、多平台测试、构建。一个典型的 CLI PR 在有人看之前可能已经跑了几十个检查。PR 模板还要求填写「如何测试」和「如何撤销」两栏——Claude 可以代填，但发起变更的人要签字确认。

第 5 层：按风险分级的人工批准

这是整套体系里人类保留最集中的地方。决定风险等级的是变更内容本身，不是作者：分类器读 diff 选出风险层，另一个分类器判断是否需要追加人手。

三条配套规则很关键：轻量路径只给受信作者（主要是所属团队），代理的批准不算人类批准；谁提示代理发起变更，谁就是必需的评审者；批准只覆盖特定 commit，新 commit 进来必须重新批准。

第 6 层：合并队列与渐进发布

合并队列把变更重新套用到 main 上重跑全部检查，防止两个各自绿灯的 PR 合在一起弄坏主干。新行为先通过 flag 对内部员工发布，再走 latest 频道，stable 频道滞后跟随。

第 7 层：快速检测与快速回滚

flag 不用重新部署就能关闭；每周 on-call 轮值；每次事故复盘都要回答「哪一层本应捕获这个问题」。原文也坦承：目前还没有「指标异动就自动收紧批准」的断路器机制，工程师们希望未来补上。

三、评审器自己也要迭代：事故变评测集

这套体系最让我意外的是第四部分——他们用工程化手段持续改进 AI 评审器本身：

• 事故回放：把导致过事故的历史 PR（含回退和修复）收集起来，人工确认 bug 位置，评审器每天在这个集合上跑一遍回归；
• 噪声测量：按人类对评论的实际处置分类（修了、说错了、说有意为之、说无所谓），并在已知干净的 PR 上跑评审器，统计造成有害改动的报告数量；
• 优先级写死：先抓真 bug，再减评审轮次。

对我们的启发是：AI 评审不是接上就完事的工具，它和模型一样需要评测集和回归。

四、收敛机制：评审轮次失控怎么办

代理互审有个经典故障模式：评审代理提问题，作者代理修，修完又触发新评论，循环不止。原文给了一个真实案例——某个 CLI 相关的 PR 一夜里经历了超过 50 轮评审加修复，而且 git blame 显示审阅器反复标记的代码里约 59% 是第一轮就存在的旧代码。

团队的解法是一组收敛规则，值得我们直接抄：

1. 轮次上限：3 轮之后要求作者退一步重新考虑整体方案；
2. 前几轮之后只做 diff 范围的重审，不再扩大范围；
3. 标记 bug 类别让作者修全部同类实例，而不是只修被点名的那一行；
4. 不重复发布已提过的发现；
5. 审阅代理夜间巡查现有代码，把存量旧 bug 主动挖出来。

五、能搬回自己项目的最小集合

不是每支球队都是 Anthropic，但这几样东西迁移成本很低：

其一，一份 REVIEW.md。由代码属主编写，告诉审阅器这片代码里什么最重要。原文总结的好的特征是：简短；说清楚这个仓库的「失败」长什么样（文档类仓库的失败是撒谎，配置类是路由错误）；限制 nit 级评论；要求给出文件加行号作为证据。下面是一份示意结构（字段按原文要点整理，非官方模板原文）：

# REVIEW.md（示意结构） ## 这个目录里什么最重要 - 鉴权中间件：任何绕过校验路径的改动都算高危 ## 失败长什么样 - 配置类改动：路由错配 = 静默失败，优先级高于风格问题 ## 评审要求 - 发现必须附文件名和行号，禁止按符号名猜测 - 摘要以计数开头（如「发现 2 处问题」），无问题要明说

其二，可阻断的安全评审。直接接开源的 security review GitHub Action，先在某个高风险仓库试点，跑几周调好 REVIEW.md 再铺开。

其三，风险分层写进流程文档。列出哪些路径（计费、CI 工作流、安装器、自动更新）始终需要人审，由变更内容决定等级，宁可先严后松。

总结

这篇原文本质上回答了一个问题：当产出速度不再受人类打字速度限制时，质量该靠什么保证。Claude Code 团队的答案是七层漏斗加风险分级——机器负责海量阅读，人类负责判断该不该做、风险在哪、是否拥有结果（他们内部的说法是「你落地的变更你负责」）。对普通开发者来说，最先可以落地的是 REVIEW.md、可阻断安全评审和收敛轮次上限这三件事；等团队习惯了，再考虑把低风险变更的合并权逐步交给自动检查。