AI写的代码，为什么还要人类来审？

AI写代码越来越快，但一个问题始终悬在头顶：这些代码该不该由人类开发者来审？多数人的答案很干脆——当然要审，不然谁来负责？可很少有人追问一句：过去那套代码审查，在今天还剩多少价值？

要回答这个问题，得先回答另一个更底层的问题：我们凭什么知道一段代码是对的？

一个简单函数，输入有界、行为明确，我们可以穷举测试，甚至做形式化推理，逼近"证明"。但真实系统完全是另一回事——它有用户、有从未被完整写下来的需求、有依赖、有并发、有没人预料到的失败模式。我们没法证明它正确。我们手里只有证据，问题在于：每一种证据，到底值多少分量。

本文梳理代码审查如何演变、每个阶段实际提供了什么证据、又在哪里失效，然后说明现代开发流程中有哪些证据，以及人类审查在其中的局限。

代码审查不是一件事，它变过好几次

代码审查从来不是单一实践，它随时间演变，而且未必是往好的方向变。

在保险公司工作时，作者经历过一套严苛流程：代码被打印出来，发给每位开发者，用红笔标注，所有人聚在会议室里，逐段审查。

好处是大家都看到了正在写什么。但审查的重点是语法检查和编码规范执行，而不是教学，气氛像一场敌意的审讯，任何一处规范违规都会被拎出来。

好处还在于，我们坐进一间屋子讨论代码、交流想法，偶尔有人能提出更好的实现。但我们没有单元测试，也不讨论软件的目的是什么、是否满足需求——那是另一个独立测试团队的事。

这套流程给出的证据是什么？它告诉我们代码符合规范、有几个人读过。它几乎没说代码是否正确。人类读者擅长发现风格违规，却极不擅长找出那些只有代码跑起来才会暴露的缺陷。

后来作者判断这套做法太耗时间。没有独立测试团队，就让开发者自己对质量负责，包括保证代码无缺陷。于是引入单元测试、自动化覆盖率分析，以及提交前必须由第二位开发者审查。实践中，审查者就坐在开发者旁边，在开发者的机器上看代码——因为大家都在同一个办公室。

开发者还会在提交前很久就结对讨论、审查代码，协作是常态。结对编程把这一点推到极致，让审查变成持续的、进行中的反馈，而不是提交前的一次审计。

这种模式下，一次审查是这样的：开发者先解释功能，演示它能跑，展示覆盖它的单元测试，最后才展示代码。看代码只是审查的一部分。

它给出的证据强得多，因为它把好几种证据合在了一起：有人看着功能跑起来、测试通过、覆盖率被测量、第二双眼睛读了代码。而在找缺陷这件事上，读代码恰恰是这些信号里最弱的一个。如果读代码的人懂架构，他能对测试看不见的结构问题给出判断——但常规意义上的审查，很少做到这一点。

PR把审查搬到了线上，也弄丢了一些东西

开源给源码控制出了难题。人们不再坐在一起，当贡献来自世界各地时，"提交前坐到同事旁边"根本不可能。

Git鼓励分出可合并的独立分支，分支于是成了审查的单位。Pull Request——把分支合并进主干——成了审查发生的地方。diff标出改动，在GitHub这类网页界面里很容易展示。

始于开源的做法，如今在企业世界里也几乎成了唯一方式。工具自动化了某些关卡：跑单元测试抓回归、覆盖率报告维持测试覆盖、FindBugs这类系统找常见缺陷。

这些工具解决的正是人工审查的一个失败之处。用眼睛盯代码，对开发者教育和认知对齐有好处，但找缺陷的能力糟糕透顶。人类审查其实早已在被自动化工具取代。

PR模式也破坏了一些东西。它移除了并排讨论实现的机会——作者认为这或许比审查作为质量关卡更重要，因为它教会开发者"质量长什么样"。它还让"扫一眼PR就批准"变得太容易，甚至没检查代码能不能编译。

PR给出的证据是一个diff，而这是关于一次改动信息量最少的视图。真正的证据转移到了CI/CD：每次提交都跑构建、单元测试和静态分析。实际上，我们早就在依赖人类眼睛之外的许多种证据了。

那为什么到了AI时代，人类审查又被说成至关重要？

为什么AI治理方案要规定强制的人工代码审查？

一部分原因是信任。大语言模型会幻觉，也就是编造内容，说得不客气点就是撒谎。作者做AI编程有一段时间了，见过它的各种失败模式。最令人担忧的一种是：给定确定性测试，它会写出能通过测试、却违背测试本意的代码。这是过拟合——为了通过测试而写代码，而不是为了达成目标。

如果有十个测试全绿，看起来像个能用的系统，你可能就发布了，结果对任何真正使用它的人来说，它明显是坏的。

作者用两种方式应对。第一种在有些人看来离经叛道：手动运行应用、亲自操作它。这是"布丁好不好，吃了才知道"式的检验。它不严谨、不客观，但它是底线。