我们之前提到过，Claude大约撰写了Claude Code自己的90%的代码。那么我们如何评审我们产生的代码量呢？现在还有人阅读代码吗？如果出现问题，谁来发现呢？这篇文章介绍了Claude Code团队的代码审查流程及其演变。从6月到9月，合并到Claude Code代码库的拉取请求数量超过翻倍，而需要撤回的比例下降了40%以上。我们没有取消审查，但我们确实将大部分阅读转移到了机器上，从而优化了人类的时间和注意力，并在快速且轻松地撤销错误方面进行了大量投资。 重新思考代码审查的目的 当代理人写代码时，变更的数量迅速增加。在Anthropic的单一代码库中，每天的更改从5月的约2500次增加到今年9月的3万次以上。Claude Code在其自己的代码库中，独立于主干库，但也面临很大的压力。当你如此快速地交付时，手动逐行代码审查变得极其困难，甚至不可能。代码审查有两个任务：在代码发布前发现和修复问题，建立团队之间的共享上下文和代码库理解。本文主要关注寻找和修复问题，但我们会在最后提到第二项任务。 我们认为“是否有人阅读了代码？”是“一项更改可能出现什么问题，以及哪个检查——自动化或人类——是发现它的正确方式？”的一个不精确代理。问这个问题也改变了审查发生的时间。以前，审查是在路的尽头的一个关口：写代码，打开PR，等待同事。现在，审查是持续进行的，更像是写作时的拼写检查。大多数更改在请求人类查看之前，已经被Claude至少审查并修复过一次。这能捕捉到大多数常规错误，节省团队对更高级别问题的关注和检查。 稀缺资源：人类时间和注意力 我们希望将人类的时间和注意力保留给只有人类能解决的问题，并确保自动检查捕捉其余问题。在我们当前的变化速度下，仍然有大量的工作需要人类完成，我们的团队几乎每天都遇到新的挑战。人类时间涵盖了审查成本的两个方面：人们花在审查上的时间，以及他们花在修复坏代码所引起的问题上的时间。如果第一项减少但第二项时间并未减少，那么就没有帮助。因此，目标是Claude Code库中的大多数拉取请求（CLI、桌面和网页应用、移动应用）在最多一个参与者的情况下合并，该参与者可以是作者，而不增加撤回或事件的数量。为了衡量人类时间，我们跟踪每个PR的人类批准（中位数和95百分位），人类评论，以及PR在人员身上的等待时间。撤回和事件的比率是保护措施：如果它们上升，我们并没有节省人类时间，只是转移了它。 变更的生命周期 一个典型的变更，从工程师的笔记本电脑（或Slack中的Claude会话），经过多个层次的代码审查。变更的生命周期，一个典型的Claude Code变更，从作者的机器到用户。大部分路径是自动化的；人的注意力集中在风险较高的地方。逐层审查，六层检查，下面有回滚。每一层捕获某些问题并遗漏其他问题。很少有变更能够通过所有检查，回滚处理其余问题。 在任何人查看之前，首先验证工作。现在大多数审查在PR存在之前就已完成。我们给Claude一些可以运行的内容——如测试、构建或对比设计的截图——并让它展示输出，而不是说它完成了。然后一个子代理在新鲜的上下文中审查差异。这两种习惯源自我们的最佳实践指南。在打开PR之前，我们中的许多人还会运行一些内部技能：一种寻找错误，一种简化差异，还有一种进行端到端的行为检查。UI更改也会根据我们的设计指南进行检查。创建Claude Code的Boris Cherny表示，让Claude验证其工作的方式可能是获得良好结果的最重要因素。他估计这使最终结果提高了两到三倍，并写道：“验证在每个领域看起来都不同。它可能像运行一个bash命令一样简单，或者运行一个测试套件，或者在浏览器或手机模拟器中测试应用程序。”当自动审查者不断标记同样的内容时，我们会在源头修复它：在技能中，使用lint规则，或更新如CLAUDE.md这样的指导文件，它告诉Claude项目是什么：技术栈、约定、目标和非目标。每次审查时都会加载它，因此在大型代码库中，我们保持简短并从那里指向其他文档。审查者还会标记违反约定的代码以及使其中某一行过期的更改。由代码所有者撰写的REVIEW.md告知审查者他们代码的哪个部分重要。我们单独检查审查者是否采取行动。