Adam Langley 表示 Lean 证明自动化已到来，难题只是转移了

Adam Langley 表示，在多个大型语言模型约 20 分钟内完成一项复杂的软件证明后，Lean 证明自动化已跨过一个实用门槛。这一说法附带重要限定：AI 生成了证明，但 Lean 会根据形式化规格检查其中的每一步。

这一差异使该实验不同于又一个 AI 产出看似合理代码的故事。Langley 用 Lean 构建了一个 Zstandard 解压器，随后让模型证明其熵解码表的普遍性质。据称，模型在没有留下未解决证明空缺的情况下完成了任务，不过也修改了他实现中的部分内容。

这项实验指向了软件团队的另一种分工。开发者或许会减少构建证明的时间，转而更多地决定系统究竟必须保证什么。AI 编程助手会生成答案，并要求人类寻找错误；Lean 则颠倒了这种关系：任何未能满足可由机器检查的陈述的答案，都会被它拒绝。

这并不证明形式化验证已经变得低成本、容易，或适用于每一种应用。Langley 将该解压器描述为一个玩具项目，没有公开其源代码，并测得其速度仅为标准 zstd 命令的十分之一。独立研究也表明，当证明依赖大型、陌生的代码库时，AI 证明器仍会遇到困难。

更稳妥的结论依然意义重大。AI 现在可以承担足够多重复性的证明工作，使得在传统利基领域之外测试验证方法变得值得。对于知识工作者而言，更广泛的启示超越了软件：当验收标准明确且经过独立检查时，自动化会更值得信赖。

一项 Zstandard 实验让 Lean 证明自动化投入实际工作

新闻并不是 AI 又写出了一个程序，而是 AI 生成的成果通过了一个专为拒绝逻辑错误而设计的检查器。

以密码学和互联网基础设施工作闻名的安全工程师 Langley 于 2026 年 7 月 26 日发布了这项实验。他的 proof automation 文章介绍了如何在 Lean 中构建 Zstandard 解压器，并形式化描述其解码表的若干性质。

Lean 既是一门函数式编程语言，也是一个证明助手。证明助手会检查一个形式化论证是否建立了精确表述的命题。Lean 的小型内核会验证最终的证明项，因此用户无需信任生成该证明的模型。

测试聚焦于有限状态熵编码（Finite State Entropy，FSE），Zstandard 使用它来高效编码某些值。FSE 根据符号的概率，将符号分配到状态表中。每个状态会确定一个符号、需要读取的位数，以及用于计算下一个状态的基准值。

正确的表必须保持若干关系。它需要具有预期数量的条目，为每个符号正确分配条目，并为每一个可能的状态提供有效转换。每个非零概率符号还必须恰好拥有一条通往每个目标状态的路径。

单元测试可以检查 Zstandard 规格中的选定示例，但无法证明这些性质对每一个有效输入都成立。因此，Langley 编写了一个覆盖完整表构造函数的定理。

据称，多个 LLM 在约 20 分钟内生成了证明。Langley 确认 Lean 接受了结果，且文件中不含 sorry 声明——Lean 开发者将其用作缺失证明的占位符。

模型并非只是填补一个孤立的空白。它们修改了表生成代码，因为 Langley 使用了过多命令式风格的结构。这种结构更难被证明机制分析。

这一细节很重要，因为它同时揭示了吸引力与成本。AI 承担了证明构建工作，但实现仍需要采用支持推理的形式。验证并不是一个可以套用到任意代码上的最终质量控制按钮。

Langley 也避免将该项目描述为生产级证据。代码仍未公开，解码器覆盖的实验范围有限，其性能也落后于成熟实现。他的主张关乎证明自动化的可用性，而不是这个特定解压器是否已经就绪。

一个相关项目提供了更广泛的参照。Lean 创始人 Leonardo de Moura 强调了一个由 AI 辅助的 zlib implementation，它通过了测试，并证明了所有压缩级别下的往返正确性。这些例子共同让 AI 证明更接近日常系统代码。

它们仍在令人印象深刻的成果与可重复的工程流程之间留下缺口。弥合这一缺口，将决定 Lean 证明自动化会成为常见的开发工具，还是继续停留在专家演示的层面。

过去的障碍是证明工作量，而非证明检查

形式化验证早已提供强保证。它的经济问题在于，人类需要付出大量努力来陈述并维护这些保证。

普通测试会询问软件在已运行的示例中是否行为正确。形式化验证则询问，数学模型是否对模型范围内的每一个输入都满足某项陈述的性质。更大的承诺带来了更大的工作量。

seL4 微内核仍是最清晰的历史案例之一。其验证团队完成了一项机器检查证明，将内核实现与其形式化规格关联起来。该项目表明，高保障、生产规模的软件可以得到验证。

它也记录了成本。根据团队的 project retrospective，验证所需的工作量大约是设计和实现 C 代码所花时间的十倍。证明材料的行数超过实现代码的二十倍。

这些数字并不意味着每个经过验证的项目都会承受同样的比例。seL4 针对一个规模可观的操作系统内核追求了异常广泛的保证。但它们确实解释了为何大多数软件组织转而选择测试、评审、静态分析和运行监控。

传统自动化减轻了其中一部分负担。诸如 SMT 求解器之类的工具会搜索逻辑约束的解，能够完成常规证明义务。当问题符合求解器支持的理论和预期结构时，它们表现良好。

当目标处于这一舒适区之外时，体验就变得不那么可预测。开发者可能会一直等待，却不知道求解器只是需要更多时间，还是永远无法完成。团队还会学习让求解器正常工作的实现模式，从而形成另一门专业工程学科。

LLM 以不同方式处理这项任务。它们可以阅读定义、错误信息、附近的引理和非正式说明；可以提出中间结果、修改失败的策略，并在当前表示方式阻碍进展时重组代码。

这种灵活性使证明生成成为语言模型的自然目标。模型无需被信任为最终权威，它只需产出能被证明内核接受的成果。

这比许多办公自动化任务更契合。生成的战略备忘录没有用于判断真实性、相关性和判断质量的完整检查器；Lean 证明则具有软件可以确定性评估的狭窄验收条件。

结果改变了预期的劳动分工。人类负责指定性质、选择假设，并决定模型是否反映现实。AI 搜索证明，而 Lean 验证提出的结果。

这并未消除人类工作，而是将工作转向规格说明、架构与评审。这些活动更难自动化，因为它们要求决定哪些结果重要。

对知识工作者而言，这才是更深层的生产力故事。最强大的自动化不只是产出更多材料，而是将生成的材料连接到明确的条件上，以决定结果是否可接受。

这一原则同样适用于研究和运营工作。使用 personal knowledge base 的团队，可以在生成答案前检索证据。结果仍需要涵盖来源质量、范围和时效性的标准。

Lean 使这些标准变得格外严格。它带来的启示并不是每一项任务都需要定理证明器，而是当组织能够定义可检查的契约时，自动化会变得更可靠。

AI 改变的是证明成本，而非正确性的含义

Lean 证明自动化可以验证代码是否符合规格，但无法决定该规格是否抓住了正确的问题。

这是 Langley 实验中的核心反转。模型不确定的推理并不会自动削弱证明，因为 Lean 会检查它们的最终输出。但同一个检查器也无法挽救一个形式化了错误需求的定理。

假设一个解压器定理证明每一次生成的状态转换都留在表内。这很有价值，但并不能证明它兼容每一个 Zstandard 文件。它也没有说明拒绝服务行为、内存限制、侧信道或实现性能。

每一项额外保证都需要相应的陈述，以及与实际程序之间的连接。如果该连接遗漏了一项假设，Lean 可以证明形式化陈述，而已部署的系统仍可能存在漏洞。

这个问题类似于一份措辞精良却管错了交易的合同。完美的内部一致性无法弥补缺失的义务。验证只能在由人定义的边界内提升信心。

Langley 的 FSE 定理展示了更理想的情形。这些性质直接对应于优化解码循环所需的假设。表大小、符号分配、有效转换和唯一可达性，都是具体的不变量，而不是泛泛而谈的质量主张。

一旦这些不变量存在，编译器和内核就可以在整个程序中强制执行它们。未来任何违反其中之一的修改，都将在实现或证明发生改变之前无法通过类型检查。

这创造了不同的评审面。工程师无需以同等注意力检查数千个生成的证明步骤；他们需要审计定理、其假设，以及代码与模型之间的连接。

稀缺的专业能力会转移到这里。过去可能花数天引导策略的资深工程师，如今或许会用这些时间来完善形式化契约。AI 处理大部分机械化搜索，而人类评审者则判断该契约是否值得信任。

这种方法也能让分歧变得更有成效。产品、安全和工程团队经常使用同一个词，例如“有效”，但各自带有不同定义。形式化规格会迫使这些定义成为可见的条件。

知识工作也面临同样的隐性不变量问题。市场分析可能需要最新来源、明确区域和固定报告期。团队常常将这些约束留在评论、会议记录或某位员工的记忆中。

AI 可以生成一份精美的报告，却在不知不觉中违反其中任何一项约束。更好的工作流是在生成开始前就呈现重要约束。某些条件可以转化为自动化检查，另一些则应保留为明确的审查问题。

这正是知识融合在 AI 辅助工作中重要的原因。当生成结果始终与相关记录、决策和证据相连时，评估起来就更容易。这样的检查不像 Lean 内核那样绝对，但其运行原则相似。

因此，组织不应接受对证明自动化最简单化的理解。它的价值并不在于允许人们停止审查 AI 输出，而在于提供了在更高价值层面进行审查的机会。

生成证明的成本会降低。定义正确性会变得更加核心。无法就需求达成一致的团队，不会因为加入 Lean 或 AI 证明器就获得强保证。

Lean 形式化验证正对仅依赖测试的工作流施加压力

最直接的压力落在那些构建安全敏感代码、却仍将测试视为最高保障手段的团队身上。

测试依然不可或缺，因为它评估真实执行、集成、性能和环境行为。形式化验证回答的是另一个问题：模型是否在证明覆盖的所有情形下都满足某项性质。

两种方法不能相互替代。Langley 将 Zstandard 测试向量作为普通单元测试使用，同时证明表生成器更广泛的性质。测试验证兼容性示例，而定理覆盖普遍的结构不变量。

变化来自经济性。过去，形式化验证需要足够多的专业劳动，以至于许多团队甚至无需评估其价值便可直接搁置。如果 AI 缩短了构建证明的时间，这种自动搁置就更难成立。

密码学软件提供了早期的验证场景。细小的算术错误就可能使更大的安全系统失效，而许多重要函数本就具备数学规格。通用保证的价值在这里尤其清晰。

一份 2026 年 5 月的经验报告介绍了一条Rust 验证流水线，可将生产级密码学代码转换为 Lean。它结合 Rust 提取工具、形式化规格库，以及 Aristotle 和 Aleph 等 AI 证明器。

研究人员将该流水线应用于 Plonky3 和 RISC Zero 的组件。目标包括域算术、Merkle 包含性验证、多项式求值，以及零知识系统使用的 FRI 操作。每一份提交的证明仍会经过 Lean 内核检验。

论文也记录了工程摩擦。工具链版本会漂移，转换工具只支持部分 Rust 特性，缺失的引理会阻碍自动化。AI 证明器完成了一些证明义务，其他部分仍需要人工处理。

这些证据支持一种审慎预测：验证很可能会先通过狭窄、高价值的组件进入生产环境，而不是直接覆盖整个业务应用。团队可以从解析器、授权规则、密码学操作和状态转换逻辑入手。

这些组件具备三个有用特性：其行为通常可以被精确定义，失败代价高昂，而且边界足够小，能够被当前工具理解。

这种压力也将传导至销售 AI 编程系统的厂商。生成更多代码正变得不再那么有差异化。生成具有可独立检查性质的代码，构成了更强的主张。

编程代理最终或许会返回三项相互关联的产物：实现、所需行为的形式化陈述，以及经内核检查的证明。审查者可以将重点放在该陈述是否符合产品需求上。

以测试为中心的平台不会消失，而是会作出回应。可以预期，模糊测试、基于性质的测试、符号执行和证明将形成更紧密的组合。生成式测试仍将继续发现形式模型与复杂部署环境之间的不匹配。

形式化验证厂商同样面临压力。它们传统优势的一部分来自稀缺的证明构造专业能力。AI 降低了重复性策略工作的价值，同时提高了对规格设计、集成和保障架构的需求。

管理者不应将这一转变理解为立即减少招聘。早期采用通常会先创造集成工作，之后才减少维护工作。团队需要既理解应用领域、又理解证明边界的人才。

因此，有价值的问题并不是 Lean 是否取代传统编程，而是哪些昂贵的假设如今可以从注释和审查清单转移到由机器强制执行的契约中。

Zstandard 结果并不能证明什么

一个尚未公开的玩具解码器，无法证明当前 AI 证明器能够扩展到生产代码库、频繁变更或规格不完善的系统。

Langley 直接说明了这些局限。他的解码器在其机器上的运行速度约为 zstd 命令的十分之一。他还警告说，强类型可能会放大变更，因为修改后的假设会传播到派生类型中。

这种传播可能带来好处：它会暴露每一个需要关注的依赖组件。但它也可能将一次小型产品变更，变成一个大型证明维护项目。

性能带来了另一项权衡。当一个对象只有一个引用时，Lean 可以进行原地更新。因此，一项保留了额外引用的小型代码变更，可能在不改变功能正确性的情况下损害性能。

证明自动化不会自动发现这种回归。定理必须包含适当的性能模型，或者需要由其他基准测试捕捉它。正确性和效率仍是两项独立的工程主张。

代码库规模带来了最重要的挑战。Langley 的示例具有聚焦的实现，且定理与附近定义相连。生产系统则将语义分散在包、生成代码、构建配置、数据库和外部服务之中。

2026 年 VeriSoftBench 研究使用来自 23 个开源 Lean 代码库的 500 项证明义务测试了这一问题。其代码库基准测试保留了项目特定的定义和跨文件依赖关系。

研究人员发现，在面向数学的 Lean 任务上训练的证明器，迁移到以代码库为中心的软件验证时表现不佳。当证明依赖于更长、更多步骤的本地定义链时，性能会下降。

与暴露整个代码库相比，提供精心挑选的上下文改善了结果。但仍有很大的改进空间。上下文检索有所帮助，却没有解决推理问题。

这一发现直接限制了对 Langley 主张最强版本的解读。LLM 如今能够产出有意义的软件证明，但并不能仅因为一个项目使用 Lean，就处理其中的每一项证明义务。

已公开实验周围也存在验证缺口。读者可以审阅 Langley 的解释、定理陈述和限制条件，却无法复现完整结果，因为他没有公开解码器或证明文件。

他确认没有留下 sorry 声明，是有用的一手证据。但这并不等同于从固定版本代码库进行独立构建。该结果应被视为可信的工程报告，而非基准测试。

安全团队还必须审视可信计算基。Lean 的内核有意保持精简，独立的内核实现可以比较结果。然而，部署仍依赖编译器、运行时行为、硬件，以及任何外部模型的准确性。

系统可以证明一个 Lean 函数满足 Lean 规格。还需要额外工作来表明优化后的原生代码保留这些语义。Langley 提出了经验证汇编作为一种可能方向。

这些限制并未抹去该结果，而是界定了它的位置。Lean 证明自动化似乎适用于边界明确的组件：其性质能够精确陈述，且其依赖关系能够容纳在可用上下文中。

这已经比“形式化证明始终要求专家手工完成每一步”的旧有假设更具实用性。但它距离面向生成式软件的通用“一键验证”仍很遥远。

三个信号将表明证明自动化是否真的到来

下一阶段取决于可复现性、代码库规模的维护能力，以及在普通工程工作流中的采用。

第一个信号是与 Langley 模式一致、可公开复现的实现。它应包括源代码、定理陈述、生成的证明、固定版本的依赖项，以及会拒绝未解决空洞的自动化构建。

公开产物将使独立团队能够衡量证明时间、模型依赖程度和维护成本。它还会揭示从初始实现到证明获接受之间发生了多少人工干预。

如果多个团队在解析器或压缩库上复现这一工作流，Langley 的结论将更有说服力。如果结果依赖大量隐藏提示或人工重构，当前的生产力主张就会减弱。

第二个信号是对不断变化的代码库的表现。一个有用的系统必须能够在常规重构、依赖更新和需求变化后修复证明。一次解出定理的价值，低于让它跨版本始终保持已解状态。

因此，代码库规模的基准测试应加入纵向任务。AI 证明器可以接收连续提交，并在保留原始规格的同时修复受影响的证明。团队应跟踪已接受的修复、耗时、计算资源使用和人工编辑。

在密集的本地依赖关系上取得改进，将回应 VeriSoftBench 识别出的弱点。若持续失败，AI 证明将被限制在具有精心策划上下文的小型模块中。

第三个信号是融入主流编程代理和持续集成系统。证明自动化在拉取请求能够陈述所需不变量、生成证明并由 Lean 自动验证时，才真正具备可操作性。

这一过程还需要透明的失败模式。找不到证明的模型必须区分缺少上下文、定理困难、代码不兼容和陈述错误。否则，团队只会得到又一个不透明的红色构建结果。

采用很可能会从组织已能编写精确需求的领域开始。密码学、协议实现、编译器、财务控制和访问控制系统都符合这一描述。更广泛的业务软件推进速度会更慢。

知识工作者也应在自己的工具中观察同样的模式。可靠自动化需要明确的输入、验收规则、可追溯的证据，以及有权拒绝结果的检查器。

大多数办公室任务无法达到数学确定性，但仍可以采用更窄的关卡。一份研究简报可以要求带日期的来源；一份销售分析可以要求每项账户主张都映射到客户记录；一份项目更新可以标记缺乏近期工作支持的陈述。

这种转变使 AI 从未经检查的作者，变为在受控流程中运行的候选内容生成器。人仍然负责定义边界，并审查检查机制无法覆盖的部分。

Lean 证明自动化提供了这一未来最清晰的版本，因为它的检查器是精确的。模型在搜索过程中可以反复表现得不一致、冗长或错误。只有有效证明才能进入程序。

未来几个月的问题并不是 LLM 能否生成任何形式化证明。它们已经能做到。问题在于，团队能否反复将真实需求转化为持续维护、经机器检查的软件，而不重演旧有的十倍劳动负担。

选择工作流程中一项代价高昂的假设，写下能够让它得到可验证确认的条件。如果该条件可以检查，就应先将这项检查自动化，再去自动化更多产出。这正是 Langley 实验背后的实用教训，也是自动化如今必须达到的基本证明标准。