Anthropic让agent互相投票审代码，回滚率降了40%

Anthropic公开了Claude Code团队在用的代码审查配置。三个数字先摆出来：合并的PR翻了一倍多，回滚降了40%以上，带真实审查评论的PR从16%涨到54%。

前两个数字容易让人兴奋，第三个才是重点。16%意味着在这套东西之前，八成以上的PR所谓的review，就是有人点了个通过。有网友在讨论里说得直接：大部分review就是一个没打开diff的人竖了个大拇指。

这套配置怎么跑的，五个部分。

一，审查在PR创建之前就开始了。Claude跑测试、构建和linter，把输出贴出来，而不是回一句“done”。然后第二个agent在一个全新的上下文里读diff。写代码的和审代码的不是同一个上下文，这点后面还会出现。

二，仓库里放一个REVIEW.md。由代码owner写，内容很具体：这个目录下什么样算失败，挑刺最多挑几条，哪些路径直接跳过，提问题时必须给出文件和行号。把重复出现的审查意见从评论区搬进这个文件，agent每次都能读到。

三，多个agent并行找bug，另一组agent对每个发现投票。票数够才发出来，风格类的挑刺直接丢掉。有网友说这是整套东西里最意外的一环：一个agent找出来的东西是噪音，三个agent都同意才算信号。

四，如果你是一个人审PR，让一个新上下文的agent带着REVIEW.md再过一遍，补你扫过去没看见的部分。

五，每条发现都必须有回应。修掉，或者写理由关掉。有未关闭的发现，PR不能合并。

想抄的话，清单不长：

• CLAUDE.md写短一点，只列agent能实际跑的检查
• 加REVIEW.md，把反复出现的评论搬进去
• 每个PR前跑/code-review和/security-review
• PR模板加Testing、Risk、How to revert三栏
• 限制审查轮次，几轮之后只看新增的diff

讨论里有个提醒值得记下。有网友说，合并PR翻倍本身不说明质量，可能只是盖章变快了，真正该盯的是评论率从16%到54%。这个提醒是对的。另一个网友问token开销，这套流程确实不省token，并行找bug再加投票，成本摆在那。

还有人把fresh context推得更远：Claude审Codex写的，Codex审Claude写的。同家族互相审，像同一个人把同一段代码读了两遍。

三个东西都不新：干净上下文、多agent投票、发现必须闭环。组合起来的效果是让审查从走过场变成有成本的动作。写PR的agent不能给自己的PR签字，这条可能是最容易抄的一条。

来源：Anthropic博客 Solving code review at Anthropic，原推文 Yarchi。