像 Claude Code 团队一样做代码审查

Anthropic 前不久分享了 Claude Code 团队的代码审查实践：How the Claude Code team does code review。文章的核心目标只有一句话：在不增加回滚和线上事故的前提下，把人工审查的时间降到最低。审查不再是合并前的最后一道关卡，自动化检查贯穿始终，人的注意力只花在有风险的地方。

读完这篇文章，我们很有共鸣。我们是一支十几人的工程团队，过去一年多一直在做同一件事：把人的精力放在真正需要它的地方，其他的交给 AI。我们用来落地这件事的工具，就是我们自己做的 AI 代码审查服务 HeyDeer。下面结合 Anthropic 的文章，聊聊我们的做法，以及 HeyDeer 为什么是按这个思路设计的。

一、为什么不能再让人逐行审查

Anthropic 在文章中提到，Claude Code 约 90% 的代码由 Claude 编写，合并的 PR 数量在几个月内翻了一倍多。我们走过的路很相似。

过去，我们对代码审查的要求非常严格：每一行都要有人认真读，想一想有没有更好的写法。因为不好的代码一旦进了代码库，就很难再清理出去。

到了 Opus 4.1 的时候，团队 70% 到 80% 的代码已经由 AI 生成，GitHub 上等待审查的 PR 越积越多，人渐渐审不过来了。如今到了 Opus 5.5，模型已经足够强大，工程师主要负责设定目标，具体实现交给 coding agent，AI 写的代码占比接近 100%。审查如果还靠人逐行去看，人就成了整个流程里最慢的一环。

与此同时，逐行审查本身的价值也在下降。过去我们最担心的那些 code smell，现在交给 AI 很容易就能清理掉，不再需要人一行行去抠。具体怎么做，我们之后会单独写一篇文章介绍。

所以，问题不再是“怎么让人审得更快”，而是：

1. 哪些改动真正需要人来看？
2. 不需要人看的那些，怎么保证质量？

接下来分别回答。

二、哪些改动需要人来看：按风险分级

Anthropic 的答案是按风险分级的人工审批：由分类器根据改动本身（而不是作者是谁）判断风险等级。低风险的改动，自动检查通过后就不需要人批准；中风险需要一个人；高风险需要两个人。

HeyDeer 也是这样设计的。每次审查，HeyDeer 都会评估 PR 的风险等级（低、中、高），并说明理由。在设置里的“可自动批准的 PR”中，你可以决定 HeyDeer 能批准哪些风险等级的 PR。

低风险和中风险：交给 HeyDeer 批准

我们团队选的是“低风险和中风险 PR”：只要 PR 不在高风险等级，而且 HeyDeer 完整审查后没有发现问题，它就会直接批准，PR 随即自动合并进主干。

这种方式我们已经跑了 8 个月，至今没有出现过一次因为合并了有 bug 的代码而导致线上服务崩溃的情况。

高风险：人只判断方向，细节交给 HeyDeer

高风险的 PR 仍然需要另一位工程师批准。但人在这里的角色变了：不再是逐行挑错，而是从更高的层面判断这个 PR 的思路和方向对不对。这和 Anthropic 文章里“人类留在哪里”的结论一致：判断要不要做、审查架构、看改动背后的依据。细枝末节的问题，交给 HeyDeer 就好。

为了让人更快抓住重点，HeyDeer 提供了导览功能：

• 它把相关的改动归成组，并标上“必读”“建议阅读”“略读”，偏离主线的改动放到“其他”里并写明原因。你一眼就知道哪些可以跳过，只需要把精力放在最重要的部分。
• 它会给出 PR 的风险等级和判断理由，告诉你哪些地方需要重点确认。

审查者不用再从第一个文件读到最后一个文件，而是直接看最需要人来判断的那几处。

三、不需要人看的部分，怎么保证质量

把大部分 PR 交给 AI 批准，前提是 AI 的审查结果值得信任：既要找得全，又不能满是噪音。HeyDeer 在这两方面分别做了设计，并允许团队按自己的审查方式调节。

找得准：多个模型交叉审查、互相校验

Anthropic 的 AI 审查会让多个 agent 并行找 bug，再由其他 agent 对每条发现投票，只有通过的才会发布出来。

HeyDeer 更进一步：我们使用来自不同厂商的多个模型交叉审查、互相校验。单个模型很容易漏报，也很容易误报，而且同一个模型的多个副本往往会犯同样的错。不同模型的盲区不同，交叉审查能找出明显更多的问题，交叉校验又能过滤掉大量噪音和误报。

降噪同样是在保护人的注意力。误报太多，人处理不过来，最后就干脆不看了；如果完全交给 coding agent，它又可能盲目照着误报去改，让代码库越来越臃肿。只有审查结果足够准确，“交给 AI”这件事才成立。

不遗漏：用仓库检查落实团队规范

Anthropic 的做法是：同样的审查意见反复出现，就从源头修掉，写进 skills、lint 规则、CLAUDE.md 或 REVIEW.md。

我们的体会是，通用的代码审查工具很难满足特定代码库的需求。比如按钮文案该用什么大小写、界面文字的语言风格、团队对 React 某些用法的约定等等。这些规范写在 AGENTS.md 或 skill 里，coding agent 写代码时会参考，但在一次完整的代码审查中，它们很容易被淹没在大量上下文里，被漏掉。

HeyDeer 的仓库检查就是为此设计的。你在 .agents/checks 里用自然语言写下想要专门检查的要求，HeyDeer 会为每项检查安排单独的审查者，专门对照这一条去审查改动了相关文件的 PR，确保它不会被遗漏。

可调节：按团队的审查方式选择反馈范围

不同团队对审查意见的需求不一样，HeyDeer 提供了反馈范围设置：

• 精简：适合仍然以人工审查为主的团队（比如金融相关的业务）。它只保留重要的问题，让人把时间花在最值得关注的地方。
• 平衡（默认）或详尽：适合大量审查和修复都交给 coding agent 或 HeyDeer 的团队。修复小问题对 AI 来说几乎没有成本，这样即使是细小的问题也能得到解决。

四、发现问题之后：交给 Autopilot 修到收敛

审查发现了问题，还得有人去修。如果每一轮都要工程师回来看意见、让 agent 修改、再等下一轮审查，注意力还是会被牵扯住。

Anthropic 在文章里坦白了一个很真实的问题：AI 审查可能无法收敛。他们有个 PR 一夜之间来回审查、修复了五十多轮。审查者反复标记的问题里，约 59% 出在第一轮审查时就已经存在的代码上：每一轮并没有发现新引入的 bug，只是又多翻出几个老问题。他们后来做了一系列改进：限制轮数、后续只审查新改动、不重复已经提过的问题等等。

HeyDeer 从一开始就把“收敛”当作审查设计的目标。当 HeyDeer 找出一堆小问题时，你可以直接交给 Autopilot：它会修复待处理的问题、推送到 PR 分支，再审查自己的修改，如此循环，直到 PR 可以合并，或者遇到需要人来回答的问题。在我们的实际使用中，大部分 PR 两轮就能处理完所有问题，复杂一些的三轮。Autopilot 最多跑 5 轮，停下时会说明原因，以及还有哪些事需要你处理。

这件事对我们很重要。人的上下文切换成本非常高，我们不希望工程师把心思同时挂在两件事上：一边写新功能，一边惦记着上一个 PR 的审查意见改完没有。点完 Autopilot，工程师就可以安心去做下一个任务了。

把这几部分连起来，就是我们团队现在的日常：工程师提完一个 PR，就可以去做别的事。HeyDeer 负责审查，发现问题由 Autopilot 修复；低风险和中风险的 PR 由 HeyDeer 批准，直接合进主干；高风险的 PR，由另一位工程师借助导览再看一眼方向。

五、什么样的团队适合这样做

“只有高风险的改动才需要人来审查”，这种方式适合谁？我们的看法是：以现在 AI 的能力，大部分创业公司和中小型公司，只要业务不涉及特别敏感的信息，其实都可以这样做。你可以先从只让 HeyDeer 批准低风险 PR 开始，跑一段时间、建立信心之后，再逐步放开到中风险。

写在最后

对照 Anthropic 的实践，我们和 HeyDeer 的对应关系大致如下：

工具会变，模型会变，但目标不变：人的注意力是团队里最稀缺的资源，要把它花在最值得的地方。如果你的团队也在面对“AI 写得太快，人审不过来”的问题，欢迎试试 HeyDeer。