# AI 审查者一晚上跑了 50 轮还停不下来，Anthropic 决定先教它什么时候收手 **Summary:** 一个 Claude Code PR 一晚上跑了五十多轮审查和修复才被人叫停。本文据此讨论：在拿 AI 审查当理由减少人工审批之前，先定好停止规则、收窄审查范围，同时跟踪漏到线上的缺陷和返工成本。 - Canonical: https://markhuang.ai/zh/news/claude-code-review-rounds-stop - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-10-16 - Section: News - Tags: Claude Code, 代码审查, 编程 Agent, 开发者效率, 软件可靠性 - Source: [Claude Developer Blog](https://claude.dev/blog/solving-code-review-at-anthropic/) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![半透明电路瓦片在金属轨道上围成圆圈，两枚检查镜头下方留有开口，旁边是琥珀色的停止控制按钮](https://cdn.markhuang.ai/news/claude-code-review-rounds-stop/hero.webp) *概念图：一个自动审查循环需要知道何时停下来重新考虑。* 一个 Claude Code 的 pull request 一晚上跑了五十多轮审查和修复，最后被作者手动叫停。这个细节来自 [Anthropic 10 月 15 日发布的代码审查流程介绍](https://claude.dev/blog/solving-code-review-at-anthropic/)，比"agent 已经能读完大部分代码"这个说法更让我在意——AI 审查者一直在给彼此找活干，直到有人介入才停下来。 在拿 AI 审查当理由减少人工审批之前，我会先把停止规则定下来。自动审查确实能省下注意力，但 agent 的作者也可能把每条评论都变成一次修改、再触发一轮审查。我希望这个循环最后能落到一个有人能负责的改动上。 Anthropic 提到，调整审查规则让结果收敛之后，平均审查轮次从 2.08 降到了 1.32，需要五轮以上的 PR 比例从 8.9% 降到 1.5%。我觉得这些内部数据有参考价值，因为它们衡量的是完成一个 PR 到底要过多少轮审查。找出更多 bug 只是其中一部分工作。 ## 审查者一直在"发现"老代码 团队查了审查者反复标记的内容，发现大约 59% 的问题代码在第一轮审查时就已经存在。每一轮审查都在揭开更多已有的问题，而不是主要找最新修复引入的 bug。 这些发现不一定是误报，老 bug 一样可能很严重。但审查的性质变了：本来只审查一个改动，结果变成了审查周围所有代码。如果作者把每条意见都自动修掉，补丁就会一直膨胀，最初要改什么反而越来越看不清。 Anthropic 改了审查规则。三轮之后，审查者会要求作者退一步重新考虑方案。前几轮过后，重新审查只关注新的 diff。审查者会指出某一类 bug，让作者一次性修完所有同类问题，避免重复已经提过的意见。夜间审查仍然会检查现有代码。 我喜欢这种分离方式。不相关的发现应该保持可见，给它一个负责人，再决定它是否必须阻塞当前改动。审查机器人不应该因为顺手发现了别的问题，就悄悄把任务做大。 ## 谁能合并，仍然是关键问题 这套流程站得住脚的地方在于，Anthropic 在模型周围保留了多层检查。团队提到了必需的 CI、单独的安全审查，以及会把改动和最新 main 做对比的合并队列。未解决的审查意见必须修复，或者给出理由说明为什么不修。 人工审批按风险等级决定。可信作者在低风险改动上可以走更轻的流程，敏感路径仍然需要人工。agent 的审批不能替代必须的人工环节，审批也只覆盖特定的 commit。在决定哪些改动可以跳过人工审查时，我会保留这些约束。 公开产品的角色更窄一些。[Code Review 文档](https://code.claude.com/docs/en/code-review)说明它只发布审查意见，不会批准或阻止 pull request。它读取 diff 和周围代码，但不会构建或运行。买了这个审查工具，并不等于拿到了 Anthropic 那一整套验证和发布流程。 > **Info:** > > 我会用轮次上限来触发一个决策：收窄改动范围、调查分歧原因，或者交给人来审查。达到上限不等于缺陷已解决，不能就这样放行。 当 agent 们反复意见不一时，这个区别就很重要了。再来一轮也许能发现有用的东西，但也可能是在提示你该去看看需求或设计方案了。在让机器继续跑之前，我更希望作者先说清楚还有哪些地方不确定。 ## revert 变少了，但问题没有全部回答 Anthropic 说六月到九月之间，Claude Code 代码库里合并的 PR 翻了一倍多，被 revert 的比例下降了 40% 以上。这算是整个流程的一个积极信号。不过这篇介绍没有给出绝对 revert 率，也没有说明是哪些改动带来了改善。 在 [Hacker News 的讨论](https://news.ycombinator.com/item?id=50122951)里，有人质疑改动数量是否真的转化成了用户价值。也有人指出，revert 率改善的同时仍可能存在安全问题。这些评论并不能证明 Anthropic 的流程不安全，但我同样担心这些数字漏掉了什么。 [Alex Ewerlöf 在质疑"编码问题已经解决"的文章里](https://blog.alexewerlof.com/p/coding-is-not-solved)追问了运维成本：廉价生成留下的烂摊子谁来收拾？Anthropic 的做法是让每一个上线的改动都有人负责。他们公开的目标把修复故障花的时间和审查花的时间算在一起。我也想同时算这两笔账。 团队想要的一种控制手段目前还没有。他们说还没有自动熔断器，不会在 revert 或事故数量上升时自动收紧审批。检测仍然依赖作者、值班工程师和监控面板。在放开更多无人工审批的合并之前，我会先确定谁有权收紧规则、在什么情况下收紧。 ## 我会先抄哪几条 在[我之前关于补丁验证成本的文章](https://markhuang.ai/news/coding-agents-patch-proof-cost)里，我把验证排在了廉价输出前面。Anthropic 的这篇介绍让我又多了一项要检查的东西：审查是停在任务范围内，还是不断把任务做大。 我会先测量通过审查需要的轮次、被接受或被拒绝的意见背后的人工投入，再看有多少问题漏到了线上。我会限制反复审查的轮次，把后续审查收窄到它需要看的改动上，不阻塞当前工作的老 bug 单独分配处理。 如果这样能省下时间、又不增加修复工作量，我会考虑对符合条件的改动减少人工审批。但当 PR 需要再来一轮时，我想知道这一轮要解决什么、解决不了时谁来接手。