$catMANUAL||~26 分钟

Mistral 开源了一款数学证明模型：Leanstral 1.5 发布，AI 帮你验证代码不再是科幻

advertisement

昨晚刷 Hacker News 的时候，看到一条消息直接把我从床上拉起来了——Mistral 发布了 Leanstral 1.5，一个专门做数学证明和代码验证的 AI 模型。Apache-2.0 协议，免费 API，6B 激活参数就能干翻一堆大模型。

说实话，之前我对"AI 做数学证明"这件事一直持怀疑态度。感觉这东西就是学术圈的自嗨，跟普通开发者没什么关系。但看完 Leanstral 1.5 的发布稿之后，我觉得事情开始变得有意思了——不是因为它的数学成绩有多好，而是因为它真的能帮助验证真实世界的代码，还找到了 5 个之前没人报告的 bug。

这篇文章就从我的视角来聊聊，Leanstral 1.5 到底能干什么，对普通开发者有什么意义，以及这东西现在够不够实用。

先说说我为什么关注这件事

我建站三个月，一直在追各种 AI 工具的发布。但说实话，这段时间模型发布越来越频繁，我已经有点"发布疲劳"了。什么 xxx 又发布了新模型、xxx 又融资了多少亿——消息多到看不过来，而且同质化严重。

但 Leanstral 1.5 不一样。

首先，它做的事情很特别——不是又一个"写代码的 AI"，而是一个"验证代码的 AI"。其次，它来自 Mistral，这个法国公司从来不按套路出牌。当大家都在堆参数、堆算力的时候，Mistral 在做 6B 参数的 MoE 模型，Apache-2.0 开源，免费 API，然后在形式化证明这个非常窄的赛道上做到了 SOTA。

这种"非主流"的打法，反而让我觉得值得认真看一看。

背景：Leanstral 这个系列是干什么的？

先说一下 Leanstral 的前世今生。Mistral 在去年推出了第一代 Leanstral，目的是在 Lean 4 这个领域里做一个好用的定理证明助手。Lean 4 是一个交互式定理证明器和函数式编程语言，最早是由微软研究院搞出来的，这些年一直在学术界和验证领域使用。

Leanstral 1.5 是第二代，我的评价是：进步太大了，大到离谱。

一个只有 6B 激活参数的模型（总参数 119B 但走的是 MoE 架构），居然在好几个数学证明 benchmark 上实现了 SOTA（state-of-the-art）。而且不是靠堆算力，是靠聪明的训练方法。

技术参数速览

我直接把关键数据撂这儿，有兴趣的可以细看：

  • 架构：MoE（混合专家），119B 总参数，6B 激活参数
  • 协议：Apache-2.0，完全开源
  • License：免费商用，不搞幺蛾子
  • 发布方式：HuggingFace 权重 + 免费 API
  • 训练方法：三步走——mid-training（中期训练）→ SFT（监督微调）→ RL with CISPO（强化学习）

CISPO 这个名看着挺唬人，其实就是一种在推理环境里做强化学习的方法。简单来说，模型写完证明之后，Lean 编译器会给反馈——通过编译就算你对了，没过就算错了。模型根据反馈不断调整策略，像人类做题一样，错了就重来。

这个 6B 激活参数到底什么概念？

MoE 架构的一个好处就是，虽然总参数量大，但跑的时候只用激活一部分。Leanstral 1.5 每次推理只跑 6B 参数，也就是说，你不需要买 H100，不需要 A100，甚至一个消费级显卡可能都能跑。

相比之下，GPT-5.5 这种模型动辄几百 B 参数全部激活，跑一次烧的钱够你吃一周的饭了。

跟竞品的对比到底怎么样

Mistral 在发布稿里拿 Leanstral 1.5 跟几个模型做了对比。坦白说，他们对自己的定位还是蛮清醒的——没有说自己"最强"，而是说"在这个细分赛道上，用这个价格，我们能打"。

Leanstral 1.5 在 FATE-H 和 FATE-X 上比 Seed-Prover 1.5 和 Goedel-Architect 都强，在 PutnamBench 上超过了 Seed-Prover 1.5 high 的 580 题（Leanstral 是 587）。而且在 PutnamBench 上每个问题成本大约 $4，跟 Seed-Prover 的 $300+ 相比，省了 75 倍。

那些排在前面的——比如 Aleph Prover（$54-68/问题）或者那些用了自然语言 proof guidance 的——运作条件都不一样。Leanstral 1.5 的优势不在于"绝对能力最强"，而在于"够用 + 便宜 + 开源"。

HN 社区的反应

Leanstral 在 HN 上的讨论也挺有意思的（251 分，74 条评论）。我挑了几个有价值的观点：

有人质疑他们发现的 bug："这不就是开箱即用的 fuzzing 就能找到的溢出吗？" 确实，如果知道要测什么，proptest 一秒就复现了。但 Leanstral 做的事情是不需要知道"要测什么"——它自动扫描整个仓库，自动推断正确性属性，然后找出不一致的地方。

还有人问："我完全不懂 Lean，能用这个干吗？" 回答是可以用 Aeneas 把 Rust 代码翻译成 Lean，然后让 Leanstral 验证。不需要你懂 Lean 的语法，只需要理解你要验证什么性质。

最有价值的一条评论来自一个实际用了半年 Lean 的开发者，他说从零开始学 Lean 到能写有用的程序，花了大约 6 个月，而 AI 辅助在这个过程中帮助巨大。"这个语言本身就很漂亮，不管是不是做定理证明。"

训练过程：三步打造一个证明专家

Leanstral 1.5 的训练流程分三个阶段，每个阶段的都有不同的目标。

第一阶段：Mid-Training（中期训练）

这一步其实就是把模型在大量的 Lean 代码和数学证明文本上继续预训练。目标是让模型"学会" Lean 的语法、证明模式、库的使用习惯。

Mistral 没有公开他们用了多少数据，但从结果来看，这步应该做的挺足的——模型对 Lean 4 的理解深度已经到了一般人类开发者需要学半年的程度。

第二阶段：SFT（监督微调）

这个阶段用大量的人工标注或正确证明做监督学习。模型的输入是一条定理或一个需要证明的命题，输出是一段完整的 Lean 验证代码。跟正常写代码的 SFT 几乎一样，只是领域换成了形式化证明。

第三阶段：RL with CISPO（强化学习）

这是最关键的步骤。两个训练环境：

多轮交互环境（Multiturn Environment）： 模型拿到一个定理，尝试给出证明。Lean 编译器检查证明是否通过——如果通过编译就得分，否则模型收到编译器的错误信息，然后重试。就像你在刷 LeetCode 的时候，提交了代码然后看通过不通过。模型在这个循环里会不断调整证明策略，直到成功用完全部尝试次数。

代码 Agent 环境（Code Agent Environment）： 这个更接近真实开发者的工作方式。模型可以：

  • 编辑文件
  • 运行 bash 命令
  • 调用 Lean 语言服务器实时检查类型信息、goal 状态、错误
  • 在仓库中完成部分证明、构建辅助引理
  • 通过多轮上下文压缩来延续长任务

一个完整的 agentic 环境，不是单纯的"输入-输出"，而是像人类开发者一样在文件系统中操作。

训练数据规模

Leanstral 系列从一开始就定位在 Lean 这个生态。Lean 社区虽然不如 Python 大，但有一个好处——所有的证明都会被编译器验证，所以训练数据的质量天然高。不需要人工标注，不需要 LLM-as-Judge，Lean 编译器本身就提供了一个客观的、二元的判断标准：编译通过了，就对了。

这也是为什么 Mistral 能用相对较少的资源做出这么好的数学证明模型。编译器作为 reward model，不需要人来标数据。

Benchmark 成绩：确实能打

Leanstral 1.5 在几个主流数学证明 benchmark 上的表现：

  • miniF2F：100%（满分）。这是一个跨系统的数学证明 benchmark，从小学题到 IMO 级别都有。不是那种刷几个月就能过的那种——这是真的难。之前没有任何模型做到满分。
  • PutnamBench：587/672（87.4%）。普特南数学竞赛，大学数学竞赛的天花板级别。
  • FATE-H：87%（SOTA）。研究生级别的抽象代数。
  • FATE-X：34%（SOTA）。博士级别的抽象代数。能拿到博士级别问题的三分之一，已经不是运气能解释的了。

FLTEval：实战能力的硬指标

除了这些学术 benchmark，Mistral 还发布了一个新的 benchmark——FLTEval。这个 benchmark 的特别之处在于，它不像 PutnamBench 那样是"竞赛题"，而是基于 Fermat's Last Theorem 仓库的真实 pull request 做出来的。全是真实的、复杂的实际证明问题。

Leanstral 1.5 在这个 benchmark 上 pass@1 达到了 28.9（上一代是 21.9），pass@8 达到了 43.2，超过了 Opus 4.6 的 39.6。而且成本只有 Opus 的七分之一。

测试时缩放（Test-Time Scaling）

还有一个让我印象深刻的点——Leanstral 1.5 的测试时缩放曲线非常漂亮。

什么意思呢？就是说如果你给它更多时间（更多 token）去思考，它的表现会持续提升。从 50k token 只解出 44 道 PutnamBench 题，到 200k token 的 244 道，1M token 的 493 道，再到 4M token 的 587 道。几乎是单调递增的，没有一个明显的"天花板"。

这说明模型不是靠蒙对的，而是真的有持续的推理能力。你给它更多算力，它就给你更好的结果。这在工程上是非常有价值的——你可以根据预算来调节它的表现，而不是"要么解出来，要么解不出来"。

真正让我兴奋的：代码验证

Leanstral 1.5 有一个很有意思的能力——验证真实世界的 Rust 代码。

具体流程是这样的：

  1. 用 Aeneas 工具把 Rust 代码翻译成 Lean 代码
  2. Leanstral 分析代码意图，从代码本身推断出"正确的行为应该是什么"
  3. 然后它尝试证明这些"正确性属性"
  4. 如果四个尝试都失败了，它反过来尝试证明"代码有问题"——也就是证明反例存在
  5. 如果反例也证明了，说明真的有 bug

Mistral 团队拿这个流程扫了 57 个开源仓库，发现了 11 个真实的安全性质疑，其中 5 个是之前没人报告过的 bug。

具体 bug 案例：varinteger 库的溢出

他们发了一个具体的例子——datrs/varinteger 这个 Rust 库里的 zigzag 解码函数。当输入是 Std.U64.MAX 的时候，表达式 (value + 1) 会溢出，debug 模式下直接崩溃，release 模式静默数据损坏。

这种 bug 确实恶心。测试工具可能不会想到去测 u64::MAX 这个边界值，fuzzing 跑多少次也不一定命中这个路径。但 Leanstral 用形式化验证的方式，直接从代码结构层面发现了它。

说个题外话——HN 评论区有人反驳说"这明明就是个开箱即用的边界值测试就能找到的 bug，你们吹什么吹"。确实，对于单个这样的溢出，写个 #[test] 可能几秒钟就完了。但 Leanstral 不是人工去一个个测的，它是自动化的、大规模的、无差别的把 57 个仓库全部扫了一遍，找到 5 个 bug。这种规模的验证，人工根本做不到。

AVL 树的时间复杂度证明

还有一个案例更硬核——AVL 树的时间复杂度证明。

AVL 树是一个自平衡二叉搜索树，关键性质是插入和删除的复杂度是 O(log n)。Leanstral 1.5 成功了证明了这个性质对一个真实的实现（不是玩具代码）是成立的。

这个过程耗时 270 万个 token、22 轮压缩，模型系统地展开了 TimeM monad 的每一层，最终得出了插入操作 48 步/高度单位 + 常数、删除操作 O(log n) 的严格界限。

说人话就是：它证明了这段代码在最坏情况下也能保证 O(log n)，不管输入什么样。

性价比：$4 vs $300+

Leanstral 1.5 的另一个让我心动的点是成本。

在 PutnamBench 上，Leanstral 1.5 每个问题平均花费 ~$4。而 Seed-Prover 1.5 的高设置模式，每个问题跑下来要 $300+（H20 算力跑 10 天）。

就算跟 Aleph Prover 比，Leanstral 1.5 的 $4/问题 vs Aleph 的 $54-68/问题，也是 10 倍以上的差距。

Mistral 的思路跟其他公司确实不一样。别的公司在堆算力、堆参数、拼 SOTA，Mistral 在拼效率——用最小的成本做特定领域的事。之前他们的 OCR 模型也是这个逻辑，花 $100 能用一整年。

怎么上手

Mistral 给了一套比较完整的工具链。如果你装了 uv，几步就能跑起来：

bash
1
# 安装 Mistral Vibe
2
uv tool install mistral-vibe
3
vibe --setup
4
5
# 安装 Leanstral
6
/leanstral
7
exit
8
9
# 启动 Lean agent
10
vibe --agent lean

还推荐安装 Lean LSP MCP 来增强体验。MCP（Model Context Protocol）是一个让 AI 工具跟开发环境交互的标准协议，装了之后 Leanstral 可以通过 Lean 语言服务器实时获取类型信息和错误：

bash
1
# config.toml 加这一段
2
[[mcp_servers]]
3
name = "lean-lsp"
4
transport = "stdio"
5
command = "uvx"
6
args = ["lean-lsp-mcp"]
7
tool_timeout_sec = 600

完事了就可以让它帮你验证代码、证明定理或者分析仓库了。

如果没有 uv，也可以直接调 Mistral API：

bash
1
curl -s "https://api.mistral.ai/v1/chat/completions" \
2
  - H "Authorization: Bearer $MISTRAL_API_KEY" \
3
  - d '{"model":"leanstral-1-5","messages":[{"role":"user","content":"用 Lean 证明 forall n : Nat, n + 0 = n"}]}'

我跑了一个小测试

拿到消息之后我立刻去试了一下。注册了 Mistral 的 API 账号，拿到免费额度之后就开始搞。

第一个测试是让它证明一个简单的数学性质——forall n : Nat, n + 0 = n。这个性质在 Peano 算术里是最基础的，但如果不是专门训练过的模型，很多模型会搞混。

Leanstral 1.5 的响应大概在 2 秒左右，直接给出了一个完整的 Lean 证明：

lean
1
theorem add_zero (n : Nat) : n + 0 = n := by
2
  induction n with
3
  | zero => rfl
4
  | succ n ih =>
5
    simp [Nat.succ_eq_add_one, ih]

干净利落。回显模式（thinking）大概占了 1 秒，输出花了 0.5 秒。

然后又试了那个 varinteger 的溢出——让它分析一个类似的 Rust 函数看看能不能发现溢出问题。它也确实指出了边界值的问题。不过这个环节 Aeneas 翻译那一步我还没完全跑通，等搞定了再详细写。

注意事项

有几个点大家上手的时候要注意：

  1. Leanstral 只懂 Lean 4，不懂 Lean 3。 两个版本语法不兼容，如果还在用旧版本，需要先迁移。
  2. 模型擅长数学证明，但在代码验证上还有局限。 特别是涉及复杂内存模型的代码（比如 Rust 的生命周期、unsafe 代码），Aeneas 翻译之后验证的准确性取决于翻译质量。
  3. 成本虽然低，但不是零。 $4/问题是 PutnamBench 的平均数，实际使用中如果一直跑复杂的 agentic 循环，token 消耗还是不少的。建议先用免费 API 额度试水，评估你的场景到底需要多少算力。
  4. 目前没有针对中文的优化。 模型的 prompt 输入和输出都是英文和 Lean 代码，中文直接沟通的效果可能不太好。但如果你只是用它验证代码，语言其实无所谓。

这东西对普通开发者有什么用？

聊到这里，你可能想问：我一个 Web 开发者 / 后端工程师 / 全栈开发，关我什么事？

我的答案是：现在还不太关你的事，但快了。

现在的适用场景

如果你在写 Rust、或者做需要安全关键软件的工作（嵌入式、金融系统、密码学、协议实现），Leanstral 1.5 现在就能帮你找到不容易发现的问题。特别是配合 Aeneas 那个流程，Rust 代码可以直接翻译成 Lean 做验证，不需要自己手写形式化规约。

短期内会发生的

我觉得接下来一年内，可能会出现这样的事情：

  1. CI/CD 里集成 Lean 验证。每次 PR 提交，自动跑形式化验证检查关键路径，像现在的 linter 和测试一样自然
  2. IDEs 集成。VSCode 插件，写 Rust 就能看到"这段代码在输入 X 时会溢出"这样的实时提示
  3. 模型推理成本的进一步下降。$4/问题已经很便宜了，但会越来越便宜

长期来说

我一直觉得，测试覆盖率 100% 不能证明你的代码没有 bug——它只能证明你测过的那些 case 没有 bug。而形式化验证之所以强大，是因为它从数学上证明了你的代码在所有可能的输入下都符合规约。

过去形式化验证的门槛太高了——你要学 Lean、写规约、手动推理。现在 AI 把门槛降低了很多。Leanstral 1.5 从源码自动推断正确性属性，不需要你写繁琐的规约文档，这就是一个巨大的进步。

如果说测试是保安，形式化验证就是 FBI 级别的背景调查。 以前请不起 FBI，现在价格降下来了。

踩坑记录：跟 fuzzing 比怎么样？

我研究 Leanstral 的时候，HN 评论区有个很有价值的讨论——很多人质疑 Leanstral 发现的溢出的 bug，其实 fuzzing 也能很快发现。

我试了一下，确实。用 Rust 的 proptest 写一个 round-trip 测试，不到一秒钟就复现了那个溢出：

rust
1
// 确实，对于这个具体 bug，fuzzing 也能发现
2
#[test]
3
fn test_zigzag_overflow() {
4
    // 用 proptest 随机生成输入
5
    proptest!(|(value: u64)| {
6
        let encoded = zigzag_encode(value);
7
        let decoded = zigzag_decode(encoded);
8
        assert_eq!(value, decoded);
9
    });
10
}

但这里面有两个关键区别：

  1. 你要先知道这个函数有 bug，才会去写测试。 Leanstral 的方式是扫整个仓库，不需要你指定要测什么。fuzzing 需要你自己定义测试属性。

  2. 形式化验证能证明"没有 bug"，测试只能证明"测试过的那些 case 没有 bug"。 这不是技术细节的区别，这是根本上的质量保证级别的区别。

在 Dan Luu 的最新博客里也提到了类似的观点——他在测试 AI 生成的代码时，发现用 fuzzing 结合 LLM 来生成 fuzzer，效果比单纯问 LLM"这个代码有没有 bug"要好得多。Leanstral 本质上就是把这两个东西结合到了一起——用 LLM 的能力来做形式化验证，既有人工的弹性，又有数学的严谨性。这也是我认为形式化验证即将迎来爆发的原因之一。

我的感受

说实话，看完 Leanstral 1.5 我有点感慨。

Mistral 这家公司一直挺有意思的。他们没有去跟 OpenAI 和 Anthropic 拼大模型烧钱，而是走了一条完全不同的路——小而精、领域专用、开源友好。Leanstral 1.5 就是这个策略的又一个例子。

在大家都在追"更大的模型、更多的参数、更贵的使用成本"的时候，Mistral 在做"6B 参数能干 90% 的活，而且完全免费、开源、可以商用"。你要说它不够 SOTA 也行，但 $4/问题 vs $300/问题的差距，让我选的话，差的那些分数我完全可以接受。

而且 5 个真实 bug 是实打实的，不是 benchmark 上的数字。它们真的存在于开源项目里，真的可能导致崩溃或者数据损坏。光凭这一点，这个模型就已经有实际价值了——不需要它成为最聪明的 AI，只需要它能在你睡觉的时候扫一遍你的代码库，找到你忽略的问题。

这让我想起一个趋势——AI 行业正在从"一条更大的模型"往"一群更专业的模型"分化。OpenAI 和 Anthropic 在追 AGI，追通用大模型。但像 Mistral 这样的公司，选择在特定领域做到极致，然后用开源和低价打市场。对于开发者来说，这其实是更好的局面——你可以根据任务选模型，而不是"一个模型打天下"。

RAG 选专门的嵌入模型，代码生成用专门的编程模型，数学证明用专门的 Lean 模型。每个领域的门槛都降低了，开发者手里的工具箱越来越丰富。

我觉得形式化验证离"每个开发者的必备工具"还有一段距离，但 Leanstral 1.5 让这个距离缩短了一大步。以前你要学 Lean、学形式化方法、手动写规约和证明。现在，你只需要把代码丢给它，它能自动发现可疑的地方。

这东西就像早期的 linter——一开始大家都觉得是"花架子"，后来发现是真的能减少 bug。形式化验证可能也在走同样的路：先被当成学术界的玩具，然后慢慢渗透到日常开发流程中，最后变成标配。你想想，十年前谁会想到"代码格式化"这种事情需要专门的工具？现在 ESLint、Prettier 哪个项目不用。五年前谁会想到类型检查会成为 JS 的标配？现在 TypeScript 是新项目的默认选择。形式化验证可能也处于类似的转折点上。

后面我打算把 Leanstral 接入到我的一些 Rust 项目里试试，看看能不能真的在 CI 环节发现一些潜在问题。如果能跑通，我再写一篇实操教程，把 Aeneas 翻译、Leanstral 验证、CI 集成全套流程走一遍。

有啥问题评论区聊。

advertisement