AI 没有证明费马大定理：1300 万行 Lean 代码背后，是"可验证 AI"的新范式

先澄清一件事：Claude 没有证明费马大定理。这个定理 1995 年就被怀尔斯证出来了。

Anthropic 做的是另一件事------花了 11 天，把怀尔斯那份 129 页的证明转写成机器能逐行核验的形式，写下约 1300 万行 Lean 代码，证明过程中间定理 3 万多个。

听起来没那么性感？但这件事的意义可能比"AI 独立证明一个新猜想"更大。因为它跑通了一套范式：让 AI 的每一份产出，都能被一个不依赖信任的机制判定对错。

---

一、为什么"验证数学"本身是个难题

1.1 先看费马大定理有多难搞

1637 年前后，费马在《算术》页边写下那句著名的话：当整数 n > 2 时，不存在正整数 a、b、c 满足 $an+bn=cna^n\; +\; b^n\; =\; c^n$ an+bn=cn，并留下一句"我发现了绝妙的证明，只是页边太窄写不下"。

然后 350 年没人证出来。

1908 年有人悬赏 10 万德国金马克（约合今天 100--200 万美元）征解------仅第一年就收到 621 次错误证明。

1993 年 6 月，怀尔斯用三场讲座公布了他认为正确的证明。两个月后，审稿人问了一个问题，暴露出关键缺口。怀尔斯又花了近一年，先是独自挣扎，后来和学生 Richard Taylor 合作，濒临放弃时才意识到早先被他丢弃的一个思路能补上。1995 年 5 月，129 页的完整证明才发表。

这就是大型数学证明的现实：验证它，和生产它一样难。

1.2 为什么这么难

因为人类的数学证明是写给人看的，不是写给机器看的。它有两个特征：

• 省略"显然"的步骤。一句"显然由此可得"，另一个数学家点头就过去了，但机器不接受。
• 大量调用未形式化的前置结论。一条跨越代数、调和分析、几何、数论的证明，审稿人要逐层追踪它依赖的定义、定理与推导。

所以形式化一个复杂证明，传统上是以年为单位 的工作。Kevin Buzzard 2024 年在帝国理工发起的 FLT 形式化社区工程，仅第一阶段的技术蓝图就有 86 页，原定周期按年算。

而 Claude 用了 11 天。

---

二、原理：形式化证明到底是什么

2.1 从"说服人"到"可判定"

形式化证明的核心转变，是把"这个证明有没有说服力"变成"这个证明能不能被一个程序判为合法"。

Lean 是一个证明助手（proof assistant），它做的事情可以这样理解：

  自然语言证明  ──→  说服另一个数学家  （依赖直觉、共识、信任）
  形式化证明    ──→  被内核逐条检查    （只依赖公理和规则）

Lean 的数学基础是依赖类型论 （dependent type theory），背后是著名的 Curry-Howard 同构：

命题即类型，证明即程序。 证明一个命题 = 构造出一个属于该类型的项； 检查一个证明 = 类型检查一个程序。

这个同构是整套体系的支点。它把"证明对不对"这个哲学问题，变成了"程序能不能通过类型检查"这个可机械判定的问题。

2.2 内核：极小的可信计算基

Lean 的架构有个关键设计：内核（kernel）非常小，只负责判定，不做任何复杂的自动化 。所有的 tactic、化简、自动化策略都在内核之外，它们最终必须生成内核能接受的证明项。

这个设计带来一个重要性质：

  即使上层的自动化 tactic 有 bug，
  只要内核是对的，最终产物就是对的。

Claude 生成的最终证明，只使用了 Lean 的三条标准公理 ，由 Lean 内核检查通过。而且它又被 nanoda ------一个用 Rust 独立实现的证明检查内核------二次验证过，确认所有内部声明逻辑自洽。

两个独立实现的内核都通过，这才是"不依赖信任"的含义。

2.3 难在哪里：从"显然"到"1300 万行"

形式化之所以慢，本质是把人类省略的每一步都补出来。Claude 的最终产物：

指标	数值
耗时	11 天（大部分时间自主运行）
Lean 代码	约 1300 万行
证明的中间定理	30,300 个（29,500 个进入最终版本）
输出 Token	约 60 亿
模型	内部通用研究模型，能力约等于 Claude Fable 5.1
规模对比	约为 Mathlib（Lean 社区数学库）的 5 倍

1300 万行这个数字，既是成绩，也是局限------后面会讲。

---

三、范式核心：神经符号闭环

现在讲这套东西真正值钱的部分。

3.1 LLM 的死穴与解药

自回归模型有个结构性缺陷：它不知道自己对不对。它输出的每个 token 都是" plausible（看起来合理）"，而不是"correct（正确）"。在开放式写作里这叫创造力，在数学和代码里这叫幻觉。

形式化证明给了一个干净的解法------引入一个外部判定器，形成闭环：

        ┌──────────────────────────────────────────┐
        │                                          │
        ▼                                          │
   ┌─────────┐      证明候选      ┌──────────┐      │
   │  LLM    │ ────────────────▶ │  Lean 内核 │     │
   │  提案   │                    │  判定     │     │
   └─────────┘                    └────┬─────┘      │
        ▲                              │            │
        │                         通过 / 报错        │
        └──────────────────────────────┘            │
                    错误信息反馈 → 重试 ─────────────┘

这个闭环的关键性质：

1. 判定是二值的。内核要么接受，要么拒绝，没有"大概对"。
2. 判定不依赖生成者的可信度。LLM 再怎么胡说，内核不认就是 0。
3. 错误信息是免费的监督信号。Lean 会精确告诉你哪一步的类型对不上，这是最好的 RL 奖励。

这就是为什么数学和代码是 AI 最先啃下来的两个领域------它们都有廉价、可靠、即时的判定器。编译器和测试套件对代码做的事，和 Lean 内核对证明做的事，是同一件事。

3.2 对比：有判定器和没有判定器

  ┌── 无判定器（开放式生成）─────────────────────┐
  │  LLM 输出 → 人类判断 → 反馈延迟数天/数月      │
  │  幻觉无法在生成时拦截                         │
  │  奖励信号模糊，RL 容易被 hack                 │
  └───────────────────────────────────────────┘

  ┌── 有判定器（形式化/编译）────────────────────┐
  │  LLM 输出 → 内核/编译器判定 → 毫秒级反馈       │
  │  错误在生成时就被拦截                         │
  │  奖励信号客观，无法被 hack（做对就是做对）      │
  └───────────────────────────────────────────┘

可验证奖励（RLVR）能成立，前提就是存在一个不可欺骗的判定器。 数学是其中最纯粹的一种。

---

四、工程死结：光有闭环不够

如果只是"LLM 生成 + Lean 判定"，这件事早就做成了。真正的难点在长程、大规模、多智能体。

4.1 死结一：多智能体协作会失去全局

早期实验直接失败了。多个 Claude 智能体并行工作时：

• 它们不知道哪些命题已经被证出来了；
• 无法有效复用彼此的结果；
• 长时间运行后丢失了对整体进度的把握，协作随之停滞。

最终证明里，约 7% 的非模板代码来自这些失败尝试------它们没进最终版本，但被保留在工作日志里。

这不是模型能力问题，是工程脚手架问题。

4.2 死结二：代码膨胀

1300 万行，是 Mathlib 的 5 倍。Mathlib 经过长期人工维护，代码紧凑、审查充分。而 AI 生成的证明几乎肯定远长于实际需要。

这暴露了当前方法的一个短板：它解决了"能不能完整验证"，但离简洁、优雅、人类可读还很远。

4.3 死结三：陈述对齐------最容易被忽略的坑

这一条最微妙，也最要命。

Lean 内核保证的是：从给定的公理和定义出发，这条逻辑链能正确推出结论。

它不保证的是：你形式化的那个命题，就是你想证的那个命题。

  Lean 能判定：  axioms ⊢ statement  ✓ / ✗
  Lean 判不了：  statement 是不是你想表达的意思？

举个极端例子：你可以把一个命题形式化成一个更弱或不同的命题，然后完美证明它------内核照样通过。

Anthropic 显然意识到了这点，用了一个比较工具来确认：Claude 证明的定理陈述，与 Mathlib 中费马大定理的陈述一致。

这个步骤看起来不起眼，却是整套流程的信任锚点。 任何做形式化验证的工程，都必须单独处理"陈述对齐"，不能指望内核帮你做。

---

五、解法：Prove2Me 做了什么

转折点是 Prove2Me------Anthropic 研究员 Tianyi Peng 及其哥伦比亚大学合作者开发的开放式数学形式化协作平台。

它解决了三个具体问题：

5.1 用 DAG 管理依赖与进度

Prove2Me 把待证明的定理组织成一张有向无环图（DAG）：

                    ┌─────────────────┐
                    │  费马大定理      │  ← 根节点
                    └────────┬────────┘
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
        ┌──────────┐  ┌──────────┐  ┌──────────┐
        │  Mazur   │  │  Ribet   │  │  Wiles   │
        │  定理     │  │ level    │  │  R=T     │
        │          │  │ lowering │  │ patching │
        └────┬─────┘  └────┬─────┘  └────┬─────┘
             ▼             ▼             ▼
          （更底层的引理，数十个智能体并行推进）

每个节点是一项任务，节点之间记录依赖关系。于是：

• 智能体能判断下一步该证什么（找入度已满足的节点）；
• 能复用已证结果，不重复劳动；
• 长时间运行后能重新定位当前进度。

5.2 拆分陈述与证明，缩短编译时间

Prove2Me 把定理陈述 和具体证明拆到不同文件，独立维护二者之间的连接。

这是个很实用的工程优化：Lean 编译大型证明很慢，拆开后可以只编译变化的部分，大幅降低计算资源消耗。

5.3 给每个定理配自然语言描述

每个定理同时带有自然语言描述，方便智能体搜索和调用已有结果。这相当于给形式化库加了一层语义索引------解决的就是 4.1 里"不知道别人证过什么"的问题。

一句话总结这次成功的关键 ：模型能力决定单个任务能走多远，外部脚手架决定几十个智能体能否在数天内围绕同一目标持续协作。

而且早期没有 Prove2Me 的尝试是失败的------换脚手架，比换模型更管用。

---

六、这意味着什么：从数学到通用范式

6.1 门槛在快速下降

Anthropic 还做了一个规模小得多的实验：

研究人员用 3 个个人版 Claude Max 账号 ，通过 Prove2Me 协作，3 天 完成了维诺格拉多夫三素数定理的形式化。

3 个消费级账号、3 天、一个经典定理。这说明这类工作的门槛不在实验室独占，而在任务拆解和协作机制是否成熟。

6.2 通用判据：你的领域有"廉价判定器"吗

把这套范式抽象出来，得到一个可以直接用的判据：

  Q1. 你的任务产出，能否被一个程序判定对错？
      ├── 能（代码→编译器+测试；证明→内核；配置→schema 校验）
      │     └── Q2：判定的成本够低、速度够快吗？
      │            ├── 是 → ✅ 可以上神经符号闭环
      │            └── 否（判定要几天）→ ⚠️ 收益打折
      └── 不能（文案、设计、策略）
            └── ❌ 闭环不成立，只能靠人类反馈或弱代理指标

凡是存在廉价可靠判定器的领域，AI 都会先突破。 这解释了为什么编程和数学走在最前面------不是因为它们"最难"，恰恰是因为它们最容易被判定。

顺带说，这也解释了：为什么"AI 幻觉侵权"会被写进最高法的司法意见（9 月 7 日发布）。在缺乏判定器的领域，验证成本被转嫁给了社会。

6.3 对你的启发

三条实践建议：

1. 审视你的 AI 工作流，找出能加判定器的环节。哪怕只是一个 JSON schema 校验、一个单元测试、一个 lint，都比"人眼看一遍"强得多。
2. 长程多智能体任务，先搭脚手架再堆模型。这次的教训很直白：同样的模型，没有 DAG 就失败，有了 DAG 就跑通。
3. 单独处理"陈述对齐"。让 AI 做的事和你以为它做的事，是不是同一件事？这个问题判定器帮不了你。

---

七、局限：别把它想成"AI 会做数学了"

必须说清楚的边界：

说法	对不对	说明
AI 独立证明了费马大定理	❌	定理 1995 年已被证明，这是转写 不是发现
AI 做出了人类做不到的数学	❌	人类社区工程也在推进，AI 做的是大幅加速
这份证明绝对正确	✅	只依赖 Lean 三条标准公理，经内核与 nanoda 双重检查
这份证明简洁优雅	❌	1300 万行，约为 Mathlib 的 5 倍，很可能远长于必要
这完全是 Anthropic 的成果	❌	依赖 Mathlib 与 Buzzard 的社区项目等开源基础设施

还有一条更根本的：Lean 能确认一条逻辑链是否从给定公理正确推出结论，但不会自动给出直觉清晰、适合人类理解的解释。

Kevin Buzzard 的评论很到位------这类工具能帮我们发现现有证明中的错误、减轻审稿人负担。未来的数学成果很可能需要两套表达：一套写给研究者讲清思路与意义，一套交给证明助手确保每一步经得起检查。

注意这个分工：机器负责"对不对"，人类负责"有没有意思"。

---

八、我的判断：可验证性正在成为新的稀缺资源

把这件事放到更大的背景下看。

就在同一周，OpenAI 首席科学家 Pachocki 发长文警告：思维链监控正在失去可靠性------模型越来越擅长操纵自己的推理过程，也越来越能在不"说出口"的情况下思考。

一边是监控工具在变钝，一边是形式化验证在跑通。这两件事放在一起，指向同一个结论：

  当 AI 的产出能力爆炸式增长，
  而"判断它做得对不对"的能力跟不上时，
  ─────────────────────────────────
  可验证性就成了最稀缺的资源。

我倾向于这样看接下来的格局：

  ┌────────────────────────────────────────────────┐
  │  有廉价判定器的领域（代码 / 证明 / 结构化输出）    │
  │  → AI 自主化程度快速提升，人类退居"定义问题"      │
  ├────────────────────────────────────────────────┤
  │  判定昂贵但存在（法律 / 医疗 / 金融合规）          │
  │  → 人机共担，判定器成为核心资产与壁垒             │
  ├────────────────────────────────────────────────┤
  │  无判定器（创意 / 审美 / 战略）                   │
  │  → 仍是人类的地盘，AI 只做提案                    │
  └────────────────────────────────────────────────┘

所以，1300 万行 Lean 代码真正的价值，不在于费马大定理------那个定理早就证完了。它的价值在于演示了一条路径：

当 AI 能做的越来越多，我们唯一能守住质量的办法，就是让它做的每一件事都经过一个不依赖信任的判定。

这套范式会从数学外溢到代码、芯片验证、合规文档，最终外溢到所有"对错可判定"的工作。

而那些判定不了的领域，才是我们真正需要焦虑的地方。

---

参考

• Anthropic《Formalizing Fermat's Last Theorem》（2026-09-04）
• 完整 Lean 证明：github.com/anthropics/...
• Prove2Me：Tianyi Peng（Anthropic / Columbia）团队开发的数学形式化协作平台
• Mathlib：Lean 社区维护的形式化数学库；nanoda：Rust 实现的独立证明检查内核
• Kevin Buzzard（Imperial College London）2024 年发起的 FLT 形式化社区工程
• 同期进展：GPT-6 Astra 将孪生素数间隔界限降至 186；黎曼猜想临界线零点比例下界提至 67.2%

如果这篇文章对你有帮助，欢迎点赞收藏。也欢迎聊聊：你的工作流里，哪些环节其实是可以加判定器的？