这大概是最近两代数学人和大模型研究者圈子里唯一一条能同时让人愣住的新闻Anthropic 宣布Claude 花 11 天时间端到端地完成了费马大定理的形式化证明。先给不常刷飞书的读者翻译一下这句话的分量。费马大定理要追溯到 1637 年费马在书边空白处写下的那句我已发现一个绝妙的证明但空白太小写不下。这个猜想困扰了人类三百多年一直到 1994 年安德鲁·怀尔斯才用上了当时最前沿的椭圆曲线理论写出了上百页的证明而且第一步就依赖后来被证明成立的“谷山-志村-韦伊猜想”。这个证明本身已经足够复杂复杂到数学界花了多年时间消化它。而“形式化证明”则是另一件完全不同的事情把人类书写的、依赖直觉和语言逻辑的文字证明翻译成一台计算机能逐行验证的、严格机械化的证明。Claude 用 11 天把这两件“难上加难”的事同时做完了就是这次新闻的核心信息。很多人第一反应是“AI 能证费马大定理了数学家是不是要失业”也有人第一反应是“这不会是又一篇营销通稿吧”。作为一个既配过 Claude Code、也研究过 Lean 形式化验证的在座工程师我想认真聊一聊这次事件背后真正值得关注的东西端到端意味着什么Claude 的工作流到底有多颠覆以及如果我们也想踩进这个坑现实里会遇到哪些问题。1. 先搞清楚三件事费马大定理、形式化证明、端到端1.1 费马大定理为什么是数学史上最难啃的骨头之一费马大定理本身一句话就能说清当 n 大于等于 3 时方程 a^n b^n c^n 没有正整数解。但这句话背后的证明难度很多人低估了。一个关键原因在于费马抛出这个断言之后的三百多年里无数数学家证明了 n3、n5、n7 甚至一系列特殊指数的情况但对一般情形毫无办法。怀尔斯在 1994 年的突破不是说“我找到了一条通解”而是把费马大定理整体归约到了“所有半稳定椭圆曲线都是模的”这个模块化命题上再利用岩泽理论和变形环理论等工具完成了证明。整个证明链路之长导致后来的数学家们花了相当长的时间才逐步确认其中没有逻辑漏洞。所以费马大定理不是一个“难但可以硬算”的问题。它是一个需要新数学工具、新理论框架、跨多个分支联动才能解决的问题。任何一个试图证明它的形式化体系必然要面对无数层层嵌套的定义、引理、定理传播这是理解 Claude 这次成果的第一个前提它不是做一个竞赛题而是在一个高度抽象的巨型数学大厦里干活。1.2 形式化证明让数学从“说服人”变成“不骗电脑”形式化证明简单说就是把人能看懂的证明写成计算机能验算的证明。这事听起来像“写严格一点就行”但实际上比想象中变态得多。我举个接地气的例子。你高中证明过“三角形内角和等于 180 度”吧很多证明其实是依赖图形的直觉——把一条线延长一下画个平行线用眼睛看出来角度相等。但计算机没有视觉也没有直觉。你告诉它一个三角形它只会按图索骥地问你“你说这两条线平行请给出公理层级的依据”“你说这两个角相等请给出引用的是哪条定理”。在 Lean、Coq 这类证明助手里每一个看似显然的结论都要推进到由精确的类型定义、构造函数、归纳规则构成的形式证明树。也因为这种苛刻人类把怀尔斯证明形式化是一个漫长工程。我印象里早有团队在推进做费马大定理的形式化那是一个庞大的、以年计的工程。哪怕这些团队已经做完了很多基础铺垫真正的形式化工作依旧极耗精力。这也是为什么“Claude 11 天完成端到端形式化证明”会让数学家群体感到冲击力。1.3 端到端到底改了什么“端到端”这个词最近在 AI 圈已经快被用烂了但放在数学证明里必须重新解释。在 Claude 之前AI 参与数学证明的主流模式是“人机协作”AI 负责猜测证明思路、补全局部引理人类负责盯住整体方向把各种片段拼起来再逐行推进。这种模式里AI 更像一个超级计算器或者辅助论证工具工作流的掌控权在人手里。而这次“端到端”的意思是从输入问题本身到输出可验证的完整证明文件整个过程中没有人工逐步把关。Claude 自己去探索中间引理、自己决定证明顺序、自己调用 Lean 验证器做反馈失败了自己再换思路最后交出一个通过了机械化验证的完整证明产物。听起来是不是像一个“数学研究 agent”这在工程上是个巨大的边界移动。不是说 AI 从此能独立发现费马大定理这种级别的数学成果但至少在“形式化验证”这个环节AI 第一次做到了最短路径上的闭环。2. 核心细节拆解Claude 11 天证明里隐藏的技术逻辑2.1 它不是凭空算出来的而是站在证明助手生态的肩膀上要理解 Claude 这次做的事必须先知道 Lean 证明了什么位置。Claude 用到的证明助手 Lean 4 背后已经存在大量被人类数学家和工程师逐行验证过的库包括数学库 mathlib里面沉淀了几十万个定理和定义。换一种描述Claude 不是从字面意义上“发明”了费马大定理的证明而是通过调用这些已经机械化的数学碎片搜索、拼接、验证出了一条完整的前端到后端的证明路径。这个过程的难度依然非常高因为库里的定理不会自动告诉你该怎么组合。在每一层抽象之间选择正确的构造、主动去证明那些库还没覆盖的引理、找到隐藏在文档深处的适用的已有结论这套搜索能力正是 Claude 的强化点。对做过程序的的人来说好懂一点你相当于用一台安装了上百个开源依赖的开发机去从零撸一个大型系统。源代码都在但没有人告诉你架构应该怎么设计、哪些包可用你必须自己一边查文档一边试验直到编译通过。而 Claude 不只是“编译通过”它把这个开发动作严格限制在“数学证明必须逐条机械验证”的规矩里——任何一点偷懒都会导致证明验证失败无从作弊。2.2 一次推理不够关键在“搜索 验证”反馈循环Claude 能做到 11 天跑通端到端我不认为这是靠“单次大模型推理能力爆炸”实现的。更合理的拆解是它在那个持续运行的环境中执行了无数轮的“生成候选证明片段 → 采用 Lean 验证 → 返回错误信息 → 重新修改”循环。换成人脑的比喻这更像一个刻苦的研究生每天写几十页草稿自己用逻辑推演和同行检验去核查错了就回去改。区别在于Claude 的验证器反馈是以机器的严格度进行的速度上也许能以天为单位跑完上百轮迭代。所以这条 11 天的时间线意味深长它不是一个 LLM 单次生成的问题而是一个 agent 持续工作的时长。按照 Anthropic 公布的叙事这个 agent 需要长时间维护状态、跨会话保存进展、规划整体证明路径不断在抽象概念之间跳跃。这种“长时间运行 自我反馈 上下文维护”的模式才是真正贴近未来可落地的 AI 科研助手形态的东西。2.3 对比人类形式化的时间成本你就明白这有多惊人把费马大定理形式化这件事人类团队通常用什么时间尺度来衡量我从已知的公开项目里了解到人类数学团队完成一个大型定理的形式化往往以年为单位。哪怕是已经有大量现成库支撑的分支领域一个中等复杂程度的定理形式化一两个月也不算夸张。把费马大定理这样量级的证明在 11 天内从草稿推进到端到端形式化即使有前人在 mathlib 里的积累打底也是一个人类团队很难企及的速度。速度差异的来源不是人类不会搜索、不会拼接而是人类的注意力、体力和持续工作能力是有限的。Claude 可以 24 小时不停不歇地尝试同一条死路的一百种变形人做不到。这个时间的压缩说明“AI 做形式化数学”已经从理论可行性走到了效率和成本都具备真实竞争力的阶段。3. 实操视角如果我想跑通一个“AI 形式化证明”的工作流该怎么准备3.1 工具链选型和环境准备看完新闻很多人会好奇“我自己能用 Claude 干点类似的事吗”。先说结论你大概率不会真的去复现费马大定理但你完全可以搭建一个“数学证明 agent 工作台”让 Claude 帮你验证一条小定理这也是很值得做的体验。工具链上需要准备几块Lean 4 及配套的 mathlib这是形式化证明的核心环境。Claude或者 Claude Code承担策略生成和代码生成任务。一个能够持续运行脚本的服务环境我建议直接在本地终端跑配好 Claude Code 后让它长驻。版本管理工具比如 Gitagent 跑长任务时随时保存证明进度避免上下文丢失后一切归零。安装 Lean 4 一般用 elan 这个工具管理器然后拉取 mathlib 缓存过程不算复杂。真正麻烦的是环境变量的配置和网络访问稍后我会细讲踩坑。3.2 最小可行流程让 Claude 帮我在 Lean 里证明一个小引理为了让不熟悉的朋友有概念我给一个最朴素的流程示例。假设我们要让 Claude 证明一个简单命题“自然数加法是交换的”的某个特定实例或者更简单一点证明 “forall n : Nat, n 0 n”。预设环境变量后我启动 Claude Code给它一段系统指令你是 Lean 专家请使用 Lean 4 完成以下定理的证明每次写完一部分请运行 lean /path/to/file.lean 检查如果报错根据报错信息继续修改不要跳过验证步骤。然后我可以把 Lean 文件放到工作目录让 Claude 尝试填补证明。它第一步通常是导入 Mathlib声明 theorem然后尝试穷举归纳法等。执行过程很有意思Claude 生成的第一个版本大概率会报错比如它可能会写simp策略但遇到未覆盖的引理时Lean 会提示“简化器无法推进目标”。这时 Claude 看到错误反馈后会主动去library_search或omega等战术库里面找对应工具然后接着验证直到编译器无差错通过。这就是最小闭环生成 - 执行 - 读错误 - 修复 - 再执行。3.3 在 Claude Code 里配置 Lean 数学模式的通用做法如果你想做更Freestyle的尝试我建议在 Claude Code 里写一个CLAUDE.md或者项目说明文件把约束写清楚所有证明必须使用 Lean 4 的 mathlib。每次修改后用lake build或lean命令行编译检查。禁止在未验证的情况下以“我猜应该没问题”结束。如果一个引理反复失败超过三次先分解成更小的子目标。这些看起来朴素但极大改善 agent 的长任务稳定性。大多数人在 AI 写数学证明过程中遇到的翻车不是模型能力不够而是“没有给它错误反馈的入口”。让它能够持续接收编译器的报错就是给它装上了导航仪。4. 现实中的坑安装、连接、403 与模型路由问题实录4.1 Claude Code 安装时的典型报错与修复如果你想真正在本地把一套类似工作流跑起来遇到的第一个门槛往往是 Claude Code 的安装问题。很多人装上后用不了最常见的就是报错claude : 无法将“claude”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这个错误在 Windows PowerShell 下最常见几乎都是 PATH 环境变量没有配置好。npm 安装的全局包有时候会装到一个自定义路径下如果你之前装过 Node 的多版本管理器路径可能会乱。解决方法是找到claude或claude.cmd的实际路径手动加到 PATH 里然后重新打开终端。另外有人会遇到error: claude native binary not installed. either postinstall did not run这种情况通常是 npm 安装过程中 postinstall 脚本没有执行成功常见原因是使用 cnpm/pnpm 等替代包管理器或者公司的 npm registry 挡住了二进制下载。可以尝试删除 npm 缓存改用官方源或者重新执行安装命令让 postinstall 脚本重新跑一遍。4.2 “Unable to connect to Anthropic Services”和 403 的真正排查思路热词里频繁出现的unable to connect to anthropic services或status 403我自己也遇过而且这类报错往往让新手特别崩溃。这里要区分清楚403 和连接超时是完全不同的故障点。连接超时一般是网络链路层面的问题请求根本没有到达服务端DNS 解析、TLS 握手还是中间网络封锁都可能导致。403 Forbidden 则说明请求已经到达了服务端但服务端拒绝响应——最常见的原因是 API key 没有权限、账户余额不足、区域受限或者并发超额。有些人第一反应是“换一个代理”或者“换个工具”其实很多情况下换个 API key、检查配额就能解决。排查时按这个顺序来检查 API key 是否配置正确有没有多余空格。检查账户是否还有余额、额度是否有效。确认你使用的地址是官方文档给出的标准 endpoint。如果还不行找一个支持 Anthropic 协议的服务商切换测试看是不是账户问题。最后检查网络出口。注意不同网络环境对 Anthropic 服务的连通性不一样如果想在本地稳定使用请确保当前网络能正常访问该服务不要让公司或机构的防火墙策略成为隐藏变量。4.3 把 Claude Code 路由到 DeepSeek 或硅基流动模型的方法有很多朋友关心如何把 Claude Code 接到 DeepSeek 或者硅基流动这类第三方模型服务上。因为这类模型网关要么便宜体验好要么更适配本地需求是不少团队已经在用的省钱方案。配置逻辑其实很简单Claude Code 本质是一个支持 Anthropic 协议的客户端它通过环境变量指定 base_url 和认证 token。以接入 DeepSeek 为例你可以在环境中设置export ANTHROPIC_BASE_URLhttps://api.deepseek.com/anthropic export ANTHROPIC_AUTH_TOKEN你的DeepSeek_API_Key export ANTHROPIC_MODELdeepseek-chat这样启动claude时它就会把请求发送到 DeepSeek 的 Anthropic 兼容接口上。硅基流动的配置方式类似把ANTHROPIC_BASE_URL指向它的兼容端点再设置好对应的模型名和 token 即可。这种方法不需要修改客户端代码只是把内部协议互相兼容的模型接到 Claude Code 的命令行界面里。好处是留住了 Claude Code 的交互体验坏处是第三方模型的推理能力和工具调用质量差异很大如果任务很复杂建议还是切回官方 Claude 模型。我用过一段时间这类第三方路由方案最深的感触是省钱是省钱的但 Cocoa 里那些需要长时间上下文维护的任务第三方模型的稳定性明显还是差一口气。你要证明一个复杂定理时中途上下文忘了路径会让整个 agent 变成无头苍蝇。所以大任务我还是老老实实用官方服务小任务才考虑路由到便宜的第三方模型。4.4 VS Code 和桌面版的配置心得关于在 VS Code 里使用 Claude Code社区里常见的问题是最开始找不到对话记录。Claude Code 是一个终端工具你在 VS Code 的终端里启动它时它默认把工作状态放在项目目录下。如果你直接在 VS Code 里关闭窗口而没有正确保存或者退出会话下一次打开后会话历史可能不在当前这个终端上下文里就会让人感觉“对话怎么没了”。解决策略很直白把 Claude Code 当作一个独立的命令行工具来用不要把它当成 VS Code 原生插件。规范做法是设置好会话存储路径或者显式使用续聊命令让上下文写盘最后恢复。如果用 Claude Desktop 桌面版注意它和 Claude Code 的会话记录是两套体系工具定位不同别混着找。5. 这件事对数学界和普通开发者的真正影响5.1 机器验证正在改变“论文有效”的定义以前一篇数学论文发表后审稿人需要花大量时间去检验逻辑。而形式化证明一旦普及论文能不能过很可能变成“你的证明文件能不能在 Lean 里跑完”。一种更强的数学交流范式逐渐清晰人类写下思路和直觉AI 帮助翻译成形式化证明机器负责终极验收。费马大定理这种级别的定理都能被 11 天端到端形式化说明大部分已经成熟的新数学分支都有机会逐步被搬进数学库里。这是数学知识库的资产积累长尾价值巨大。以后的新定理证明可以直接站在这种已验证的资产上构建整体正确性风险大幅下降。5.2 长期运行的 AI Agent 才是真正的科研形态这次新闻里最容易被人忽略的其实是“持续运行 11 天”这件事。传统基于 LLM 的数学解题往往停留在单轮对话内而这次 Agent 证明了长期记忆、跨会话规划、自主纠错这些能力对复杂科研任务的完成至关重要。所以对普通开发者的启发我认为更落地你要开始适应“AI 是员工而不是搜索引擎”这个新心智模型。给 Claude Code 一个目标、一套工具、一个反馈机制然后让它持续跑定期检查关键输出。费马大定理的形式化证明是这样跑出来的很多工程任务也一样能这样加速。5.3 注意事项不是所有证明都能交给 AI 自动完成话又说回来这次成果很容易被过度解读。目前我们能看到的成功路径还是建立在已有数学知识和证明助手库之上的搜索验证循环AI 并没有真的独立创造出跨越时代的全新数学方法。端到端形式化证明解决的是一个“把已有结构查漏补缺、打通闭环”的问题而“如何想到新的抽象结构”依然是当前 AI 最不擅长的事情。另外把复杂证明翻译成形式化语言依旧需要大量算力个人电脑是跑不动的。如果你准备玩类似的事情先把预算、API 配额、网络连通性想清楚再动手。不然跑了三天中途提示 403 或者配额耗尽前面的工作直接白费那才是最容易劝退人的现实。我个人在实际操作中最大的体会是Claude 这次 11 天证明的形式化工作流本质上是把“耐心”这一科研要素外包给了机器。以前人做大型形式化最大的掣肘就是太容易出错、太容易累、太容易失去信心。现在 AI 可以在没有情绪的前提下一秒一秒地从错误中爬起来。我们离“机器在数学上真正发表突破性成果”还有距离但离“机器成为数学证明的强势把关人”已经很近了。最后再分享一个小建议别只盯着论文级数学。打开 Lean挑一个小问题让 Claude Code 在你的项目里帮你形式化一遍。感受一下它从报错到验证通过的过程你会更懂这次新闻里真正让人头皮发麻的地方在哪里。
Claude 11天完成费马大定理形式化证明：AI数学推理与Lean工作流深度解析
这大概是最近两代数学人和大模型研究者圈子里唯一一条能同时让人愣住的新闻Anthropic 宣布Claude 花 11 天时间端到端地完成了费马大定理的形式化证明。先给不常刷飞书的读者翻译一下这句话的分量。费马大定理要追溯到 1637 年费马在书边空白处写下的那句我已发现一个绝妙的证明但空白太小写不下。这个猜想困扰了人类三百多年一直到 1994 年安德鲁·怀尔斯才用上了当时最前沿的椭圆曲线理论写出了上百页的证明而且第一步就依赖后来被证明成立的“谷山-志村-韦伊猜想”。这个证明本身已经足够复杂复杂到数学界花了多年时间消化它。而“形式化证明”则是另一件完全不同的事情把人类书写的、依赖直觉和语言逻辑的文字证明翻译成一台计算机能逐行验证的、严格机械化的证明。Claude 用 11 天把这两件“难上加难”的事同时做完了就是这次新闻的核心信息。很多人第一反应是“AI 能证费马大定理了数学家是不是要失业”也有人第一反应是“这不会是又一篇营销通稿吧”。作为一个既配过 Claude Code、也研究过 Lean 形式化验证的在座工程师我想认真聊一聊这次事件背后真正值得关注的东西端到端意味着什么Claude 的工作流到底有多颠覆以及如果我们也想踩进这个坑现实里会遇到哪些问题。1. 先搞清楚三件事费马大定理、形式化证明、端到端1.1 费马大定理为什么是数学史上最难啃的骨头之一费马大定理本身一句话就能说清当 n 大于等于 3 时方程 a^n b^n c^n 没有正整数解。但这句话背后的证明难度很多人低估了。一个关键原因在于费马抛出这个断言之后的三百多年里无数数学家证明了 n3、n5、n7 甚至一系列特殊指数的情况但对一般情形毫无办法。怀尔斯在 1994 年的突破不是说“我找到了一条通解”而是把费马大定理整体归约到了“所有半稳定椭圆曲线都是模的”这个模块化命题上再利用岩泽理论和变形环理论等工具完成了证明。整个证明链路之长导致后来的数学家们花了相当长的时间才逐步确认其中没有逻辑漏洞。所以费马大定理不是一个“难但可以硬算”的问题。它是一个需要新数学工具、新理论框架、跨多个分支联动才能解决的问题。任何一个试图证明它的形式化体系必然要面对无数层层嵌套的定义、引理、定理传播这是理解 Claude 这次成果的第一个前提它不是做一个竞赛题而是在一个高度抽象的巨型数学大厦里干活。1.2 形式化证明让数学从“说服人”变成“不骗电脑”形式化证明简单说就是把人能看懂的证明写成计算机能验算的证明。这事听起来像“写严格一点就行”但实际上比想象中变态得多。我举个接地气的例子。你高中证明过“三角形内角和等于 180 度”吧很多证明其实是依赖图形的直觉——把一条线延长一下画个平行线用眼睛看出来角度相等。但计算机没有视觉也没有直觉。你告诉它一个三角形它只会按图索骥地问你“你说这两条线平行请给出公理层级的依据”“你说这两个角相等请给出引用的是哪条定理”。在 Lean、Coq 这类证明助手里每一个看似显然的结论都要推进到由精确的类型定义、构造函数、归纳规则构成的形式证明树。也因为这种苛刻人类把怀尔斯证明形式化是一个漫长工程。我印象里早有团队在推进做费马大定理的形式化那是一个庞大的、以年计的工程。哪怕这些团队已经做完了很多基础铺垫真正的形式化工作依旧极耗精力。这也是为什么“Claude 11 天完成端到端形式化证明”会让数学家群体感到冲击力。1.3 端到端到底改了什么“端到端”这个词最近在 AI 圈已经快被用烂了但放在数学证明里必须重新解释。在 Claude 之前AI 参与数学证明的主流模式是“人机协作”AI 负责猜测证明思路、补全局部引理人类负责盯住整体方向把各种片段拼起来再逐行推进。这种模式里AI 更像一个超级计算器或者辅助论证工具工作流的掌控权在人手里。而这次“端到端”的意思是从输入问题本身到输出可验证的完整证明文件整个过程中没有人工逐步把关。Claude 自己去探索中间引理、自己决定证明顺序、自己调用 Lean 验证器做反馈失败了自己再换思路最后交出一个通过了机械化验证的完整证明产物。听起来是不是像一个“数学研究 agent”这在工程上是个巨大的边界移动。不是说 AI 从此能独立发现费马大定理这种级别的数学成果但至少在“形式化验证”这个环节AI 第一次做到了最短路径上的闭环。2. 核心细节拆解Claude 11 天证明里隐藏的技术逻辑2.1 它不是凭空算出来的而是站在证明助手生态的肩膀上要理解 Claude 这次做的事必须先知道 Lean 证明了什么位置。Claude 用到的证明助手 Lean 4 背后已经存在大量被人类数学家和工程师逐行验证过的库包括数学库 mathlib里面沉淀了几十万个定理和定义。换一种描述Claude 不是从字面意义上“发明”了费马大定理的证明而是通过调用这些已经机械化的数学碎片搜索、拼接、验证出了一条完整的前端到后端的证明路径。这个过程的难度依然非常高因为库里的定理不会自动告诉你该怎么组合。在每一层抽象之间选择正确的构造、主动去证明那些库还没覆盖的引理、找到隐藏在文档深处的适用的已有结论这套搜索能力正是 Claude 的强化点。对做过程序的的人来说好懂一点你相当于用一台安装了上百个开源依赖的开发机去从零撸一个大型系统。源代码都在但没有人告诉你架构应该怎么设计、哪些包可用你必须自己一边查文档一边试验直到编译通过。而 Claude 不只是“编译通过”它把这个开发动作严格限制在“数学证明必须逐条机械验证”的规矩里——任何一点偷懒都会导致证明验证失败无从作弊。2.2 一次推理不够关键在“搜索 验证”反馈循环Claude 能做到 11 天跑通端到端我不认为这是靠“单次大模型推理能力爆炸”实现的。更合理的拆解是它在那个持续运行的环境中执行了无数轮的“生成候选证明片段 → 采用 Lean 验证 → 返回错误信息 → 重新修改”循环。换成人脑的比喻这更像一个刻苦的研究生每天写几十页草稿自己用逻辑推演和同行检验去核查错了就回去改。区别在于Claude 的验证器反馈是以机器的严格度进行的速度上也许能以天为单位跑完上百轮迭代。所以这条 11 天的时间线意味深长它不是一个 LLM 单次生成的问题而是一个 agent 持续工作的时长。按照 Anthropic 公布的叙事这个 agent 需要长时间维护状态、跨会话保存进展、规划整体证明路径不断在抽象概念之间跳跃。这种“长时间运行 自我反馈 上下文维护”的模式才是真正贴近未来可落地的 AI 科研助手形态的东西。2.3 对比人类形式化的时间成本你就明白这有多惊人把费马大定理形式化这件事人类团队通常用什么时间尺度来衡量我从已知的公开项目里了解到人类数学团队完成一个大型定理的形式化往往以年为单位。哪怕是已经有大量现成库支撑的分支领域一个中等复杂程度的定理形式化一两个月也不算夸张。把费马大定理这样量级的证明在 11 天内从草稿推进到端到端形式化即使有前人在 mathlib 里的积累打底也是一个人类团队很难企及的速度。速度差异的来源不是人类不会搜索、不会拼接而是人类的注意力、体力和持续工作能力是有限的。Claude 可以 24 小时不停不歇地尝试同一条死路的一百种变形人做不到。这个时间的压缩说明“AI 做形式化数学”已经从理论可行性走到了效率和成本都具备真实竞争力的阶段。3. 实操视角如果我想跑通一个“AI 形式化证明”的工作流该怎么准备3.1 工具链选型和环境准备看完新闻很多人会好奇“我自己能用 Claude 干点类似的事吗”。先说结论你大概率不会真的去复现费马大定理但你完全可以搭建一个“数学证明 agent 工作台”让 Claude 帮你验证一条小定理这也是很值得做的体验。工具链上需要准备几块Lean 4 及配套的 mathlib这是形式化证明的核心环境。Claude或者 Claude Code承担策略生成和代码生成任务。一个能够持续运行脚本的服务环境我建议直接在本地终端跑配好 Claude Code 后让它长驻。版本管理工具比如 Gitagent 跑长任务时随时保存证明进度避免上下文丢失后一切归零。安装 Lean 4 一般用 elan 这个工具管理器然后拉取 mathlib 缓存过程不算复杂。真正麻烦的是环境变量的配置和网络访问稍后我会细讲踩坑。3.2 最小可行流程让 Claude 帮我在 Lean 里证明一个小引理为了让不熟悉的朋友有概念我给一个最朴素的流程示例。假设我们要让 Claude 证明一个简单命题“自然数加法是交换的”的某个特定实例或者更简单一点证明 “forall n : Nat, n 0 n”。预设环境变量后我启动 Claude Code给它一段系统指令你是 Lean 专家请使用 Lean 4 完成以下定理的证明每次写完一部分请运行 lean /path/to/file.lean 检查如果报错根据报错信息继续修改不要跳过验证步骤。然后我可以把 Lean 文件放到工作目录让 Claude 尝试填补证明。它第一步通常是导入 Mathlib声明 theorem然后尝试穷举归纳法等。执行过程很有意思Claude 生成的第一个版本大概率会报错比如它可能会写simp策略但遇到未覆盖的引理时Lean 会提示“简化器无法推进目标”。这时 Claude 看到错误反馈后会主动去library_search或omega等战术库里面找对应工具然后接着验证直到编译器无差错通过。这就是最小闭环生成 - 执行 - 读错误 - 修复 - 再执行。3.3 在 Claude Code 里配置 Lean 数学模式的通用做法如果你想做更Freestyle的尝试我建议在 Claude Code 里写一个CLAUDE.md或者项目说明文件把约束写清楚所有证明必须使用 Lean 4 的 mathlib。每次修改后用lake build或lean命令行编译检查。禁止在未验证的情况下以“我猜应该没问题”结束。如果一个引理反复失败超过三次先分解成更小的子目标。这些看起来朴素但极大改善 agent 的长任务稳定性。大多数人在 AI 写数学证明过程中遇到的翻车不是模型能力不够而是“没有给它错误反馈的入口”。让它能够持续接收编译器的报错就是给它装上了导航仪。4. 现实中的坑安装、连接、403 与模型路由问题实录4.1 Claude Code 安装时的典型报错与修复如果你想真正在本地把一套类似工作流跑起来遇到的第一个门槛往往是 Claude Code 的安装问题。很多人装上后用不了最常见的就是报错claude : 无法将“claude”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这个错误在 Windows PowerShell 下最常见几乎都是 PATH 环境变量没有配置好。npm 安装的全局包有时候会装到一个自定义路径下如果你之前装过 Node 的多版本管理器路径可能会乱。解决方法是找到claude或claude.cmd的实际路径手动加到 PATH 里然后重新打开终端。另外有人会遇到error: claude native binary not installed. either postinstall did not run这种情况通常是 npm 安装过程中 postinstall 脚本没有执行成功常见原因是使用 cnpm/pnpm 等替代包管理器或者公司的 npm registry 挡住了二进制下载。可以尝试删除 npm 缓存改用官方源或者重新执行安装命令让 postinstall 脚本重新跑一遍。4.2 “Unable to connect to Anthropic Services”和 403 的真正排查思路热词里频繁出现的unable to connect to anthropic services或status 403我自己也遇过而且这类报错往往让新手特别崩溃。这里要区分清楚403 和连接超时是完全不同的故障点。连接超时一般是网络链路层面的问题请求根本没有到达服务端DNS 解析、TLS 握手还是中间网络封锁都可能导致。403 Forbidden 则说明请求已经到达了服务端但服务端拒绝响应——最常见的原因是 API key 没有权限、账户余额不足、区域受限或者并发超额。有些人第一反应是“换一个代理”或者“换个工具”其实很多情况下换个 API key、检查配额就能解决。排查时按这个顺序来检查 API key 是否配置正确有没有多余空格。检查账户是否还有余额、额度是否有效。确认你使用的地址是官方文档给出的标准 endpoint。如果还不行找一个支持 Anthropic 协议的服务商切换测试看是不是账户问题。最后检查网络出口。注意不同网络环境对 Anthropic 服务的连通性不一样如果想在本地稳定使用请确保当前网络能正常访问该服务不要让公司或机构的防火墙策略成为隐藏变量。4.3 把 Claude Code 路由到 DeepSeek 或硅基流动模型的方法有很多朋友关心如何把 Claude Code 接到 DeepSeek 或者硅基流动这类第三方模型服务上。因为这类模型网关要么便宜体验好要么更适配本地需求是不少团队已经在用的省钱方案。配置逻辑其实很简单Claude Code 本质是一个支持 Anthropic 协议的客户端它通过环境变量指定 base_url 和认证 token。以接入 DeepSeek 为例你可以在环境中设置export ANTHROPIC_BASE_URLhttps://api.deepseek.com/anthropic export ANTHROPIC_AUTH_TOKEN你的DeepSeek_API_Key export ANTHROPIC_MODELdeepseek-chat这样启动claude时它就会把请求发送到 DeepSeek 的 Anthropic 兼容接口上。硅基流动的配置方式类似把ANTHROPIC_BASE_URL指向它的兼容端点再设置好对应的模型名和 token 即可。这种方法不需要修改客户端代码只是把内部协议互相兼容的模型接到 Claude Code 的命令行界面里。好处是留住了 Claude Code 的交互体验坏处是第三方模型的推理能力和工具调用质量差异很大如果任务很复杂建议还是切回官方 Claude 模型。我用过一段时间这类第三方路由方案最深的感触是省钱是省钱的但 Cocoa 里那些需要长时间上下文维护的任务第三方模型的稳定性明显还是差一口气。你要证明一个复杂定理时中途上下文忘了路径会让整个 agent 变成无头苍蝇。所以大任务我还是老老实实用官方服务小任务才考虑路由到便宜的第三方模型。4.4 VS Code 和桌面版的配置心得关于在 VS Code 里使用 Claude Code社区里常见的问题是最开始找不到对话记录。Claude Code 是一个终端工具你在 VS Code 的终端里启动它时它默认把工作状态放在项目目录下。如果你直接在 VS Code 里关闭窗口而没有正确保存或者退出会话下一次打开后会话历史可能不在当前这个终端上下文里就会让人感觉“对话怎么没了”。解决策略很直白把 Claude Code 当作一个独立的命令行工具来用不要把它当成 VS Code 原生插件。规范做法是设置好会话存储路径或者显式使用续聊命令让上下文写盘最后恢复。如果用 Claude Desktop 桌面版注意它和 Claude Code 的会话记录是两套体系工具定位不同别混着找。5. 这件事对数学界和普通开发者的真正影响5.1 机器验证正在改变“论文有效”的定义以前一篇数学论文发表后审稿人需要花大量时间去检验逻辑。而形式化证明一旦普及论文能不能过很可能变成“你的证明文件能不能在 Lean 里跑完”。一种更强的数学交流范式逐渐清晰人类写下思路和直觉AI 帮助翻译成形式化证明机器负责终极验收。费马大定理这种级别的定理都能被 11 天端到端形式化说明大部分已经成熟的新数学分支都有机会逐步被搬进数学库里。这是数学知识库的资产积累长尾价值巨大。以后的新定理证明可以直接站在这种已验证的资产上构建整体正确性风险大幅下降。5.2 长期运行的 AI Agent 才是真正的科研形态这次新闻里最容易被人忽略的其实是“持续运行 11 天”这件事。传统基于 LLM 的数学解题往往停留在单轮对话内而这次 Agent 证明了长期记忆、跨会话规划、自主纠错这些能力对复杂科研任务的完成至关重要。所以对普通开发者的启发我认为更落地你要开始适应“AI 是员工而不是搜索引擎”这个新心智模型。给 Claude Code 一个目标、一套工具、一个反馈机制然后让它持续跑定期检查关键输出。费马大定理的形式化证明是这样跑出来的很多工程任务也一样能这样加速。5.3 注意事项不是所有证明都能交给 AI 自动完成话又说回来这次成果很容易被过度解读。目前我们能看到的成功路径还是建立在已有数学知识和证明助手库之上的搜索验证循环AI 并没有真的独立创造出跨越时代的全新数学方法。端到端形式化证明解决的是一个“把已有结构查漏补缺、打通闭环”的问题而“如何想到新的抽象结构”依然是当前 AI 最不擅长的事情。另外把复杂证明翻译成形式化语言依旧需要大量算力个人电脑是跑不动的。如果你准备玩类似的事情先把预算、API 配额、网络连通性想清楚再动手。不然跑了三天中途提示 403 或者配额耗尽前面的工作直接白费那才是最容易劝退人的现实。我个人在实际操作中最大的体会是Claude 这次 11 天证明的形式化工作流本质上是把“耐心”这一科研要素外包给了机器。以前人做大型形式化最大的掣肘就是太容易出错、太容易累、太容易失去信心。现在 AI 可以在没有情绪的前提下一秒一秒地从错误中爬起来。我们离“机器在数学上真正发表突破性成果”还有距离但离“机器成为数学证明的强势把关人”已经很近了。最后再分享一个小建议别只盯着论文级数学。打开 Lean挑一个小问题让 Claude Code 在你的项目里帮你形式化一遍。感受一下它从报错到验证通过的过程你会更懂这次新闻里真正让人头皮发麻的地方在哪里。