Claude 完成了什么
费马大定理在 1995 年由 Andrew Wiles 用数百页分析完成非形式化证明，其核心依赖现代代数几何的深层工具。将这样一个证明完整写入 Lean 这样的交互定理证明器，是一项长期挑战——过去几年，Lean 社区已陆续形式化了部分中间结果，例如 Galois 表示理论和模性提升定理的核心引理。
Claude 这次的贡献在于：它不再只是补充某个引理的证明片段，而是从一个完整的命题出发，自主生成了从公理到结论的端到端 Lean 代码，并通过 Lean 内核的类型检查。
Buzzard 在评论中明确指出，这一结果意味着「如果费马大定理的形式化现在可行，我们已向自动形式化整个现代数学文献迈出了一大步」。这句话的分量需要谨慎理解——它描述的是方向性判断，而不是对全量文献覆盖的能力承诺。
费马大定理与形式化证明的背景
形式化证明要求每一步推理都对应 Lean 中的显式推导步骤。Wiles 原始证明中的许多论证是分析性的、依赖直觉跳跃的；要把它们翻译到依赖范畴论和上同调语法的 Lean 世界，本身就需要同样深度的数学理解。
过去多年，这一翻译工作主要由人类研究者主导，典型的里程碑是 Keller 等人推进的部分模性提升形式化项目。Claude 这次的任务与前人工作的本质区别是：输入只有一个命题陈述，没有其他形式化材料的引导，系统需要在长程推理中自行检索和组装需要的公理与引理。
这次结果的「首个」含义
严格地说，这是首次由 AI 系统在几乎无人类干预的前提下完成一个重大定理的端到端形式化。此前类似探索多集中在较短命题、受约束的证明策略搜索或辅助验证环节。本次的跨度——从命题到通过内核检查的完整证明文档——构成了实质性的阶段跃迁。
连续推理 11 天的资源消耗
Claude 形式化任务执行流程
##Claude完成了什么费马大
技术路径：从提示到 Lean 证明
Lean 本身是一个基于类型理论的证明助手，其核心价值在于提供一个可机械验证的逻辑框架。Claude 要完成这件事，需要同时解决三个层面的问题：理解数学对象、生成符合 Lean 语法的证明项、并在反复调试中收敛到正确结构。
Lean 的证明过程可以看作在依赖类型体系里「构造」一个类型化的证明项。Claude 生成的不是自然语言描述，而是可以直接被 Lean 内核编译和检查的代码。每一次 theorem 声明、每一条 have、每一个 apply 都需要通过严格语法约束。
Lean 形式化系统的角色
Lean 4 引入的效率改进和数学库 Mathlib 的持续扩展，为本实验提供了基础设施。Mathlib 目前收录了足够多的现代代数几何基础引理，Claude 能够在推理过程中逐步引用这些已有成果。然而，引用不等于证明——当 Claude 调用某个引理时，仍需确认其前置条件在当前上下文中全部满足。
Claude 的推理架构
根据 Anthropic 在相关研究中的描述，Claude Code 系列工具在复杂任务中引入了规划-执行-验证循环。对于这种长程数学推理，关键机制包括：将大目标拆解为可验证的子命题；在每次尝试后根据错误反馈重新定位缺失环节；以及维持跨小时的上下文一致性。
这类架构与之前 Anthropic 发布的 Boltzmann 求解器等科学计算任务的架构形成对照——前者是深度耦合链式任务，需要单 agent 持续追踪因果；后者是大规模并行任务，可由多 agent 分工。费马大定理属于前者。
[[reaction=backend-system-design|caption=长程推理系统的核心设计]]
长程数学推理的系统设计
端到端的关键差异
端到端在这里有两层含义：输入端只有命题陈述，没有人工提供的证明路径提示；输出端通过 Lean 内核检查，证明完整性有机器保证，不需要人类逐行复核逻辑链。
这与此前大量 AI+数学的工作有本质区别。那些工作大多停留在「找到证明思路」或「验证给定证明的正确性」层面，而本次任务同时覆盖了两个环节。
##技术路径：从提示到Lean证
为什么这件事重要
这一结果的直接意义不在于费马大定理本身——该定理已有完整的人类证明，数学共同体并不缺乏它的证明路径。真正值得关注的是能力边界的拓展：AI 系统正在从单点推理工具向能处理长程、结构化任务的 agent 演进。
对数学共同体的意义
形式化验证的最大痛点是人力成本极高。每位研究者在推进工作时，都要权衡「是否值得投入时间把证明写入 Lean」。Claude 这类系统若能稳定复现，将显著降低这项门槛，让更多已有证明能够进入机器可验证的轨道。
但这不意味着人类数学家会被替代。形式化过程仍然需要精确的数学直觉——选择哪些引理、如何组织证明结构、在哪个节点做关键分解——这些决策现在仍是人与机器的协作，而不是单向输出。
对 AI 推理能力的信号
从基准测试视角看，这一结果对应着 SWE-bench Pro 类任务中的最高难度档位：长周期、多步骤、强依赖领域知识。Claude 在此类任务上的表现改善，与其训练数据中引入的对齐数据质量提升直接相关。
需要警惕过度解读
值得明确指出当前的边界条件：Anthropic 并未公布完整实现细节，我们不清楚 Claude 在这 11 天中调用了多少次工具、消耗了多少 token、经历了多少次失败重试。因此，不宜将此次结果泛化为「任何数学定理都能在 11 天内完成形式化」。这个能力目前仅限于特定类型的问题，且高度依赖现有库的覆盖范围和任务的内在复杂度。
局限与边界
这次任务的成功建立在几个关键前提上：Mathlib 已覆盖足够的代数几何基础；费马大定理的中间结果已被部分形式化；任务环境提供了稳定的计算资源和错误反馈机制。
11 天的代价
11 天是一个不可忽视的时间成本。其中大部分时间消耗在试错和纠错上——Lean 的内核检查极其严格，一个小小的类型不匹配就可能让整条证明链中断，需要回溯定位。
当前能力的可复现范围
目前可见的模式是：任务越接近已有形式化成果，成功率越高；任务越依赖全新的数学构造，系统越容易陷入局部死循环。这是一个梯度，而不是二分。
对于仍在观望的团队，一个务实的判断是：将这类系统定位为「强辅助工具」而非「替代研究者」。它的价值在已有丰富形式化基础的领域中最大——帮助填补碎片化的证明片段，而不是从零开始发明新理论。
下一步的可行方向包括：评估 Mathlib 在你所在领域的覆盖密度；在小规模子问题上建立自动化流程；以及将 AI 生成的草稿纳入人工审校的正式工作流。这三件事中，第一件事最值得今天就做。
这不是一个轻松的任务。费马大定理的证明跨度超过 100 页，涉及椭圆曲线、模形式、几何表示论等高度专业化的数学领域。Andrew Wiles 在 1994 年完成原始证明后，数学界花了数年进行验证。如今 Claude 在不到两周的时间内完成了形式化版本，关键在于它没有依赖人类预先拆解好的步骤。
形式化证明是什么
形式化证明的核心诉求是消除模糊性。数学论文中的每一步推导都可能存在隐含假设、跳步或约定俗成的表述。形式化系统要求每个推理步骤都符合严格的逻辑规则，并能由程序验证。
Lean 是这一领域的代表系统之一。它基于依赖类型理论，将数学对象编码为类型，将证明编码为具有特定类型的项。一个证明是否正确，等价于一个表达式是否具有预期的类型——这是编译器可以检查的事情，不需要数学家参与。
形式化证明的日常
Lean 的学习曲线非常陡峭。数学家需要掌握一种全新的思维方式，将直觉转化为精确的构造。Kevin Buzzard 等研究者多年来一直在推动数学文献的形式化工作，但进度始终有限。Claude 的介入改变了这个动态。
Lean 的底层逻辑
Lean 3 与 Lean 4 存在显著差异。Lean 3 使用 Tactic 语言进行交互式证明，而 Lean 4 引入了更大的架构改进，包括改进的元编程能力和更稳定的性能。
Anthropic 的研究团队选择了 Lean 4 作为目标系统。这本身就体现了工程判断——旧系统虽然生态成熟，但新系统在自动化友好度上更有潜力。
证明过程中的核心挑战在于定理的分解。费马大定理的形式化版本需要调用多个大型库中的引理，包括代数几何、数论、表示论等领域。Claude 不能凭空造出这些概念，它需要从已有的形式化知识库中检索并组合。
从自然语言到类型理论的鸿沟
这里有一个容易被忽视的难题：数学家的自然语言描述与 Lean 的类型系统之间存在巨大鸿沟。
「对于任意大于 2 的正整数 n，方程 x^n + y^n = z^n 没有正整数解。」这句话在自然语言中清晰明了，但在 Lean 中需要逐一定义正整数、幂运算、方程、解的存在性等多个概念，并确保所有符号的含义一致。
Claude 的任务不是理解费马大定理的数学内容，而是理解如何用 Lean 的语言重新表达它，并找到或构造出相应的证明路径。这是一个翻译问题，更准确地说，是一个将高层语义映射到低层形式系统的问题。
Claude 做对了什么
传统的 AI 解题系统通常采用单步推理模式：输入问题，输出答案。这种模式在处理复杂任务时存在根本性缺陷——它无法维持长期目标，也无法在失败后进行系统性调整。
Claude 在这次任务中展现的能力更接近工程实践中的 agent 模式。它需要在 11 天内持续工作，管理大量中间状态，处理失败并重试，最终产出可通过 Lean 编译器验证的结果。
Agent 长时间运行的真实状态
长期规划与状态管理
11 天的自主运行意味着 Claude 需要进行多轮迭代。每一轮可能产生新的引理、修改已有的证明结构、或者推翻某些假设重新开始。
关键机制在于上下文窗口的管理。Lean 的形式化证明往往包含大量上下文信息——已证明的引理、定义的变量、引入的假设。如果这些状态无法正确维护，后续的推理步骤就会建立在不稳固的基础之上。
Anthropic 的研究报告提到，他们调整了后训练数据的质量，特别关注了对齐数据中的「原因」而非仅仅是「行动」。这意味着 Claude 不仅仅学会了「什么时候该调用哪个 Lean tactic」，而是理解了「为什么在这个阶段需要这个步骤」。这种差异在长期任务中尤为关键。
Claude 形式化证明迭代流程
工具链与上下文约束
Claude 并非孤立工作。它依赖于一套完整的工具链：Lean 编译器、数学库、以及用于错误诊断的反馈机制。
当 Lean 编译器报错时，错误信息通常是类型不匹配或 tactic 无法应用等技术细节。Claude 需要能够解读这些信息，并将其转化为可执行的修正动作。这需要模型具备两个能力：理解 Lean 的类型系统，以及理解数学证明的语义意图。
Anthropic 没有公开完整的实现细节，但从现有信息可以推断，他们在 Prompt 设计、ReAct 模式的实现、以及错误处理的边界条件上做了大量工程工作。
这不是第一次，但这次不同
在 Claude 之前，已经有多个团队尝试让 AI 完成数学证明的形式化工作。Google DeepMind 的 Gaoth、Meta 的 ProofWriter、以及 OpenAI 早期的 GPT-4 实验，都曾尝试在特定领域取得进展。
但这些工作的共同局限在于：它们要么依赖人类预先标注的步骤，要么只能在非常有限的子问题上工作。没有人能够在没有大量人工干预的情况下，从问题陈述直接推进到完整的、可通过编译检查的形式化证明。
数学家对结果的认可
过往尝试的失败教训
失败的主要原因可以归结为三点：
第一，上下文管理不足。当证明步骤超过一定长度后，早期的模型会丢失关键的假设信息，导致后续推理建立在不正确的 premises 之上。
第二，错误恢复能力弱。一旦某个步骤失败，系统往往无法回溯到正确的分支点，只能从头开始或停留在错误的状态。
第三，工具使用不连贯。数学证明需要多次切换不同的 tactic 和策略，早期的系统难以维持这种切换的一致性和连贯性。
端到端的真实含义
Anthropic 强调「端到端」这个词是有原因的。在他们之前的工作中，人类通常需要介入以下环节：
- 将数学定理拆分为多个子目标
- 为 AI 提供可用的引理列表
- 在关键步骤进行人工指导
- 调试和修复 Lean 编译错误
这次 Claude 的工作量减少了以上所有的人工介入。模型自己完成了定理分解、引理检索、证明构造、错误修复的完整循环。这不代表 AI 已经完全理解了数学，但它证明了系统在复杂、长期、需要状态管理的任务上已经达到可用水平。
工程师该如何看待
这个结果不应被简单解读为「AI 已经可以替代数学家」。形式化证明的本质是验证，而非发现。Claude 完成的是将已有的数学知识转化为形式化语言的工作，而不是创造新的数学理论。
工程师面对新工具时的真实心态
但即便如此，这项工作的工程价值不容忽视。它展示了 AI 在处理长期、复杂、需要多轮迭代的任务时的能力边界。这种能力可以直接迁移到软件工程的其他场景。
适用的边界条件
当前模型的表现依赖于几个关键条件：
第一，问题空间必须有限且定义清晰。费马大定理的证明路径已经被数学界充分探索，Lean 社区也已经积累了大量可复用的形式化知识。如果换一个全新的、没有现成库支持的领域，结果可能完全不同。
第二，错误反馈必须可机器可读。Lean 编译器的错误信息格式规范，可以被模型解析。如果换成其他形式化系统，或者人工 review 的流程，效果会大打折扣。
第三，任务时间窗口在合理范围内。11 天对于 Claude 来说可能需要数十亿 token 的推理成本。如果任务周期延长到数月，当前的技术栈可能无法承受。
下一步值得关注的信号
有几个指标可以帮助判断这项技术的成熟度：
首先是可重复性。单个成功案例可能是偶然的，但如果在多个数学领域（如代数拓扑、同调代数）都能复现类似结果，则表明模型具备通用能力。
其次是成本曲线。如果完成同等任务的 token 消耗量持续下降，说明工程优化正在生效，应用门槛也在降低。
最后是工具生态。Lean 社区是否会因为 Claude 的介入而加速形式化建设，将决定这项技术能否产生实质性影响。
AI 形式化能力适用边界
对工程师而言，真正值得关注的不是 Claude 能不能证明费马大定理，而是这种能力何时能迁移到日常的代码审查、系统设计文档生成、以及测试用例的自动生成上。数学证明是形式化系统的一个极端案例，但背后的工程逻辑是通用的：当模型能够在长期任务中维持状态、处理失败、并完成多步骤的复杂推理时，它就已经具备了替代许多传统自动化脚本的能力。
跨越从定理到文献的最后一公里
Buzzard 在评论中指出，这并非只是又一个定理的形式化完成，而是迈出了系统性形式化现代数学文献的重要一步。费马大定理的证明链条涉及代数几何、数论等多个子领域，包含引理和命题之间复杂的依赖关系，对 AI 来说，能够自主跟踪这些依赖、在出现错误时回溯并修正策略，这本身就是对长期规划和状态管理能力的检验。
证明依赖关系像侦探追踪线索
Claude 形式化证明工作流
从里程碑到可复制路径
11 天的自主运行背后，是状态管理架构的实际验证。形式化证明过程中的变量定义、引理引用、子目标跟踪，都需要精确的状态记录与恢复能力。Claude 在这一过程中展现了持续的上下文管理能力——不是在单次对话中完成任务，而是在连续多日的交互中维持对证明全局的理解。
对于数学研究团队而言，这件事的可执行落点并不复杂。第一，关注 Lean 社区的 Mathlib 更新，了解哪些经典定理已被形式化，哪些仍是空白；第二，评估自身研究领域中是否有适合拆解为小引理的问题，可以用 Claude 作为辅助工具进行形式化探索，不必一开始就瞄准宏大定理；第三，建立人对 AI 的复审机制，AI 生成的证明草稿需要经过人工审查后才能投入正式使用。
技术路径清晰可见，但距离「自动形式化整本教材」仍有距离。当前成果的核心价值在于证明了这条路径可行，而非证明这条路已经平坦。
参考文献
[1] Teaching Claude why - Anthropic. www.anthropic.com/research/te… [2] Anthropic Courses. anthropic.skilljar.com [3] CLAUDE CODE ADVANCED FULL COURSE (3 HOURS). www.youtube.com/watch?v=UPt… [4] Anthropic Says Claude Autonomously Formalized Fermat's Last .... aiweekly.co/alerts/anth… [5] Long-running Claude for scientific computing - Anthropic. www.anthropic.com/research/lo… [6] Claude Code Training | SFEIR Institute. institute.sfeir.com/en/claude-c… [7] Anthropic 2026: Every Claude Model, Agent & Tool. linas.substack.com/p/anthropic… [8] Medium. medium.com/@cyriaczeh/…
