AI 写了 95% 的代码，谁来验证它？

微软 CTO 预测 2030 年 95% 的代码将由 AI 生成。Google 和微软都报告新代码中 25-30% 已经是 AI 写的。AWS 用 AI 帮丰田迁移了 4000 万行 COBOL 代码。Anthropic 用并行 AI Agent 在两周内造了一个 10 万行的 C 编译器，花费不到 2 万美元——这个编译器能启动 Linux，能编译 PostgreSQL 和 Redis。

AI 写代码的能力已经毋庸置疑。但一个更尖锐的问题浮出水面：谁来验证这些代码是对的？

“Accept All” 的危险

Lean 定理证明器的创造者 Leo de Moura 最近写了一篇文章，直指这个行业盲区。他引用了 Andrej Karpathy 的坦白：”我现在都是直接 Accept All，不再看 diff 了。”

这不是个例。当 AI 生成的代码”大多数时候能用”，人类就会停止仔细审查。这是一个心理学问题，也是一个工程问题——自动化悖论：工具越可靠，人类越不警觉；而当工具出错时，不警觉的人类恰恰是最糟糕的后备方案。

数据也印证了这个担忧：近一半的 AI 生成代码无法通过基础安全测试，而且更大、更新的模型在安全性上并没有显著提升。错误一直在那里，审查的人却越来越少。

形式化验证：被忽视的答案

De Moura 的观点很明确：形式化验证是 AI 时代代码质量的终极保障。

传统的代码审查依赖人类，而人类已经在 “Accept All” 了。单元测试覆盖的是已知场景，无法穷举所有边界情况。只有形式化证明——用数学方法证明程序满足其规格说明——能提供真正的保证。

有趣的是，AI 本身可能成为形式化验证的加速器。就像 AI 加速代码编写一样，它也可以加速证明的构造。Lean 4 等现代证明助手已经在探索用 LLM 辅助生成证明的路径。这形成了一个闭环：AI 写代码，AI 帮忙证明代码是对的，而证明本身由数学保证——不需要信任 AI，只需要信任逻辑。

但现实没那么美好

形式化验证的理想很丰满，现实很骨感。

首先，写规格说明本身就很难。你要先精确定义”正确”是什么意思，这往往比写代码更难。对于大多数业务逻辑，形式化规格说明的成本远高于收益。

其次，覆盖率有限。目前形式化验证主要适用于编译器、密码学库、操作系统内核等关键基础设施。让每个 CRUD 应用都写形式化证明，既不现实也没必要。

第三，人才缺口巨大。能同时理解软件工程和形式化方法的人本来就少，指望这个群体突然扩大也不现实。

务实的分层策略

我认为更现实的路径是分层验证：

• 关键基础设施（编译器、加密库、操作系统内核）：形式化验证，零妥协
• 核心业务逻辑（支付、权限、数据一致性）：属性测试 + 模型检查 + 强类型系统
• 一般应用代码：AI 生成 + AI 审查 + 传统测试，接受一定的错误率

这个分层策略的关键洞察是：不是所有代码都值得同等程度的验证。Karpathy 自己也承认，对于”真正在乎的代码”，他会切换到更谨慎的工作流。问题在于，大多数团队没有明确定义哪些代码是”真正在乎的”。

Vibe Coding 的真正风险

“Vibe Coding”这个概念很有趣——凭感觉写代码，让 AI 处理细节。对于原型和个人项目，这完全没问题。但当 vibe coding 渗透到生产系统时，我们实际上是在用概率替代确定性。

AI 生成的代码最大的风险不是它会写出明显错误的代码——那种错误容易发现。真正的风险是那些看起来对、跑起来也对、但在特定边界条件下会出问题的代码。这类缺陷可能潜伏数月甚至数年，直到某天在生产环境中爆发。

写在最后

AI 改变了代码的生产方式，但没有改变验证的基本需求。恰恰相反，当代码产出速度提升 10 倍，验证的重要性也提升了 10 倍。

De Moura 的呼吁值得认真对待：在我们全速拥抱 AI 编程的同时，也要认真投资验证工具链。不一定是每行代码都形式化证明，但至少要有清醒的分层策略，知道什么该严格验证、什么可以接受 AI 的”大概率正确”。

如果你在日常开发中会用到多个 AI 模型来辅助编程和审查代码，推荐试试 OfoxAI（ofox.ai）——一个账号接入 Claude、GPT、Gemini 等主流模型，不同模型交叉审查也是提高代码质量的一种思路。