Maybe We Shouldn't Be Reviewing All This Code

也许我们不应该审查所有这些代码

Rachel Laycock

我是 Thoughtworks 的首席技术官 Rachel Laycock。我对技术如何改变我们构建软件、领导团队和运营企业的方式充满无尽的好奇。在这里，我会记录那些尚未成熟的想法，挑战自己的思考，并偶尔偏离到有趣的支线。

2026年9月2日

TL;DR 或者，也许问题不在于 AI 破坏了代码审查，而是我们一直用代码审查来解决错误的问题。

我最近与 Code Remix 的 DX 部门的 Brian Houck 一起参加了一个由 Moderne 主办的小组讨论。这是一次非常有趣的讨论，主要是因为我们意见不同。正如我的同事 Martin Fowler 所说，当人们意见相左且双方都有充分论据时，小组讨论会更加有趣。Brian 和我确实如此。

Brian 随后撰写了一篇题为《代码审查究竟有什么用？》的深入文章。他显然对他的立场充满热情，而我对自己的立场也足够热情，以至于写了这篇回应。明确地说，我认为我们大多数时候想要的是相同的东西。我只是认为代码审查并不是实现这些目标的最佳方式。顺便说一句，Brian 非常友善，他鼓励我写下这篇文章。但如果说我不希望你最终认为我是对的，那我就是在撒谎 :)

那么，我们到底在争论什么？

AI 生成的代码量已经超过了人类能够实际审查的数量。Brian 引用了一些令人震惊的数据：据报道，Meta 的人均提交代码量在一年内增长了 106%，而 DX 自己的数据则显示，拉取请求的中位数大小增加了 64%。

他的担忧（我也同样担忧）是，仅仅通过自动化消除代码审查，可能会让我们失去代码审查的其他所有价值。代码审查不仅仅是查找错误。它是团队分享知识、培养初级工程师、建立集体所有权和传播架构理解的方式。

我的问题是：为什么我们要等到代码审查时才做所有这些事情？

我从未特别喜欢将拉取请求作为软件开发过程的中心。不是因为工程师不应该查看彼此的代码，而是因为我一直难以接受这样的想法：我们应该先构建某样东西，完成它，打包好，再把它扔给其他人，然后才进行关于我们是否以正确的方式构建了正确事物的重要讨论。

更不用说合并冲突了。我浪费了太多生命中的时间在这些上面。

将判断提前

我在 Thoughtworks 早期学到的一个原则是缩短反馈循环。如果反馈有价值，不要移除它。把它移到它所支持的决策更近的地方。

看看我们常说代码审查能带来的东西。

如果我们想要探索替代方案，我宁愿在实现其中一个方案之前就进行。

如果我们想要知识传递，那就结对编程。在某人思考问题时，无论是物理上还是虚拟上坐在他们旁边，比在之后阅读他们完成的解决方案要学到更多。

如果我们希望初级工程师学习资深工程师的思维方式，那就让他们在资深工程师思考时一起工作。再次想到结对编程，但团队也可以在编写（或指导代理编写）任何内容之前，通过白板进行集体设计会议。

如果我们希望实现集体所有制，应通过结对编程、群体编程或团队设计白板会议等方式组织团队，让成员真正共同构建和运营软件，而不是依赖拉取请求来告知他人已有的工作成果。

如果我们希望实现架构一致性，应通过协作设计（我不必再重复关于结对编程和团队设计会议的内容，哦等等……）来共同制定架构，并将关键约束条件编码为适应性函数。

如果我们正在审查代码的格式、代码规范、已知安全问题或可确定性测试的内容，应将其自动化。我们真的不应该在2026年还在为代码缩进问题争论不休。

结对编程、主干开发、自动化测试、静态分析、适应性函数和安全扫描都能将反馈提前。越来越多的智能体也可以参与这些流程，挑战设计、测试假设并持续验证正在构建的内容，但真正的思考仍然来自经验丰富的开发者。如果我们希望这些经验能惠及整个团队，就必须在代码审查之前更早地将团队视为一个整体。

异常审查机制

以上内容并不意味着不需要代码审查。确实存在一些变更需要其他经验丰富的开发者参与审查。例如，涉及基础架构变更的场景。假设我们已经通过团队设计会议进行了整体规划，可能需要团队共同审查代码、确认实现正确性，或讨论是否需要调整任何内容。其他可能需要审查的场景包括跨越敏感安全边界、具有巨大影响范围、涉及关键系统中不熟悉的部分，或者团队明确表示"我对这部分没有信心"的变更。

这些正是人类判断具有价值的场景，但这与要求人类审查每个变更完全不同，因为后者只是我们历史上建立信心的一种仪式。

我们现在已经知道，继续沿这条道路走下去并不可行，这也是为什么代码审查持续成为问题或阻碍的原因。如果智能体能生成十倍于人类的代码，但每行代码最终都需要等待资深工程师审查，我们并没有创建一个十倍效率的工程团队，而是制造了一个巨大的待办事项列表和新的瓶颈。

我不认为答案是让AI代理假装成人类审查者，以更高效率维持完全相同的流程。这实际上是自动化仪式本身，而不是质疑仪式存在的原因。

不过，我在Brian的论点中有一点担忧。他提到团队积累认知债务和意图债务：软件在不断发展，而负责它的开发者对系统运作原理的理解却越来越少。我认为这是一个非常现实的问题，但我并不认为强制性的拉取请求是解决这个问题的有力手段。

如果智能体要生成大量实现代码，我们必须更加有意识地通过协作设计、结对编程、良好边界、可执行架构、共享运维责任以及一些尚未发明的实践来保持人类对系统的理解。

我们需要工程师理解系统本身，而不是代码差异。

也许这就是AI所揭示的。我们花了多年时间，将大量责任压在代码审查上：质量门禁、安全检查、架构评审、导师机制、知识共享系统、所有权模型。

在人类只能以一定速度编写代码时，这种方式或多或少是可行的。但这种限制正在消失。因此问题或许不是如何加快代码审查速度，而是我们为何要等到代码审查阶段才进行所有重要的讨论。

最新文章（9月2日）：

也许我们不应该审查所有这些代码

上一篇文章：

公民构建，代理执行，专家治理

所有文章 /