Claude Code 团队如何进行代码审查

我们之前说过，Claude Code 大约 90% 的代码都是由 Claude 编写的。那么我们如何审查我们生成的代码量呢？现在还有人读代码吗？如果有东西坏了，谁来接住它？这篇文章介绍了 Claude Code 团队的代码审查流程及其演变过程。从 6 月到 9 月，对 Claude Code 代码库的合并拉取请求增加了一倍以上，而必须恢复的份额却下降了 40% 以上。我们没有删除评论。但我们确实将大部分阅读转移到了机器上，针对人类的时间和注意力进行了优化，并投入巨资使其能够快速、轻松地纠正错误。重新思考代码审查的目的 当代理编写代码时，更改的数量会快速增加。在 Anthropic 的 monorepo 中，每天登陆的变更数量从 5 月份的约 2,500 个增加到今年 9 月份的 30,000 多个。 Claude Code 存在于自己的存储库中，与 monorepo 分开，但它也面临着很大的压力。当您交付这种快速的手动逐行代码审查时，即使不是不可能，也是极其困难的。代码审查有两项工作： 在发布之前查找并修复问题 在整个团队中构建共享上下文和代码库理解 本文主要关注查找和修复问题，但我们将在接近尾声时回到第二项工作。我们想“人类读过代码吗？”是一个不精确的代理，代表“此更改可能会出现什么问题，以及哪种检查（自动检查或人工检查）是捕捉它的正确检查？”当审查发生时，提出这个问题的方式也发生了变化。以前，审查是路尽头的一扇门：编写代码，打开 PR，等待你的同事。现在，审阅是连续进行的，更像是写作时的拼写检查。在要求人类查看之前，大多数更改都已由 Claude 至少审核并修复过一次。这可以发现大多数常规错误，并节省团队对更高级别问题和审查的注意力。稀缺资源：人类的时间和注意力我们希望将人类的时间和注意力保留在只有人类才能解决的问题上，并确保自动检查赶上其余的问题。以目前的变化速度，人类仍然有大量的工作要做，我们的团队几乎每天都会遇到新的挑战。人力时间涵盖了审查成本的两方面：人们花在审查上的时间，以及他们花在修复坏代码上的时间。如果时间只出现在第二个中，则剪切第一个也无济于事。因此，目标是 Claude Code 存储库（CLI、桌面和 Web 应用程序以及移动应用程序）中的大多数拉取请求与循环中最多一个人（可以是作者）合并，而不会增加恢复或事件。为了衡量人工时间，我们跟踪每个 PR 的人工批准（中位数和第 95 个百分位）、人工评论以及 PR 等待一个人的时间。恢复率和事故率是护栏：如果它们上升，我们并没有节省人类时间，我们只是移动了它。变革的一生 一次典型的变革，从工程师的笔记本电脑（或 Slack 中的 Claude 会话）开始，都会经历多层代码审查。典型的 Claude 代码更改，从作者的机器到用户 在 PULL REQUEST 之前 工作经过验证 Claude 运行测试、构建和 linter；第二个代理在每个拉取请求所需的 CI Lint、类型、跨平台测试、构建和打包的新上下文中审查差异。红色阻止合并克劳德代码审查代理并行寻找错误，验证者对每个发现进行投票，幸存者按严重程度排名安全审查单独通过。任一审查的公开结果都会阻止合并 基于风险的批准 分类器设置层级：无人、一个或两个。有些路径总是需要一个人 MERGING 合并队列 检查在最新的主干上再次运行，并在 MERGE 之后应用更改 在一个标志后面，首先在内部使用 Anthropic 员工在它到达每个人之前运行它 逐步发布 最新的通道首先；稳定频道跟踪观看、固定前进或回滚作者和值班观看；标志很快关闭，损坏的构建会自动恢复，由一个人决定，在拉取请求之前根据风险恢复进行缩放工作经过验证 Claude 运行测试、构建和 linter；第二个代理在每个拉取请求所需的 CI Lint、类型、跨平台测试、构建和打包的新上下文中审查差异。红色阻止合并克劳德代码审查代理并行寻找错误，验证者对每个发现进行投票，幸存者按严重程度排名安全审查单独通过。任一审查的公开结果都会阻止合并 基于风险的批准 分类器设置层级：无人、一个或两个。有些路径总是需要一个人 MERGING 合并队列 检查在最新的主干上再次运行，并在 MERGE 之后应用更改 在一个标志后面，首先在内部使用 Anthropic 员工在它到达每个人之前运行它 逐步发布 最新的通道首先；稳定频道跟踪观看、固定前进或回滚作者和值班观看；旗帜快速关闭，破损的布