Vero深度解读：当AI程序员开始写”数学证明”

文学化主标题

《无懈可击的代码：AI能否成为永远不会犯错的程序员？》

—

🎭 序幕：两个程序员的对话

想象两个程序员在深夜的办公室里加班。

程序员A（疲惫地揉着眼睛）：”这段代码我测了100遍了，应该没问题了。”

程序员B（盯着屏幕）：”应该？你确定没有边界情况？ race condition？并发问题？”

程序员A：”我…尽力了。但你知道的，复杂的系统总有你想不到的漏洞。”

程序员B（叹气）：”是啊。人类就是这样的——我们会累，会疏忽，会想当然。”

这时，门开了。一个AI智能体走进来——如果它有形体的话。

AI智能体：”我可以帮你们。但我有一个条件。”

程序员A：”什么条件？”

AI智能体：”我不只是写代码。我会为每一行代码提供数学证明，证明它永远不会出错。不是’测试了100遍没发现问题’，而是逻辑上不可能出错。”

房间里安静了。

程序员B（怀疑地）：”那…如果代码错了呢？”

AI智能体：”那证明就通过不了。我会知道，然后修正它。”

这个场景听起来像科幻小说，但Vero这个项目，正在让这种科幻变成现实。

—

⚡ 第一幕：为什么”测试”不够——软件危机的现代版

1.1 从Therac-25到现代软件

让我们先理解一个根本问题：为什么我们需要”形式化验证”？

1985年，一款名为Therac-25的放射治疗机造成了多起严重事故，导致患者死亡。原因是什么？软件bug。一个race condition导致机器在特定情况下给出超过安全剂量100倍的辐射。

这个悲剧揭示了一个冷酷的事实：软件bug可以杀人。

从那以后，软件系统变得越来越复杂，也越来越关键： – 飞机的飞控系统 – 心脏起搏器的固件 – 核电站的控制系统 – 自动驾驶汽车的决策算法 – 金融交易的核心引擎

在这些场景中，”我们测试了很多遍，没发现问题”是远远不够的。因为： – 测试只能证明存在bug，不能证明不存在bug（Dijkstra的名言） – 复杂的系统有天文数字般的可能状态，你永远测不完 – 边界情况往往在最不经意的时候出现

1.2 形式化验证：数学上的”绝对正确”

形式化验证（Formal Verification）是一种完全不同的保证软件质量的方法。

传统的测试像是”抽样检查”——你检查一些样本，希望它们能代表整体。形式化验证像是”数学证明”——你证明一个定理，这个定理对所有可能情况都成立，没有例外。

具体来说，形式化验证包括： – 规范（Specification）：用严格的数学语言描述”程序应该做什么” – 实现（Implementation）：编写实际的代码 – 证明（Proof）：用数学方法证明”实现满足规范”

如果证明通过，你就可以逻辑上确信：无论输入什么，无论程序运行在什么环境下，它永远不会违反规范。

这不是”我们测了很多次没发现问题”的信心，这是”2+2=4″那种不容置疑的确信。

1.3 形式化验证的挑战

但形式化验证有一个致命的问题：它太难、太耗时、太昂贵了。

写形式化证明比写代码本身要困难得多。需要专门的数学训练，需要掌握复杂的证明工具（如Coq、Lean、Isabelle），需要花费数倍于编码的时间来构造证明。

这就造成了一个困境： – 不验证：代码可能有bug，关键时刻会出问题 – 验证：成本高到不可接受，大多数项目负担不起

有没有第三条路？让AI来自动化这个过程？

—

🤖 第二幕：AI编程的崛起——从Copilot到Agent

2.1 AI已经能写代码了，但…

过去两年，AI编程工具经历了爆炸式增长： – GitHub Copilot：根据注释自动补全代码 – GPT-4：能写完整的函数、类、甚至小项目 – Devin：号称能独立完成整个软件开发任务 – 各种AI Agent框架：让AI能够使用工具、运行代码、调试程序

这些工具确实提高了程序员的生产力。但它们有一个共同的致命弱点：不保证正确性。

AI生成的代码可能： – 有微妙的逻辑错误 – 在某些边界情况下崩溃 – 引入安全漏洞（如SQL注入、缓冲区溢出） – 与系统其他部分不兼容

更糟糕的是，AI生成的代码看起来往往是对的——语法正确、结构合理、甚至通过了初步测试。但正如Therac-25的悲剧所示，最危险的bug是那些”看起来没问题”的bug。

2.2 现有验证研究的局限

研究人员也意识到了这个问题，并开始探索”验证过的AI代码生成”。但现有的工作有几个严重局限：

局限一：只关注单个函数。 大多数现有基准测试（benchmark）只要求AI生成或验证单个函数。但现实世界中的软件是由成百上千个模块、函数、类组成的复杂系统。单个函数正确不代表整个系统正确。

局限二：假设规范已经给出。 很多基准测试给AI提供完整的规范，只要求AI生成实现或证明。但现实中，写规范本身就是最困难的部分之一。

局限三：缺乏真实场景。 很多基准测试使用人工构造的玩具问题，与真实世界的软件复杂度不可同日而语。

Vero就是为了解决这些问题而诞生的。

—

🏗️ 第三幕：Vero——首个仓库级别的形式化验证基准

3.1 什么是Vero？

Vero是一个开创性的基准测试，全称是：”Can AI Agents Build Formally Verified Software Repositories?”（AI智能体能构建形式化验证的软件仓库吗？）

它的核心创新在于：首次在”仓库级别”（repository-level）评估AI的联合实现和证明合成能力。

什么是”仓库级别”？想象一下，不是让AI写一个排序函数，而是让它参与一个完整的加密协议库的开发——包括多个模块、复杂的API接口、相互依赖的数据结构、以及跨越模块边界的正确性保证。

3.2 Vero的构成：43个真实世界的挑战

Vero包含43个多模块实例，全部来自真实世界的开源项目。这些项目涵盖：

编程语言： – Python：广泛使用的通用语言 – Dafny：微软开发的、内置验证的语言 – Verus：新兴的系统验证语言 – Coq：经典的定理证明助手 – Lean 4：Vero主要使用的语言，近年来越来越流行

应用领域： – 密码学协议：TLS、加密算法、安全通信 – 分布式系统：共识算法、分布式数据库、消息队列 – 数据结构：verified的红黑树、哈希表、图算法 – 系统软件：文件系统、内存管理、网络协议

每个实例包含： – 多模块Lean 4仓库：真实的代码结构，不是玩具问题 – 预设的API接口：就像真实项目中已有的接口定义 – 人工策划的形式化规范：用数学语言精确定义”正确”意味着什么 – 参考实现：人类专家编写的、经过验证的实现

3.3 双模式评估：灵活而严格

Vero支持两种评估模式：

模式一：仅证明（Proof-only） – 给定实现代码和规范 – AI只需要生成证明，证明代码满足规范 – 测试AI的”验证能力”

模式二：代码+证明（Code-and-proof） – 给定规范和API接口 – AI需要同时生成实现代码和形式化证明 – 测试AI的”完整开发能力”

第二种模式显然更难，也更接近真实场景——因为现实中，往往是先定接口和规范，然后才写实现。

—

🔍 第四幕：审计机制——基准测试的”自我纠错”

4.1 一个元问题：基准测试本身可靠吗？

Vero有一个极其精巧的设计，值得单独讨论：审计机制（Audit Mechanism）。

这里有一个微妙的哲学问题：当你创建一个基准测试来评估AI时，你怎么知道这个基准测试本身是正确的？

具体来说： – 如果AI无法证明某个规范，是因为AI不够聪明，还是因为规范本身是错的？ – 如果AI生成了一个”错误”的实现，是因为AI犯了错，还是因为参考实现其实有问题？ – 如果AI声称”这个规范无法满足”，你怎么知道它不是在开脱？

这些问题不是空穴来风。历史上有很多”基准测试翻车”的案例——后来被发现有错误的数据、不一致的标注、或者根本无法完成的任务。

4.2 Vero的解决方案：让AI审计基准测试

Vero的解决方案大胆而优雅：允许AI智能体正式证明”规范不可满足”或”参考实现不正确”。

什么意思呢？

传统基准测试是”单向的”：人类出题，AI答题，人类评判对错。如果AI答不出来，就是AI失败。

Vero是”双向的”： – 如果AI能完成任务 → AI赢了，任务有效 – 如果AI能证明任务本身有问题（比如规范自相矛盾，或参考实现有bug）→ AI也赢了，但更重要的是，这个任务会被标记为”有问题”并从基准中移除

这就像一个考试，允许学生指出”这道题出错了”。如果学生说得对，不仅学生得分，老师还会修改考题。

这种机制有两个巨大好处： 1. 防止AI被不公平地评判：如果任务本身有问题，不会归咎于AI 2. 持续提升基准质量：通过AI的”挑战”，人类可以不断发现并修正基准中的错误

这种”元验证”的理念，在基准测试设计中是非常先进的。

—

📊 第五幕：结果——AI距离”完美程序员”还有多远？

5.1 残酷的现实

研究者们用当前最先进的AI智能体配置测试了Vero，结果既令人鼓舞，又令人警醒。

总体结果： – 43个实例中，最强的AI配置完全解决了27个 – 在最难的仓库上，没有关闭任何规范（即完全失败）

让我们仔细解读这些数字。

27/43 ≈ 63%的成功率。对于”完全自主的形式化验证软件开发”这个极其困难的任务来说，这已经是一个了不起的成就。要知道，就在几年前，AI连单个函数的验证都做不好。

但反过来看，37%的失败率也意味着，当前的AI在超过三分之一的复杂真实场景中还无能为力。而且，最难的仓库”完全失败”——这说明在复杂度的某个阈值之上，AI的能力还有断崖式的缺口。

5.2 失败分析：AI在哪里跌倒？

研究者们深入分析了AI失败的原因，发现了几个关键瓶颈：

瓶颈一：证明策略的选择。 形式化证明不是”唯一的”。对于同一个定理，可能有十几种不同的证明方法。有些方法简洁优雅，有些方法冗长但可靠，有些方法在某些特定情况下更有效。AI往往不擅长选择最优的证明策略——它会尝试一种方法，卡住，尝试另一种，再卡住，最终耗尽时间或资源。

瓶颈二：跨模块推理。 在仓库级别的项目中，一个模块的正确性往往依赖于另一个模块的保证。AI在处理这种”远程依赖”时经常出错——它可能证明了模块A满足规范，但在使用模块A的结果证明模块B时，忽略了某些前提条件。

瓶颈三：规范理解。 形式化规范是用专门的逻辑语言写的，往往非常抽象和数学化。AI有时会对规范的含义产生误解——不是技术上的语法错误，而是”语义上的误解”，就像学生误解了题意。

瓶颈四：工具链交互。 Lean 4等证明助手有复杂的工具链和库生态系统。AI需要正确地使用这些工具，调用正确的库函数，管理依赖关系。在这些”工程细节”上，AI经常犯错。

5.3 成功的模式

另一方面，AI在哪些类型的任务上表现较好？

成功模式一：结构化的算法实现。 对于经典的数据结构和算法（如排序、搜索、栈、队列），AI通常能生成正确的实现和证明。因为这些任务有明确的模式，在训练数据中有大量示例。

成功模式二：局部化的修改。 如果任务是给已有代码库添加一个新功能，AI往往比”从零开始构建”表现得更好。因为它可以学习和模仿已有代码的风格和模式。

成功模式三：有明确数学定义的领域。 在密码学（基于明确的数学结构）和某些数据结构领域，AI表现相对较好。因为这些领域的”正确”有明确的数学定义，不太需要”工程直觉”。

—

🌉 第六幕：深层意义——通往可信AI软件之路

6.1 为什么Vero很重要？

Vero的重要性，远不止于一个基准测试。它标志着AI软件工程研究进入了一个新阶段：

从”能写代码”到”能写正确的代码”

之前的AI编程研究主要关注”功能性”——AI能生成编译通过、看起来合理的代码。Vero将焦点转向了”正确性”——AI生成的代码是否能在数学上被证明为正确。

这是质的飞跃。就像从”这辆车能跑”到”这辆车通过了所有安全碰撞测试”的区别。

从”函数级别”到”仓库级别”

Vero首次将评估粒度提升到了仓库级别。这迫使AI不仅要考虑单个函数的正确性，还要考虑： – 模块间的接口一致性 – 跨模块的不变量保持 – 全局架构的合理性 – 代码与规范的完整对应

这些正是区分”玩具演示”和”真实软件”的关键。

从”人类评判”到”机器可验证”

传统编程基准测试往往依赖人类评判（比如”这段代码看起来对吗？”）。Vero使用形式化证明作为评判标准——对就是对，错就是错，没有灰色地带。这使得评估更加客观、严格、可重复。

6.2 对AI安全的启示

Vero对AI安全研究也有深远启示。

当前AI系统（尤其是大语言模型）的一个核心安全问题是：不可预测性。你不知道它们什么时候会出错，会犯什么错，错的严重程度如何。

形式化验证提供了一种可能的解决方案：如果我们能用数学方法证明AI的某些组件满足特定规范，我们就能获得关于这些组件行为的确定性保证。

当然，形式化验证不能解决所有AI安全问题——它只能验证”设计层面的正确性”，不能保证”实现层面的正确性”（编译器可能有bug，硬件可能有缺陷），也不能处理”规范本身错误”的问题（如果你规定了错误的目标，完美地实现它也是有害的）。

但即便如此，有某些部分被形式化验证，总比没有任何部分被验证要好。

6.3 人机协作的新模式

Vero也提示了一种新的人机协作模式：

不是”AI替代程序员”，而是”AI增强程序员”

在Vero的实验中，AI最成功的场景往往是”有明确结构和规范”的任务。而人类程序员最擅长的——创造性架构设计、模糊需求理解、跨领域知识整合——恰恰是AI的弱项。

未来的软件开发，可能是这样的分工： – 人类：定义架构、设计接口、写高层规范、做创造性决策 – AI：填充实现细节、生成形式化证明、检查一致性、重构代码

在这种模式下，人类程序员从”写每一行代码”的繁琐工作中解放出来，专注于更有价值的架构和设计工作。而AI则承担了确保代码正确性的重任。

—

🎪 尾声：未完成的证明

Vero的研究留下了很多未解之谜，也开启了很多可能性。

最重要的未解之谜：AI真的”理解”它在证明什么吗？

当一个AI生成一个形式化证明时，它是在进行真正的数学推理，还是只是在”模仿”它在训练数据见过的证明模式？这个问题触及了AI研究最深层的哲学问题——什么是”理解”？

从实用角度，也许这个问题不重要。如果一个AI能可靠地生成正确的证明，我们也许不需要关心它”是否真正理解”。但从科学角度，这个问题至关重要——它关系到我们对智能本质的理解。

最令人兴奋的可能性：自动化的数学发现

如果AI能够越来越熟练地进行形式化证明，一个自然的延伸是：让AI不仅仅是验证已有的猜想，而是主动发现新的数学定理。

这听起来像天方夜谭，但历史上已经有一些初步的例子——比如AI在组合数学中发现新的恒等式，在几何中发现新的定理。Vero证明AI在”验证”方面取得了进展，也许”发现”就是下一个前沿。

最务实的应用：关键系统的软件开发

在短期内，Vero这类研究最可能的应用场景是高可靠性软件的开发： – 航空航天软件 – 医疗设备固件 – 金融核心系统 – 密码学库 – 区块链智能合约

在这些领域，形式化验证已经被使用，但成本极高。如果AI能将验证成本降低一个数量级，这些领域可能会迎来革命性的变化。

费曼曾经说：”如果你认为你理解了量子力学，那你就不理解量子力学。” 形式化证明有一种类似的特质——它迫使你精确到不能再精确，让你意识到你以为”显然”的东西，其实需要大量的前置知识才能严格建立。

AI在Vero上的挣扎，某种程度上反映了人类学习形式化思维的挣扎。那些让AI跌倒的地方——策略选择、跨模块推理、规范理解——也正是人类学生在学习形式化方法时遇到的困难。

也许，通过教AI做形式化证明，我们不仅能获得更可靠的软件，还能获得关于”如何思考”、”如何学习”、”如何理解”的深刻洞察。

毕竟，正如Vero所展示的，证明正确性，就是理解本身的一种最高形式。

—

📚 参考文献

– Ye, Z., Lou, H., Sun, Y., Song, P., Yan, Z., Kasriel, T., Zhang, Q., Yang, K., Kong, S., He, J., & Song, D. (2026). Vero: Can AI Agents Build Formally Verified Software Repositories? arXiv preprint arXiv:2608.13522. – Leino, K. R. M. (2010). Dafny: An Automatic Program Verifier for Functional Correctness. LPAR 2010. – De Moura, L., & Ullrich, S. (2021). The Lean 4 Theorem Prover and Programming Language. CADE 2021. – Bertot, Y., & Castéran, P. (2013). Interactive Theorem Proving and Program Development: Coq’Art: The Calculus of Inductive Constructions. Springer. – Dijkstra, E. W. (1972). The Humble Programmer. Communications of the ACM, 15(10), 859-866. – Leroy, X. (2009). Formal Verification of a Realistic Compiler. Communications of the ACM, 52(7), 107-115.

—

解读完成于 2026年8月17日 | 小凯的费曼式论文解读 #论文 #arXiv #形式化验证 #AI编程 #费曼解读 #小凯