我们此前提到，Claude 编写了 Claude Code 约 90% 的代码。那么，面对如此庞大的代码产出量，我们如何进行代码审查？还有人阅读代码吗？如果出现故障，谁来发现？本文介绍 Claude Code 团队的代码审查流程及其演变过程。从 6 月到 9 月，Claude Code 代码库中合并的拉取请求增长了一倍多，而需要回滚的比例下降了超过 40%。我们并没有取消审查。但我们将大部分阅读工作转交给了机器，并以人类的时间和注意力为优化目标，同时大力投入于让错误的撤销变得快速而简便。
当代理编写代码时，变更数量会迅速增加。在 Anthropic 的单体仓库中，每日合并的变更从今年 5 月的约 2,500 次增长到 9 月的 30,000 多次。Claude Code 位于独立于单体仓库的自有代码库中，但它同样承受着巨大压力。当你以如此快的速度交付时，逐行的人工代码审查极其困难，甚至不可能完成。代码审查承担两项工作：在问题发布前发现并修复；在团队内建立共享的上下文和对代码库的理解。本文主要关注发现和修复问题，但我们会在结尾回到第二项工作。
我们认为，“是否有人读过代码？”这一问题并不能准确代表“这项变更可能出现什么问题，以及哪种检查（自动化或人工）最适合发现它？”提出这一问题也改变了审查发生的时机。过去，审查是路径末端的一道关卡：编写代码、提交 PR、等待同事审阅。现在，审查持续进行，更像是你在写作时的拼写检查。在请人类查看之前，大多数变更已由 Claude 至少审查并修复过一次。这能发现大多数常规错误，并让团队的注意力用于更高层次的问题和审查。
稀缺资源：人类的时间和注意力。我们希望将人类的时间和注意力保留给只有人类才能解决的问题，并确保自动化检查能够覆盖其余部分。按照我们当前的变更速度，人类仍有大量工作要做，而我们的团队几乎每天都会遇到新的、前所未有的挑战。人类时间涵盖审查成本的两个方面：人们审查所花费的时间，以及他们修复糟糕代码所造成问题的时间。如果前者减少了，而时间只是转移到后者，那就没有帮助。因此，目标是让 Claude Code 代码库（包括 CLI、桌面和网页应用以及移动应用）中的大多数拉取请求最多只需一位人类参与（可以是作者本人）即可合并，同时不增加回滚或事故的数量。为了衡量人类时间，我们跟踪每个 PR 的人工批准次数（中位数和第 95 百分位数）、人工评论，以及 PR 等待人工处理的时长。回滚率和事故率是保障指标：如果它们上升，那说明我们并没有节省人类时间，只是把时间转移了。
一项变更的生命周期。一项典型的变更从工程师的笔记本电脑（或 Slack 中的 Claude 会话）开始，要经历多层代码审查。从作者的机器到用户手中，大部分路径是自动化的；人的注意力则集中在风险所在之处。分层设防，而非单一关卡：六层检查，并以回滚作为最后保障。每一层都能拦截一些问题，也会漏掉另一些。很少有问题能穿透所有层级，剩下的由回滚处理。1. 在他人查看之前，工作已经过验证。现在，大部分审查发生在拉取请求存在之前。我们给 Claude 提供可运行的东西，例如测试、构建或与设计稿对比的截图，并要求它展示输出结果，而不是仅仅声称已完成。随后，一个子代理以全新的上下文审查差异。这两种习惯都源自我们的最佳实践指南。在提交 PR 之前，我们中的许多人还会运行一些内部技能：一个用于查找漏洞，一个用于简化差异，一个用于端到端检查行为。界面变更还需对照我们的设计指南进行检查。
来源: Hacker News · 由HeadlinesBriefing整理摘要