AI 写的代码怎么审：七层过滤法

让 AI 写代码不难，难的是它一天交上来三十个 PR，你敢不敢合。Anthropic 给出的答案不是「多派人看」，而是「换一套过滤方式」。

一、发生了什么

10 月 15 日，Anthropic 的 Addy Osmani 等三人在官方博客发文，讲 Claude Code 团队怎么做出代码评审。

几个数字值得先记住：Claude 大约写了 Claude Code 自身 90% 的代码；6 月到 9 月，代码库合并的 PR 数量翻了一倍多，需要回滚的比例反而下降 40% 以上；在他们的 monorepo 里，每天落地的改动从 5 月约 2500 个涨到 9 月 3 万多个。

团队的目标写得很直白：大多数 PR 最多经过一个人类（可以是作者本人）就合并，同时回滚率和事故率不许上升。内部数据显示，研究预览版上线后，拿到实质性评审意见的 PR 比例从 16% 升到 54%；超过 1000 行的大 PR 大多能查出问题，小 PR 多半干净返回。

他们的核心判断是：用「有没有人读过代码」衡量评审质量并不准，该问的是「这个改动可能出什么问题，哪道检查最该抓住它」。

带 3 到 8 人小团队的负责人：你不需要七层，但至少需要三层——自动评审、能阻断的检查、按风险分级的人工批准。缺一层，AI 写的量一上来就会漏。

独立开发者：你能省的是「自己当自己的评审」。让一个新上下文的模型复审 diff，比你自己再看一遍更容易发现问题，因为你已经知道自己的意图了。

刚用上 AI 编程的人：最容易犯的错是让模型说「做完了」。它说做完了不算，能跑起来的测试、构建、截图才算。

先把验证条件给它。 开 PR 之前，让 AI 跑测试、跑构建、给出对比截图，用输出证明结果。博客里引述 Claude Code 作者 Boris Cherny 的说法：给 Claude 一个验证工作的方法，大概是让结果好上 2 到 3 倍的关键。

写两个短文件。 CLAUDE.md 说明项目是什么、约定是什么、什么不做，保持简短；REVIEW.md 由代码 owner 写，说清这块代码「失败」长什么样、哪些路径可以跳过、提意见必须给到文件和行号。评审器反复标记同一个问题时，改文件，别改那行代码。

每个 PR 先过自动评审。 让它对着整个仓库和 PR 声明的意图读 diff，修 bug 的 PR 要找到根因。发现先由另一组模型投票验证，再以重要、小问题、历史遗留三档呈现，避免把老问题算到作者头上。

按改动分级，不按作者分级。 低风险（文档、文案、开关后的改动）自动检查全绿即可；普通产品改动一人；计费、自动更新、权限这类高风险两人。代理的批准永远不算人类批准，一次批准只覆盖一个 commit。

给评审设轮次上限。 他们踩过的坑：一个 PR 一夜之间跑了 50 多轮评审和修复。现在改成 3 轮后请作者重新想方案，之后只审新 diff，已经提过的问题不重复提。同时把事故和回滚做成测试集，每天跑一遍。

「自动评审过了就能合。」 代理的批准不算人类批准，这是他们写在流程里的硬规则。机器能放行低风险改动，但填不上需要人签字的位置。

「多审几轮更安全。」 他们统计过，评审器反复标记的内容里约 59% 是第一轮就已存在的旧代码。轮次越多，噪声越大，作者越麻木。先抓真 bug，再减轮次，顺序不能反。

「人都可以撤了。」 人撤不掉，只是换了岗位：决定这件事该不该做、盯高风险代码、定架构、看证据、对结果负责。谁提示了这个改动，谁就算评审人之一。

AI 写代码的评审不是「看得更仔细」，而是「把检查放到正确的位置」：能让机器拦的别用人拦，必须人签的别让机器签。

Anthropic 官方博客《Solving code review at Anthropic》，2026-10-15：https://claude.dev/blog/solving-code-review-at-anthropic/

功能与价格以官方公告为准。本文写于 2026 年 10 月 17 日。