Agent 写代码之后，Claude Code 团队怎么做评审
用 Claude Code、Codex 这类 Coding Agent 写代码，开 PR 的速度比以前快了太多。agent 半夜也能干活，早上醒来可能就多了几个等着合并的 PR。代码写得快了，看代码的还是那几个人。
这周读到两篇可以放在一起看的东西。一篇是 Claude Code 团队在 claude.dev 博客上发的 How the Claude Code team does code review，由 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 署名，讲 agent 写了大部分代码之后他们怎么做代码评审。另一篇是 The Register 10 月 16 日的报道：PostgreSQL 19 推迟发布，原因之一和 AI 辅助的代码评审有关。
两件事绕着同一个问题：AI 写代码、查代码都变快以后，人的时间该花在哪。下面先按原文的顺序把 Anthropic 的流程拆一遍，再看 Postgres。
评审瓶颈
原文开头提了一句他们以前说过的话：Claude Code 自己的代码，大约 90% 是 Claude 写的。
代码量也跟着涨。Anthropic 的 monorepo 里，每天落地的变更从今年 5 月的约 2,500 个涨到了 9 月的 3 万个以上。Claude Code 有自己单独的仓库，不在这个 monorepo 里，但原文说它的压力也不小。按他们的说法，在这种速度下，人工逐行评审「极其困难，甚至做不到」，评审成了瓶颈。
他们换了一个问题来问。「有没有人读过这段代码」只能粗略地代表他们关心的事，他们更想知道：这个改动可能出什么错，哪一道检查（自动的还是人工的）最适合把它抓出来。
评审的时间点也跟着变了。以前评审是终点前的一道闸：写完代码、开 PR、等同事看。现在评审一直在跑，像边写边查的拼写检查，多数改动在找人看之前，已经被 Claude 审过、修过至少一次。
原文说现在最缺的是人的时间和注意力，而且要算两头：人花在评审上的时间，和人花在修坏代码上的时间。评审省下的时间如果换成了修 bug 的时间，就等于没省。所以他们给 Claude Code 的几个仓库（CLI、桌面端和网页端、移动端）定的目标是：多数 PR 合并时最多只有一个人参与，这个人可以就是作者，同时回滚和事故不能增加。他们看每个 PR 的人工批准次数（中位数和第 95 百分位）、人工评论数，以及 PR 等人处理的时长；回滚率和事故率是护栏，一旦上升，就说明人的时间只是挪了个地方。
一个改动要过几层
原文把一个改动从作者电脑到用户手上的路径拆成了几层：开 PR 前先自证；每个 PR 都要过 CI、Claude 评审和安全评审，这几步全自动；然后是按风险决定的人工审批；再进合并队列；合并后先藏在 flag 后面给内部用，再渐进发布，最后有人盯着，随时准备往前修或者回滚。这几层各有漏洞，位置不同，从一层漏下去的问题多半会被后面某层接住。极少数穿过所有层的，靠最后的快速回滚兜底。
先自证再开 PR
现在大部分评审发生在 PR 出现之前。他们给 Claude 一个能实际运行的东西，比如测试、构建，或者拿来和设计稿对比的截图，要求它把运行结果拿出来，不能只说一句「做完了」。之后再派一个 subagent，在全新的上下文里审这份 diff。不少人开 PR 前还会跑几个内部 skill，分别负责找 bug、精简 diff 和端到端检查行为。
Claude Code 的创造者 Boris Cherny 说过，给 Claude 一个验证自己工作的办法，大概是拿到好结果最重要的一件事，他估计能让最终结果好两到三倍。
如果自动评审一直在标同一类问题，他们会从源头改：改 skill、加 lint 规则，或者更新说明文件。CLAUDE.md 写项目的技术栈、约定、目标和不做什么，每次评审都会加载，所以要写短。REVIEW.md 由代码负责人来写，告诉评审器这部分代码里什么最要紧。原文说好的 REVIEW.md 都很短：写清这个仓库里「出错」长什么样（文档出错是「它在撒谎」，配置出错是「它把请求路由错了」），限制小毛病的数量，列出可以跳过的路径，要求用文件和行号作证据。
每个 PR 都有 AI 评审
每个 PR 在人看之前都会先过一遍 Claude 评审。它结合整个仓库和 PR 写明的意图来读 diff，看改动有没有解决问题、和系统合不合得上、会不会弄坏别的东西。对外的版本叫 Code Review for Claude Code，已在 Team 和 Enterprise 套餐上正式开放，本地可以用 /code-review 跑轻量版。研究预览上线时，内部 PR 收到实质性评审意见的比例从 16% 升到了 54%。
评审意见给人看之前还要先过一道核实：几个 agent 同时找 bug，再由另一组 agent 对每条发现投票，足够多的 agent 认为是真问题才发出来。只关于风格、诊断信息或代码整理的意见直接过滤掉。剩下的按严重程度排序，标上三种标签之一：Important 是重要问题，Nit 是小毛病，Pre-existing 表示 bug 在这个 PR 之前就有，免得算到作者头上。每条意见都必须回应，要么修掉，要么写明理由后关掉。
安全评审和 CI 都能拦
安全问题有单独的一道自动评审。bug 评审或安全评审里只要还有没关掉的意见，PR 就合不进去，误报可以写一句理由关掉。再往后是 lint、类型检查、各平台测试和构建，一个典型的 CLI PR 在有人看之前可能已经跑了几十项检查。PR 模板会问改动怎么测的、出了问题怎么撤回，可以让 Claude 填，但要由提出改动的人签字确认。
按风险决定几个人批
改一处文档和改自动更新器，风险差别很大。原文给了三档：
| 风险 | 例子 | 需要几个人批准 |
|---|---|---|
| 低 | 文档、文案、只在内部用的功能、藏在 flag 后面的增量改动 | 自动评审和安全检查全绿后，不需要人 |
| 中 | 普通产品改动，以及缓存、自动更新器、系统提示词这类敏感区域 | 一个人 |
| 高 | 风险最高的代码，以及一小批永远需要两个人的路径 | 两个人 |
风险等级由改动内容决定，和作者是谁无关：一个分类器读完改动给它定级，第二个分类器再判断，即使按等级不需要人，这个改动是否还得再加一个人。
另外几条规则：
- 只有仓库信任名单上的作者能走轻量路径，这些人大多是负责这个仓库的团队，其他人的改动都需要第二个人批准；
- 代码负责人列为敏感的路径和所有 CI workflow 文件，总要有人看；
- agent 的批准永远不算人的名额，自动评审可以放行低风险改动，但填不了要求由人来占的位置；
- agent 写的 PR，指挥这个 agent 的人本身就算一名审批人，和他亲手敲了这些代码一样；
- 一次批准只对应一个具体的提交，之后只要再有系统没法确认的提交（比如 agent 推上来的代码），就要重新批准。
合并队列、flag 和回滚
合并队列会把改动放到最新的 main 上再跑一遍所有检查，避免两个各自通过的 PR 合在一起后把 main 弄坏。新功能通常先藏在 flag 后面开给 Anthropic 员工用，公开版本先发 latest 渠道，stable 渠道随后。flag 不用重新部署就能关，Claude Code 有每周轮换的值班，事故复盘会问这个问题本该由哪一层抓住。
原文也写了还没做到的部分：发现一次坏的合并，目前还要靠作者、值班人员和回滚、事故看板；他们还没有在指标变坏时自动收紧审批的熔断机制，工程师们希望在更多代码走零人工合并之前先把它做出来。
评审器自己也要被考
团队把过去引发事故的 PR 连同后来的修复和回滚收集起来，请熟悉那部分代码的工程师逐个确认 bug，做成评测集，评审器每天跑一次。评审器的提示词、工具或模型每改一次，都拿整个集合打分，分数上去了才保留。
噪音也要算。他们看人怎么对待每条意见：修了、说它错了、说这个行为是有意的，还是觉得无所谓；也拿已知没问题的 PR 去跑评审器，数它有多少次会诱导人做出有害改动。作者是 agent 时噪音代价更高：人几秒钟就能略过一条小毛病，agent 会去修，于是多一次提交，再多一轮评审。
评审还得能收敛。有个 CLI 的 PR 一夜之间来回评审、修复了五十多轮，最后是作者手动叫停的。他们对评审器反复标记的代码跑了 git blame，大约 59% 在评审器第一轮时就已经存在。评审器很少找到新 bug，每一轮只是多挖出几个旧的。现在的规则是：最多三轮，三轮后请作者重新考虑思路；前几轮之后只审新增的 diff；按类别标 bug，让作者把同类问题一起修掉；发过的意见不再重复。另外有评审 agent 每晚扫一遍现有代码，找旧 bug。
这些改动之后，内部 PR 一轮评审加修复就通过的比例从 65% 升到 78%，需要五轮及以上的从 8.9% 降到 1.5%，平均评审次数从 2.08 降到 1.32。
人留在哪些地方
原文说，他们的工作已经从逐个读 diff 转到了五类机器不擅长的决定上：这个东西该不该做；计费、自动更新器、CI workflow 这类高风险代码；会被别人照着抄的架构；读证据，包括测试输出、跑过的命令和结果、截图和评审意见；以及为结果负责。有个团队宣布自己的评审瓶颈已经解决，但仍对团队外部提交的改动保留人工评审，好让有人问一句「我们该做这个吗」。
评审的另一件事是让团队理解代码库，这一点他们没有正式流程。想了解哪一块，就让 Claude 针对那一块写一份讲解，几分钟就好，内容和当前代码一致。团队还有一条约定：小改动或中等改动合进去后出了问题，通常由作者来修。撑住这条约定的是：改动小；一切都能撤回，多数错误几分钟内就能撤销；影响范围越大要求越高；遥测和内部使用能让退化很快暴露。
两组数字
原文里有两组数字口径不同，要分开看。
前面那组 2,500 到 3 万以上的数字，说的是整个 Anthropic monorepo。
第二组只针对 Claude Code 自己的仓库，时间是 6 月到 9 月：合并的 PR 数量翻了一倍多，需要回滚的 PR 占比下降了 40% 以上。原文是把这组数字和上面这套评审流程放在一起讲的。
两组说的是两个仓库，第一组的变更量和第二组的回滚占比不能放在一起算。
PostgreSQL 19 推迟
据 The Register 报道，PostgreSQL 全球开发组推迟了 PostgreSQL 19 的发布。这个版本原定 9 月底或 10 月初发布，现在预计 11 月 19 日前后正式发布，同时撤下了 8 到 10 个重要特性，推到明年的 PostgreSQL 20。
解释这些撤回的是 Peter Eisentraut，他是 PostgreSQL 支持与咨询公司 EDB 的副总裁，也是 PostgreSQL 主要的 committer 之一。committer 指有权把代码合进主线的核心开发者。按 The Register 的转述，他认为撤回的原因至少有一部分可以归到开发者使用的 LLM 代码评审上。
AI 评审只是原因之一。他在博客里写到，一些被撤回的特性有严重的架构缺陷，很难「快速地、在 beta 期间」修好。
AI 评审那一部分，挖出来的是一长串「相对无害、涉及各种边界情况」的问题。放在以前，这类问题多半要在发布后的五年里陆续发现、陆续出补丁。他举了个例子：「有了 LLM 辅助的代码评审，这类问题能被快得多地发现，然后你就对着一份四十条的缺陷报告。哪怕每条平均只要三行修复，处理每一条都有固定开销，然后时间就用完了。」这里的四十条是他举的例子，报道没有给出实际的问题数量。
时间上也有错位。几个大特性写出来时，LLM 辅助评审还没现在好用；临近发布的几个月里，AI 辅助评审的用法被摸得更清楚，效果也上来了。Eisentraut 说：「实际的质量门槛，是在特性写完并提交之后才被抬高的。除非 LLM 辅助评审的能力继续按现在的速度提升，否则这种情况在以后的开发周期里应该会自己理顺。」他还专门说明，这些撤回和 vibe coding 无关，因为大部分新特性写出来时，这种做法还没出现。
被撤下的特性里有 SQL/PGQ，也就是 2023 年进入 SQL 标准的属性图查询，用来探索由边连接起来的节点之间的关系。PostgreSQL 贡献者 Tom Lane 当时警告：「我愿意赌一顿晚饭，如果我们在 v19 里发布它，发布后会发现一些要到 v20 才能修的 bug。」
Eisentraut 说 19 仍会是「一个很棒的版本」，其中有 REPACK CONCURRENTLY，回收磁盘空间时可以避开会锁表的 VACUUM FULL；「经过这么多额外的审查，它会非常可靠。」几个月前，开发者还以为 PostgreSQL 20 只修 bug，现在它多半会收下从 19 撤出来的特性。
我的几点收获
- 找问题和修问题要一起算。 Anthropic 算人的时间时，把修坏代码的时间也算了进去。按 Eisentraut 的说法，Postgres 的问题出在修的这一头：问题发现得快了，每条问题的处理开销却是固定的。我的理解是，引入 AI 评审前，最好先估一下团队修得过来多少。
- 评审放在什么时候很要紧。 Anthropic 的评审在写代码时就在跑。Postgres 的大特性是在 AI 评审变好用之前写完、提交的，门槛是事后才抬高的。同一批问题，写代码时发现和临近发布时发现，留给人处理的时间差很多。
- 给发现分轻重。 Anthropic 把意见分成 Important、Nit、Pre-existing，纯风格类直接过滤，旧 bug 交给每晚的扫描。Postgres 挖出来的多是相对无害的边界情况。不分轻重的长清单，最占人的时间。
- 评审要能停下来。 三轮上限、只审新 diff、按类别报 bug。Anthropic 加上这几条之后，平均评审轮数从 2.08 降到 1.32。
原文没说的
- Claude Code 仓库的两个结果数字都是相对值，没有合并 PR 的绝对数量，也没有回滚占比的起点。
- 事故率被列为护栏，但没有公布它的变化。
- 6 到 9 月的结果有多少来自这套流程，原文没有拆开分析。
- 风险分类器的准确率、各档 PR 的占比，都没写。
- PostgreSQL 这边，报道没有给出 AI 评审挖出的问题总数，也没有逐个说明每个特性被撤回的原因。
写在最后
原文结尾说，评审漏掉东西时，他们会去问模型当时缺了什么信息，再把补救写进 CLAUDE.md、某个 skill 或一项新检查里，目标是每个改动花的人工时间更少，回滚不比以前多。
原文也提到，对外的 Code Review 产品只给意见、不给批准，批准 PR 仍由人来做；他们内部仓库让负责人决定哪些低风险改动可以只凭自动检查合并。外部团队拿到的和他们内部的做法不完全一样。
如果团队已经在让 agent 开 PR，原文清单里有几步门槛很低：给评审轮数设上限，把 agent 的批准从人工名额里拿出去，PR 模板里加上「测试」「风险」「如何撤回」三栏，把风险分级写下来，先从严，有了证据再放宽。