从“AI 解数学题”到“AI 做数学研究”这两年技术演进的节奏比很多人预想的要快。最近有一个话题很有意思一个叫 GPT-5.6 的模型和一个叫 Fable 的证明引擎合作拿下了一道悬置 25 年的数学难题。这个结果在社区里的讨论度很高但大多数人注意力都被“25 年”吸引走了很少有人真正拆开看这套系统的技术链路是怎样的大模型在中间到底负责什么符号引擎又在做什么“证明”是怎么一步步被机器验证的。这篇文章我想写得更偏工程一点。我不会去炒作那条新闻本身而是以这类“大模型 形式化证明引擎”的组合为蓝本把背后的核心概念、系统架构、环境配置、运行流程、坑点和工程建议完整梳理一遍。即使你的日常工作不是做数学研究这套“生成候选 符号验证 反馈闭环”的思路在代码生成、测试用例生成、静态分析等领域都有很强的迁移价值。1. 背景与核心概念1.1 什么是“机器证明”和“形式化证明”传统意义上数学家证明一个定理靠的是严格的逻辑推导最终把结论“说服”给同行评审。机器证明则是把这一过程变成计算机可执行的任务我们不再用自然语言描述证明步骤而是用一套带有严格语义的符号语言把“定理”和“证明”都表达出来然后交给计算机进行机械式验证。形式化证明的核心思想是每一个证明步骤都必须落在预先定义好的逻辑规则上不能有模糊地带。比如你要证明“如果 A 且 A→B那么 B”这不叫一个结论它只是在表达一条推理规则。真正形式化之后你要在证明助手中写example (A B : Prop) (hA : A) (hAB : A → B) : B : hAB hA这就不是在“描述”证明而是把证明变成了一个可以被程序检查的表达式。证明助手如 Lean、Coq、Isabelle会在背后检查这一步是否合法类型是否匹配逻辑是否完整。1.2 大语言模型在数学证明中到底扮演什么角色很多人以为让 GPT-5.6 去解数学题就是直接输入题目、输出答案。这个理解在“竞赛题”层面勉强成立但在“科研级数学问题”上完全不够用。科研级问题往往没有标准答案证明路径可能极长一个证明可能包含几万甚至几十万个中间步骤。直接让大语言模型输出完整证明几乎一定会出现逻辑跳步、隐含假设、格式错误等问题。无论模型训练得多好这类“长程推理”问题都会因为注意力分散而失败。所以真实系统不会让大模型单打独斗。它的角色通常被拆成几个部分给定一个数学目标生成下一步的证明策略根据当前证明状态生成一个可行的中间引理对搜索树进行剪枝判断哪些路径更有可能成功把自然语言形式的数学想法翻译成形式化证明代码。Fable 这样的证明引擎则负责另一件事验证大模型生成的证明步骤是否真的合法。如果大模型生成的证明步骤不合法Fable 会返回错误信息系统再把错误信息喂回给大模型让模型根据反馈重新生成。这个循环本质上就是强化学习里常见的 actor-critic 结构只不过这里的 critic 不是神经网络而是一个绝对可靠的逻辑验证器。1.3 为什么“25 年难题”会成为一个标志性事件数学史上存在大量“表述简单但长期没有突破”的问题。它们可能被提出数十年期间无数人尝试却无法完成证明。这类问题有一个共同特点证明路径可能非常长或者需要构造一个极其复杂的反例/辅助对象。传统人工证明在这里会遇到瓶颈因为人很难同时管理数千个分支和中间状态。而大模型加证明引擎的组合正好在“大规模搜索”和“严格验证”这两个维度上补足了人类短板。当然这里要强调一句即使机器找到了证明路径也不代表数学家的工作被取代了。相反的机器生成的证明往往需要数学家去解读、简化和推广。真正的价值在于机器把“证明是否存在”这个问题的空间压缩了让人能站在更高的地方去看清结构。2. 环境准备与版本说明在进入代码之前我们先梳理一下做这类“大模型 证明引擎”实验需要哪些基础环境。2.1 需要准备哪些组件一个最小可跑的实验环境通常包括组件作用建议Python 3.9数据准备、策略生成、控制逻辑建议 3.10 以上PyTorch 2.x加载开源模型、推理需要 CUDA 环境Lean 4形式化证明验证引擎目前社区最活跃的证明助手之一大语言模型生成候选证明步骤本地部署或调用 API向量数据库可选缓存历史证明搜索状态工程化时可引入注意版本需要根据你的项目实际情况调整。本文示例以常见环境为例重点演示配置思路。2.2 创建一个实验目录建议按下面的结构组织项目文件math_agent/ ├── agent/ │ ├── __init__.py │ ├── llm_client.py # 大模型调用封装 │ ├── prover.py # 证明引擎交互 │ └── search.py # 证明搜索调度 ├── data/ │ └── examples.lean # 测试用 Lean 代码 ├── scripts/ │ └── run_demo.py # 主程序 ├── pyproject.toml └── README.md2.3 安装示例依赖下面给出一个基础的依赖清单你可以按需调整pip install torch pip install transformers pip install lean-auto这里的lean-auto是我用来做演示的占位包名实际项目中你需要根据你的 Lean 环境选择合适的交互库比如直接调用 Lean 的命令行接口或者使用社区维护的 Python 绑定。3. 核心原理拆解3.1 把“解数学题”拆成搜索问题大模型 证明引擎解决数学问题的框架本质上是一个树形搜索问题。初始状态下我们有一个证明目标G比如“证明所有大于 1 的整数可以分解为素数的乘积”。系统尝试从G出发不断应用推理规则直到把目标归约为空。每一步搜索都会生成多个候选策略证明引擎Fable接收当前目标大模型根据当前目标生成若干候选策略每个候选策略交给证明引擎执行如果执行成功产生新的子目标如果执行失败丢弃该分支。这个循环反复进行直到所有子目标都被证明或者搜索超时。3.2 大模型的“生成”和证明引擎的“验证”大模型在这里不是“最终裁判”它只是“策略生成器”。这个设计非常关键。如果让大模型自己判断证明是否正确那就会产生自欺欺人的问题模型在逻辑上是概率性的它无法保证自己生成的推理链中每一步都严格成立。而证明引擎是确定性的它按照一套固定的逻辑规则执行验证不会“觉得”一个步骤看起来不错就放行。所以这套架构的成功基础是生成能力来自大模型判断能力来自符号引擎。这也解释了为什么 25 年难题能被解决——它不是靠大模型凭空顿悟的而是靠大模型在庞大的搜索空间中不断产生有希望的候选路径再由证明引擎负责每一步的精确验证最终拼出了一条人类之前没有走通的路。3.3 反馈闭环与多轮精修一个值得展开的细节是当证明引擎返回错误时系统并不是简单放弃那个分支而是会把错误信息作为提示词的一部分重新交给大模型。举例来说如果证明引擎返回“unexpected token”大模型在下一轮生成时就会看到这个错误信息于是更有可能生成正确的语法结构。这种多轮精修机制和我们在日常编程中使用大模型时“把编译器报错粘贴回对话”的做法非常相似。区别只在规模和自动化程度上。4. 完整实战案例模拟一个极简证明搜索系统下面我们用一个教学性质的示例把“大模型生成策略 符号引擎验证”的闭环跑通。这里会做一个简化我们用 Python 实现一个微型的逻辑表达式验证器然后模拟大模型生成候选策略并让验证器判断是否合法。4.1 定义命题逻辑表达式首先定义一套极简的命题逻辑抽象语法树# 文件路径agent/ast_nodes.py from dataclasses import dataclass from typing import Union dataclass class Var: name: str dataclass class Implies: left: Union[Var, And, Implies] right: Union[Var, And, Implies] dataclass class And: left: Union[Var, And, Implies] right: Union[Var, And, Implies]这里定义了三种节点变量、蕴含、合取。Implies(A, B)表示“A 蕴含 B”And(A, B)表示“A 且 B”。4.2 实现极简证明验证器我们需要一个函数判断“给定前提集合和结论是否能通过一个简单的证明规则推导出来”。# 文件路径agent/simple_prover.py from typing import Set def can_prove(premises: Set[str], goal: str) - bool: 极简验证器 1. 如果结论本身就在前提中则证明成立 2. 如果前提中存在 A 和 A-B且结论是 B则证明成立 3. 其他情况视为无法证明。 if goal in premises: return True for p in premises: if p.startswith(() and p.endswith(-): # 形如 (A - B) inner p[1:-1] # 去掉外层括号 left, right inner.split(-, 1) left left.strip() right right.strip() if left in premises and right goal: return True return False这个验证器非常简陋但它足以说明一个核心思想验证器不关心证明过程是否“好看”只关心是否能从已知前提机械地推出目标。4.3 模拟大模型生成候选策略真实场景中这里会调用一个 LLM。教学示例中我们用规则生成几个候选策略# 文件路径agent/llm_client.py import random def generate_candidates(premises: Set[str], goal: str): 模拟大模型基于前提和目标生成候选策略。 实际项目中这里会调用 GPT-5.6 等模型。 candidates [] for p in premises: if - in p: candidates.append(fuse premise {p}) if goal not in premises: candidates.append(ftry introduce {goal}) candidates.append(apply backward reasoning) random.shuffle(candidates) return candidates[:3]这里生成的候选并不一定都有效后面验证器的价值就体现出来了。4.4 串联搜索闭环现在把大模型和验证器连起来# 文件路径scripts/run_demo.py import sys import os sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), ..))) from agent.simple_prover import can_prove from agent.llm_client import generate_candidates def run_search(premises, goal, max_iterations5): cur_premises set(premises) for iteration in range(max_iterations): print(f\n第 {iteration 1} 轮搜索) print(f当前前提: {cur_premises}) print(f当前目标: {goal}) if can_prove(cur_premises, goal): print(验证通过目标可从前提推出) return True candidates generate_candidates(cur_premises, goal) print(f模型生成候选策略: {candidates}) # 逐个尝试候选策略 accepted False for cand in candidates: if cand.startswith(use premise): premise_name cand.replace(use premise , ) if premise_name in cur_premises: print(f策略被接受{cand}) accepted True break if not accepted: print(本组候选策略均不被验证器接受引入新的前提尝试) cur_premises.add((A - B)) return False if __name__ __main__: premises_sample {A} goal_sample B success run_search(premises_sample, goal_sample) print(f\n最终证明结果: {success})4.5 运行与预期结果运行命令python scripts/run_demo.py预期输出大致如下第 1 轮搜索 当前前提: {A} 当前目标: B 模型生成候选策略: [apply backward reasoning, try introduce B] 本组候选策略均不被验证器接受引入新的前提尝试 第 2 轮搜索 当前前提: {A, (A - B)} 当前目标: B 验证通过目标可从前提推出 最终证明结果: True这个演示虽然简单但已经完整呈现了大模型 证明引擎协作的核心循环大模型生成候选策略验证器接收并执行策略失败时反馈错误或补充信息进入下一轮直到证明完成。4.6 如何把它替换成真实大模型如果你想把这个流程替换成真实的 GPT-5.6 或其他开源模型核心改动集中在generate_candidates函数中。你需要把当前证明状态序列化为文本调用模型接口再解析返回结果。例如提示词模板可以长这样你是一名形式化证明助手。当前前提如下 {premises} 当前待证明目标 {goal} 请生成下一步证明策略直接输出策略内容不要解释。然后用模型输出替换掉演示中的规则生成逻辑即可。5. 常见问题与排查思路在实际部署这类系统时遇到的问题远不止“代码报错”。这里整理一张排查表覆盖了从模型推理到证明引擎交互的常见问题问题现象常见原因解决思路证明引擎返回语法错误大模型生成了不合法代码把错误信息回传模型多轮精修限制输出格式搜索长时间不收敛策略搜索空间过大引入优先级排序让模型给策略打分显存不足输入上下文过长压缩历史状态只保留关键路径证明被接受但实际错误验证器本身实现有缺陷不要自研验证器使用 Lean 等成熟证明助手模型重复生成相同错误策略缺乏对失败历史的记忆在提示词中加入已尝试策略列表并发推理下全局限流请求过于密集加入重试、指数退避、异步队列生成证明过长无法验证单次验证超时拆分证明步骤逐步验证5.1 策略生成不合法代码怎么处理这是最常见的问题。大模型生成的内容本质上是对 token 的概率采样它不理解“语法”它只是在模仿训练数据中的分布。所以生成结果中夹杂语法错误的概率并不低。解决方案不是一遍遍重试而是构建一个语法校验器先过滤掉明显不合法的候选再把错误信息返回给模型。# 文件路径agent/validator.py import re def check_lean_syntax(code: str) - tuple[bool, str]: 简化版 Lean 语法检查至少检查括号是否匹配。 真实项目建议调用 Lean 编译器或使用其 Python API。 stack [] for ch in code: if ch (: stack.append(ch) elif ch ): if not stack: return False, extra closing parenthesis stack.pop() if stack: return False, unclosed parenthesis return True, ok5.2 证明搜索不收敛数学证明的搜索空间是极大的朴素搜索几乎不可能成功。工程上常用的优化手段是对搜索树做剪枝限制每一步生成的候选策略数量记录已访问过的证明状态避免重复搜索根据历史成功率给不同策略类型设置优先级使用值函数对大模型生成的候选打分。这实际上已经接近强化学习中的策略优化思路。6. 最佳实践与工程建议6.1 不要自研验证器除非你的目标是研究验证器本身这是最重要的一条建议。很多人在做大模型 数学实验时第一反应是自己写一个“推理验证器”比如像我们上面这个can_prove这样。这个作为教学演示没问题但一旦进入真实研究自研验证器几乎一定会出错。数学证明的验证难点在于它需要覆盖大量推理规则、类型系统、定义展开等多个层次。这些逻辑规则之间还会互相组合。如果你用 Python 硬编码这些规则代码复杂度会迅速超出维护能力。更稳妥的选择是直接使用成熟的证明助手比如 Lean 4 或 Coq。你只需要写好当前要证明的定理然后用大模型生成证明代码交给 Lean 验证。验证通过就是通过没有任何模糊空间。6.2 记录失败历史避免模型在同一个坑里反复踩大模型是无状态的。在同一个证明搜索任务中它不会自动记得上一轮尝试过什么。所以你需要在提示词中显式携带“历史尝试记录”以下策略已被尝试且失败 1. apply assumption A - B 错误信息invalid type ascription, term has type C 请生成一个不同的策略。只告诉模型“要做什么”不够还要告诉模型“不要做什么”。6.3 控制上下文长度防止模型“迷失”真实证明任务经过多轮迭代后提示词会越来越长。当上下文超过一定长度后模型注意力会分散生成的策略质量会明显下降。工程上的做法是使用向量数据库保存历史证明状态每次只读取与当前目标最相关的几条历史记录对大段证明过程做摘要再送入模型必要时重新启动一轮新的搜索而不是无限追加历史。6.4 明确人机边界最终解释权属于数学家即使系统能够形式化地验证证明也不代表这个证明在数学上有“解释力”。形式化验证能确认推理链每一步合法但无法判断这条证明路径能否被简化为更优美的人类可读形式。在真实项目中一个好的工作流是这样的大模型 证明引擎快速搜索可行证明路径数学家阅读证明结构数学家对证明进行简化、抽象和推广最后将成果写成论文并附上机器可验证的附件。6.5 注重可复现性科研级实验必须可复现否则结论没有意义。建议在工程中固定以下内容大模型的具体版本号采样参数温度、top-p 等证明引擎版本搜索策略随机种子。这些信息最好统一记录在一个config.yaml中model: name: gpt-5.6-example temperature: 0.2 top_p: 0.9 prover: engine: lean4 version: 4.7.0 search: max_iterations: 100 timeout_seconds: 3600 seed: 42这样做的好处是即使几个星期后你再回来看实验依然能根据配置恢复完全一致的运行环境。7. 从数学证明到软件工程的迁移思考做完了这个项目我自己最大的收获不一定在数学本身而在于这套思路完全可以迁移到日常软件工程中。7.1 代码生成领域的“验证器”就是编译器大模型生成代码时有一个天然的验证器——编译器。很多团队抱怨“AI 编程助手生成的代码不能直接用”根本原因不是模型不够强而是缺少一个自动反馈闭环。如果能让大模型在生成代码后自动编译编译失败后自动把错误信息回传再让模型修改直到编译通过那么这个闭环的效率会远高于“人复制代码 - 运行 - 复制报错 - 再让模型改”的笨重流程。7.2 测试用例也可以这样生成大模型生成测试用例时正确性难以保证但执行测试本身就是验证。把模型生成的测试用例放到沙箱中执行校验断言是否正确、覆盖率是否达标这就是一个缩小版的“证明引擎”。7.3 知识工作自动化的边界这套系统的边界同样值得关注大模型擅长在混乱的信息中捕捉模式生成有希望的候选方案符号引擎擅长在精确规则下做严格验证。两者结合能解决很多“以前只能靠人肉”的问题。但它们的结合并不能解决所有问题。对于那些连形式化描述都做不到的任务比如“这段代码是否优雅”“这个需求是否合理”符号引擎无能为力大模型也只能给出概率性的参考判断。这也是为什么我们在做工具链时永远不要试图用一个通用模型去替代所有决策环节。如果你对 AI 辅助数学证明这个方向感兴趣下一步建议先动手跑一个真实的大模型 Lean 4 的最小闭环把“生成候选策略 - 提交给 Lean 验证 - 根据错误信息重试”这个流程走通。这比关注那条“25 年难题”的新闻本身有价值得多。