尧图网页设计 
1. 这篇文章真正要解决的问题先抛一个可能让你意外的问题一个数学能力远不如数学系本科生的语言模型为什么这两年反而成了数学研究工作流里频繁出现的角色如果你平时关注 AI 应用大概率看过不少类似说法LLM 会算错四则运算、面对稍微变形的应用题就崩溃、在数学推理上表现极其不稳定。这些批评没错。但如果你把“AI 做数学”理解成“让 AI 解数学题”那就把这个命题想窄了。真正让数学家、理论计算机科学家和做计算研究的工程师感兴趣的不是让模型去参加奥赛而是把 LLM 嵌入到数学研究的完整工作流里——从生成猜想、辅助证明、检查反例到把论文里晦涩的推导变成可执行的代码。这篇文章要拆解的就是“AI 尤其是 LLM 在重大数学发展中到底能干什么”。我会先明确概念边界再讲清楚 LLM 在数学研究中真正被验证过的使用方式接着给出一套可以照着跑的环境准备和完整示例代码最后梳理常见误区和工程建议。读完你会发现LLM 对数学的价值不是“替代大脑”而是“放大动作”——它不能替你证明定理但能把探索问题的摩擦成本降到近几年最低。需要说明的是本文不讨论任何未经公开资料证实的“AI 独立证明大定理”的夸张叙事。真实情况是目前绝大多数成功的案例都是人类数学家负责方向判断AI 负责局部推理、符号操作、反例搜索和代码实现。这个分工本身就是值得认真研究的工程问题。2. 基础概念与核心原理2.1 什么是“AI 参与数学发展”如果你去读数学史的经典叙事重大突破通常被描述成某个天才灵光一现的产物。但真实的研究过程远没有那么浪漫数学家大多数时间在做的是大量符号计算、模式识别、特殊情形枚举、假设试错和反例搜索。这些动作有一个共同点——它们规则性强、上下文明确、失败成本低恰恰是大模型相对擅长的领域。所以“AI 参与数学发展”并不是指 AI 独立证明黎曼猜想而是指以下能力的组合在给定数学对象族中寻找规律提出可验证的猜想对已有证明文本进行结构梳理辅助发现逻辑缺口将数学推导转化为可执行的符号计算代码在大规模搜索空间中高效定位反例或构造性示例。这些能力单独拿出来都不算“革命”但叠加在一起实际改变的是数学家的研究节奏。2.2 LLM 在数学任务中的三层能力模型根据实际使用经验可以把 LLM 的数学能力分为三层来理解很多关于“AI 数学能力行不行”的争论其实是因为只看到了某一层。第一层是语言理解与任务解析。LLM 能读入一段带有大量符号和术语的数学描述理解“已知什么、要求什么、约束条件是什么”。这一层做得好的模型即使计算能力一般也能把问题重新组织成清晰的形式化表达。这也是为什么“让 LLM 先复述问题再解题”通常比直接给答案效果更好。第二层是符号操作与规划。包括代数展开、方程变形、证明步骤规划等有一定规则性的操作。这一层 LLM 的表现介于“可用”和“不可用”之间短步骤操作可靠长链条推理会衰减。这也是推理时增加思考链能明显提升准确率的原因。第三层是创新性推理——即从零构造一个没见过的新定理或新证明。这一层目前远未达到可靠水平但正因为如此它成为了人机协作的核心地带LLM 提供候选路径人类负责审慎判断。把握这层模型你就会明白为什么现在数学领域用得最多的 AI 工具不是专门训练的“数学大模型”而是通用 LLM 配合符号计算引擎如 SageMath、Mathematica的混合架构。2.3 符号计算引擎与大模型的互补关系很多开发者容易把“数学 AI”等同于“用大模型解题”但实际上目前能真正落地到研究工作流中的方案大多数是LLM 符号计算引擎的组合。符号计算引擎这里指 SageMath、Mathematica、SymPy 这类工具擅长精确计算、公式推导、代数验证它们的缺点是需要人用代码描述任务不支持自然语言交互。大模型正好补上这层交互短板——它能理解自然语言描述的数学问题把它翻译成符号计算代码再调用引擎执行。反过来符号计算引擎的精确输出又弥补了 LLM 的“幻觉”缺陷模型给一个推断引擎可以负责严格验证。这个组合的价值在于它把“用自然语言做数学研究”变成了一个工程上可行的工作流而不是一个纯聊天式的“AI 猜答案”过程。3. 典型方向与已有关键案例在进入实操之前有必要把你需要知道的关键案例梳理一遍。这些案例来自公开发表的研究资料也最能说明 AI 在数学发展中真实的工作位置。3.1 机器学习辅助发现数学规律在深度学习兴起之前数学家就长期使用计算机枚举和统计分析来寻找规律。LLM 带来的变化在于它能提供更高层次的“模式描述层”——不是简单列数据点而是用自然语言描述观察到的规律并转化为形式化猜测。这类工作最有代表性的是利用机器学习聚类和模式识别在数论、组合学、几何学中发现新猜想。比如有研究通过监督学习在数学对象之间发现隐藏关联导致数学家注意到此前被忽视的规律并由此构造出严格的数学证明。这里机器不是证明者而是“提出值得验证的猜想”的引擎。3.2 定理证明器与 AI 的深度结合严格说数学发展最核心的活动是证明。近年来形式化证明领域发生了一次范式变化Lean、Isabelle、Coq 等证明助手从“专家工具”走向了“LLM 目标环境”。Lean 在数学形式化项目中的应用是一个标志性事件。其思路是由数学家把定理陈述和证明步骤输入到 Lean 环境中由系统严格验证每一步是否成立。而 LLM 在这个流程中扮演的角色是“策略生成器”——它观察当前证明状态生成下一步可能采用的形式化证明策略tactic再由 Lean 的验证核心确认是否有效。这种“LLM 生成候选动作 形式化系统验证”的架构把大模型从“不可靠的推理者”降格成了“可以被审查的方案建议器”。这是目前 AI 参与数学发展最被认可、也最有可能长期演进的方向。2024 年公开的 AI 在数学竞赛题中解决几何问题的案例也采用了类似思路借助语言模型生成证明路径再用符号引擎严格验证。3.3 代码生成将数学推导转化为实验工具这是 CSDN 读者最应该关注的视角对绝大多数工程师而言参与“AI 数学”的切入点不是证明定理而是利用 LLM 把论文中的数学描述变成可运行的实验代码。无论是复现论文里的算法、批量验证一个不等式对海量随机输入是否成立还是把一篇几个月前发表在 arXiv 上的方法在本地跑通LLM 的代码生成能力都已经足够带来明显的效率提升。这也是本文实战环节将要演示的核心场景。4. 环境准备与前置条件下面进入可以实际操作的部分。本节的示例会基于当前主流开源体系不做任何特殊定制保证你在一台普通开发机上就能跑通。4.1 基础环境要求Python 3.10 及以上建议 3.11SymPy 和相关科学计算库兼容性更好一台可联网的机器用于调用 LLM API或本机部署模型建议至少 8GB 内存本示例对 GPU 没有硬性要求一个可用的 LLM API KeyOpenAI、Anthropic、DeepSeek 等均可也可以使用本地模型如通过 Ollama 部署 Qwen2.5 或 Llama 3.1只要提供 OpenAI 兼容接口即可操作系统不限Windows / macOS / Linux 均可。4.2 Python 依赖安装建议先创建独立虚拟环境避免污染全局 Pythonpython -m venv .venv source .venv/bin/activate # Windows 下为 .venv\Scripts\activate安装必要依赖pip install sympy requests openai这里解释一下三个库的用途sympy符号计算引擎负责验证 LLM 给出的数学推断是否真的成立openai调用大模型 API。注意不管后端是哪个厂商只要兼容 OpenAI 接口协议代码逻辑基本一致requests如果你不想用 SDK可以用它直接请求 HTTP 接口本文示例中选择直接用openaiSDK更简洁。如果你使用本地模型例如通过 Ollama 启动一个 OpenAI 兼容服务只需要把base_url指向本机服务地址api_key填任意非空字符串即可。4.3 环境变量配置推荐把 API Key 放到.env文件或环境变量中不建议硬编码在 Python 脚本里。为避免额外引入第三方库本文直接使用os.getenv读取export OPENAI_API_KEY你的密钥 export OPENAI_BASE_URLhttps://api.openai.com/v1 export LLM_MODELgpt-4o-mini如果使用本地模型LLM_MODEL改成你拉取的模型名OPENAI_BASE_URL改成http://localhost:11434/v1。5. LLM 参与数学研究的两种实践模式在写代码之前你需要理解当前 LLM 参与数学发展的两种主流工作模式。把它们想清楚后面写代码时才不会迷失方向。5.1 模式一LLM 提出规律符号引擎验证这是最有数学研究味道的模式。流程是人工构造或让 LLM 生成一个待探索的数学对象集合LLM 对集合进行模式阅读提出一个归纳猜想将猜想写成形式化命题用 SymPy 等工具对大规模样本进行验证如果验证通过把猜想作为线索提交给数学家做严格证明如果失败让 LLM 修正猜想或缩小适用范围。这个模式里LLM 的角色是“探索助手”符号引擎是“验证者”。重要原则LLM 给出的结论本身没有权威性只有经过符号引擎或人工证明的结论才可信。5.2 模式二数学家提出猜想LLM 构造反例参考很多数学问题真正难的不是证明而是找到反例。LLM 擅长在灵活的空间里生成“可能性”这正好用于反例搜索。流程是给定一个研究中的猜想让 LLM 描述在哪些特殊边界条件下猜想可能不成立LLM 生成这些边界条件下需要验证的具体计算任务符号计算引擎执行精确计算并返回结果。这个模式能够显著压缩搜索空间——LLM 虽然不能保证找到反例但往往能提供人类直觉之外的“测试点”候选。这两种模式并不互相排斥。一个充分的“AI 辅助数学”工作流往往两者兼用先让 LLM 提出规律再让它思考边界条件最后用符号计算接管验证。6. 完整示例代码实现下面进入可落地的完整示例。这个示例模拟了一条简化的数学研究流水线让 LLM 观察整数数列提出规律然后用 SymPy 验证。6.1 示例一让 LLM 提出数列猜想并用 SymPy 验证这是一个最小演示目的是让你看到“LLM 符号计算”的完整配合方式。# 文件路径src/llm_math_demo/sequence_explorer.py import os from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) MODEL os.getenv(LLM_MODEL, gpt-4o-mini) SEQUENCE [0, 1, 4, 9, 16, 25, 36, 49, 64, 81] def ask_llm_guess(sequence): prompt f 观察以下整数数列 {sequence} 请用自然语言描述你发现的规律并给出一个你认为能生成这个数列的通项公式。 只需要描述规律和公式不要写额外解释。 resp client.chat.completions.create( modelMODEL, messages[{role: user, content: prompt}], temperature0.2, ) return resp.choices[0].message.content def verify_with_sympy(expression_str, n_values): from sympy import symbols, sympify, lambdify n symbols(n) expr sympify(expression_str) f lambdify(n, expr, math) results [f(k) for k in n_values] return results if __name__ __main__: guess ask_llm_guess(SEQUENCE) print(LLM 提出的规律) print(guess) # 用 SymPy 显式验证平方数通项公式 from sympy import n as sym_n formula n**2 checked [int(v) for v in verify_with_sympy(formula, range(10))] print(\nSymPy 验证 n^2 前 10 项) print(checked) print(\n与原数列一致, checked SEQUENCE)这段代码的核心逻辑是第 8 到 12 行初始化 OpenAI 兼容客户端第 14 到 15 行定义待研究的整数数列ask_llm_guess让模型基于数列给出规律描述verify_with_sympy接收一个字符串形式的数学表达式用 SymPy 把它解析成函数再批量求值最后对比验证结果与真实序列。运行方式python src/llm_math_demo/sequence_explorer.py成功输出大致如下LLM 提出的规律 这个数列是 n^2 的取值其中 n 从 0 开始取值每一项等于 n 的平方。 SymPy 验证 n^2 前 10 项 [0, 1, 4, 9, 16, 25, 36, 49, 64, 81] 与原数列一致 True这个例子看似简单但它展示了一个完整的人机协同闭环LLM 负责从序列中识别模式并给出通项公式SymPy 负责把公式变成可执行代码并验证正确性。如果把SEQUENCE换成更复杂的数学对象比如某个群论相关的特征值序列或者某个组合数序列的前若干项这个流程可以直接复用。6.2 示例二让 LLM 设计反例测试点接下来模拟更接近真实数学研究的工作流。我们给定一个常见的不等式猜想让 LLM 提出可能导致不等式失败的边界条件然后用数值计算验证。这里要演示的不等式是一个非常基础的数学事实实际成立。我们使用它的目的是演示“怎么用 AI 设计反例搜索实验”而不是真的要找它的反例。# 文件路径src/llm_math_demo/counterexample_search.py import os import random from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) MODEL os.getenv(LLM_MODEL, gpt-4o-mini) PROPOSITION 对任意正实数 a, b不等式 (a b)^2 4ab 恒成立。 def ask_llm_for_test_cases(): prompt f 有以下数学命题 {PROPOSITION} 请设计 10 组可能导致该命题不成立的测试输入 (a, b)。 只需要给出 (a, b) 数值列表不要解释。 resp client.chat.completions.create( modelMODEL, messages[{role: user, content: prompt}], temperature0.5, ) content resp.choices[0].message.content return content def parse_pairs(text): # 简单解析模型返回的坐标对容忍一些格式差异 import re pairs re.findall(r\(\s*(-?\d\.?\d*)\s*,\s*(-?\d\.?\d*)\s*\), text) return [(float(a), float(b)) for a, b in pairs] def check_inequality(a, b): return (a b) ** 2 4 * a * b if __name__ __main__: print(LLM 建议的测试点) suggestions ask_llm_for_test_cases() print(suggestions) pairs parse_pairs(suggestions) # 如果 LLM 返回格式不理想补充几组随机边界值 pairs.extend([(0.0001, 9999.0), (-1.0, 0.5), (1e-10, 1e10)]) print(\n实际用于验证的测试点数量, len(pairs)) failed [] for (a, b) in pairs: if not check_inequality(a, b): failed.append((a, b)) if failed: print(以下测试点出现反例) for item in failed: print(item) else: print(所有测试点均通过未发现反例。)运行方式python src/llm_math_demo/counterexample_search.py如果一切正常你会看到类似输出LLM 建议的测试点 可能的测试点包括 (0, 0)、(1, -1)、(-0.5, -0.5) 等边界情况。 实际用于验证的测试点数量 13 所有测试点均通过未发现反例。这个例子的意义在于check_inequality才是真正值得信任的判断逻辑LLM 只是“建议了值得去检查的地方”。在实际数学研究中你也应该按照这个思路设计系统——LLM 的定位永远是“建议器”而不是“验证器”。需要注意如果 LLM 返回了非数值格式parse_pairs可能解析不到。这时你可以人工从控制台输出的文本里挑选坐标或者调整check_inequality让它直接接受更宽泛的输入。在实际项目中更稳妥的做法是用结构化输出JSON mode或再加一层解析校验。6.3 示例三把论文中的数学公式转成可验证代码这个示例最贴近工程实践。我们模拟一个场景你刚读了一篇论文里面给出了一种特殊矩阵的构造公式你想快速验证它是否满足论文声称的性质。让 LLM 帮你把公式翻译成 SymPy 代码你只需要写一个简短的任务描述。# 文件路径src/llm_math_demo/paper_formula_to_code.py import os from openai import OpenAI from sympy import Matrix, symbols, simplify client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) MODEL os.getenv(LLM_MODEL, gpt-4o-mini) FORMULA_DESC 请把以下数学描述转换成 SymPy 代码 构造一个 3 阶矩阵 A满足 A[i][j] i * j 1其中 i, j 从 1 开始。 然后计算 A 的行列式。 只输出 Python 代码不要解释。 def generate_sympy_code(): resp client.chat.completions.create( modelMODEL, messages[{role: user, content: FORMULA_DESC}], temperature0.0, ) return resp.choices[0].message.content if __name__ __main__: code generate_sympy_code() print(LLM 生成的 SymPy 代码) print(code) print(\n---- 执行代码 ----\n) # 直接执行模型生成的代码 # 注意LLM 生成的代码可能包含非 SymPy 写法生产环境需要加沙箱 exec_namespace {Matrix: Matrix, symbols: symbols, simplify: simplify} exec(code, exec_namespace)运行后模型可能会生成类似这样的代码from sympy import Matrix A Matrix([[1, 2, 3], [2, 3, 4], [3, 4, 5]]) det_A A.det() print(det_A)执行结果0这个结果说明该矩阵的行列式为 0即它不是满秩矩阵——这个发现可能意味着论文中某个步骤需要进一步审视或者你需要检查初始条件是否设置正确。需要特别提醒直接exec大模型生成的安全相关代码非常危险。示例中只是因为任务简单、代码来源信任度可控才这么写。在实际项目里应当在沙箱或容器中运行并且对生成的代码做静态审查后再执行。7. 运行结果与效果验证7.1 如何判断你的流水线“真的有效”不是程序跑通就代表有效。一个合格的“LLM 辅助数学研究”系统至少要满足以下条件结果可复现同一个问题重复运行LLM 给出的建议可能有差异但最终经过符号验证后的结论应该稳定。验证逻辑独立验证部分不应依赖 LLM 生成的代码来判断正确性。更稳妥的做法是LLM 只输出数学推断验证逻辑由开发者手写。有失败切换当 LLM 输出无法解析或无法执行时系统应当有降级方案比如重新调用一次或提示人工介入。7.2 验证步骤清单第一阶段检查 LLM 输出格式。如果输出包含代码块标记或 Markdown 语法需要先清洗。第二阶段执行符号验证观察是否有异常或断言失败。第三阶段人工审查关键结论。LLM 给出的规律只有在人工认可后才具备“研究线索”价值。如果某一步失败优先看控制台中打印的 LLM 原始输出再检查解析逻辑是否太严格。8. 常见问题与排查思路问题现象可能原因排查方式解决方案LLM 返回内容包含 Markdown 代码块标记提示词中未要求纯文本输出打印原始响应用于排查在提示词中明确“只输出代码不要代码块标记”或用正则去除反引号SymPy 执行报错SyntaxErrorLLM 生成的代码与当前 SymPy API 不兼容查看堆栈信息定位具体行在提示词中指定 SymPy 版本或让模型先生成伪代码由开发者翻译解析坐标对为空模型返回了自然语言而非严格数值列表检查原始输出格式使用 JSON mode 或增加 few-shot 示例数值验证结果与直觉不符数学公式本身有误或边界条件设置错误人工手算小规模样例先缩小范围验证再扩大到完整样本调用 API 超时或限流任务复杂导致模型推理时间过长检查 API 错误码和网络状况增加重试机制或切换到响应更快的模型本地模型输出质量不稳定模型参数量较小或未设置合理温度尝试 temperature0换用更大尺寸模型或增加推理步数9. 最佳实践与工程建议9.1 把 LLM 当成“实习生研究员”来管理我在多个数学相关项目中总结出一条经验最适合 LLM 的定位不是“权威解答者”而是“可以无限提建议但需要逐条验证的实习生”。这意味着你在设计系统时天然要加一层审核、验证和容错机制。好的做法是设定三条纪律不信任模型的数学结论只信任它提供的线索所有经过验证的结论要立即形成可回归的测试用例每一次探索都要能被日志记录并回溯。这三条纪律能避免“AI 给出一个貌似合理但实际错误的结论被当作研究线索继续投入”的尴尬局面。9.2 使用结构化输出提升解析稳定性很多人一开始用 LLM 做数学辅助时最痛苦的阶段其实是“清洗模型输出”。建议从一开始就要求模型返回 JSON并用代码校验 JSON Schema。下面是一个简化示意from openai import OpenAI import json, os client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) resp client.chat.completions.create( modelos.getenv(LLM_MODEL), messages[ {role: system, content: 你只输出 JSON不要输出其他内容。}, {role: user, content: 请观察数列 0,1,4,9,16,25输出 JSON{\pattern\: \\, \formula\: \\, \confidence\: 0.0}}, ], response_format{type: json_object}, ) data json.loads(resp.choices[0].message.content) print(data)这比让模型自由输出文本再正则解析要可靠得多。如果你的后端模型不支持response_format参数可以通过系统提示词约束再用严格的 JSON 解析函数处理。9.3 用“验证锚点”对抗幻觉经验表明给 LLM 提供“验证锚点”能显著提升数学任务的表现。所谓验证锚点就是你预先告诉它某个中间结论或代数结果是多少让它在推理时以此为界之后的所有步骤都必须与锚点一致。例如在提问时加上在你开始推理之前请注意当 n3 时这个序列的真实值是 9。这个简单技巧能大幅减少模型在长推导中“跑偏”的概率。9.4 安全边界与代码执行风险必须强调不要直接在生产环境执行 LLM 生成的代码。推荐的安全执行方式包括在 Docker 容器或虚拟化沙箱中执行限制执行超时时间比如 10 秒不授予网络权限给执行环境输出只允许标准 stdout/stderr禁止读写任意文件对代码使用静态分析工具做基础过滤。这些措施不仅能防止提示注入也能避免模型生成的错误代码因为意外副作用破坏你的开发环境。9.5 与形式化证明工具的对接建议如果你想把本文的方案推进到更严格的方向下一步是接入 Lean 或 Isabelle。对工程师来说这项工作的技术关键词是将自然语言数学问题翻译为 Lean 策略序列再由 Lean 验证。由于 Lean 的类型系统和策略语言相对复杂建议从一个已有数学形式化项目的基础库开始而不是从零搭建。10. 总结与后续学习方向一个逐渐清晰的共识是AI 和 LLM 在数学发展中的角色已经不再停留在“能不能做题”的讨论层面而是进入了“如何嵌入研究工作流”的工程问题阶段。本文通过几个可运行的示例展示了最基础也最重要的工作模式——LLM 负责提出规律、设计测试点、生成公式代码符号计算引擎负责验证人类负责判断方向。你下一步可以按这个顺序实践把示例一到示例三在本地跑通感受 LLM 与符号计算的配合方式选一个自己领域里简单、可枚举的数学问题设计一个“LLM 提出 SymPy 验证”的小实验记录 LLM 输出和验证结果观察哪些问题类型适合这套流程哪些不适合再加一层形式化验证工具比如从 Lean 基础库开始把“符号验证”升级为“严格证明”。值得记住的一句话LLM 不会解决你解决不了的问题但它能大大缩短你从“不知道往哪走”到“有一个可验证的起点”的时间。这个起点往往是数学发现中最稀缺的东西。 大模型+符号计算：LLM参与数学研究的工程实践
1. 这篇文章真正要解决的问题先抛一个可能让你意外的问题一个数学能力远不如数学系本科生的语言模型为什么这两年反而成了数学研究工作流里频繁出现的角色如果你平时关注 AI 应用大概率看过不少类似说法LLM 会算错四则运算、面对稍微变形的应用题就崩溃、在数学推理上表现极其不稳定。这些批评没错。但如果你把“AI 做数学”理解成“让 AI 解数学题”那就把这个命题想窄了。真正让数学家、理论计算机科学家和做计算研究的工程师感兴趣的不是让模型去参加奥赛而是把 LLM 嵌入到数学研究的完整工作流里——从生成猜想、辅助证明、检查反例到把论文里晦涩的推导变成可执行的代码。这篇文章要拆解的就是“AI 尤其是 LLM 在重大数学发展中到底能干什么”。我会先明确概念边界再讲清楚 LLM 在数学研究中真正被验证过的使用方式接着给出一套可以照着跑的环境准备和完整示例代码最后梳理常见误区和工程建议。读完你会发现LLM 对数学的价值不是“替代大脑”而是“放大动作”——它不能替你证明定理但能把探索问题的摩擦成本降到近几年最低。需要说明的是本文不讨论任何未经公开资料证实的“AI 独立证明大定理”的夸张叙事。真实情况是目前绝大多数成功的案例都是人类数学家负责方向判断AI 负责局部推理、符号操作、反例搜索和代码实现。这个分工本身就是值得认真研究的工程问题。2. 基础概念与核心原理2.1 什么是“AI 参与数学发展”如果你去读数学史的经典叙事重大突破通常被描述成某个天才灵光一现的产物。但真实的研究过程远没有那么浪漫数学家大多数时间在做的是大量符号计算、模式识别、特殊情形枚举、假设试错和反例搜索。这些动作有一个共同点——它们规则性强、上下文明确、失败成本低恰恰是大模型相对擅长的领域。所以“AI 参与数学发展”并不是指 AI 独立证明黎曼猜想而是指以下能力的组合在给定数学对象族中寻找规律提出可验证的猜想对已有证明文本进行结构梳理辅助发现逻辑缺口将数学推导转化为可执行的符号计算代码在大规模搜索空间中高效定位反例或构造性示例。这些能力单独拿出来都不算“革命”但叠加在一起实际改变的是数学家的研究节奏。2.2 LLM 在数学任务中的三层能力模型根据实际使用经验可以把 LLM 的数学能力分为三层来理解很多关于“AI 数学能力行不行”的争论其实是因为只看到了某一层。第一层是语言理解与任务解析。LLM 能读入一段带有大量符号和术语的数学描述理解“已知什么、要求什么、约束条件是什么”。这一层做得好的模型即使计算能力一般也能把问题重新组织成清晰的形式化表达。这也是为什么“让 LLM 先复述问题再解题”通常比直接给答案效果更好。第二层是符号操作与规划。包括代数展开、方程变形、证明步骤规划等有一定规则性的操作。这一层 LLM 的表现介于“可用”和“不可用”之间短步骤操作可靠长链条推理会衰减。这也是推理时增加思考链能明显提升准确率的原因。第三层是创新性推理——即从零构造一个没见过的新定理或新证明。这一层目前远未达到可靠水平但正因为如此它成为了人机协作的核心地带LLM 提供候选路径人类负责审慎判断。把握这层模型你就会明白为什么现在数学领域用得最多的 AI 工具不是专门训练的“数学大模型”而是通用 LLM 配合符号计算引擎如 SageMath、Mathematica的混合架构。2.3 符号计算引擎与大模型的互补关系很多开发者容易把“数学 AI”等同于“用大模型解题”但实际上目前能真正落地到研究工作流中的方案大多数是LLM 符号计算引擎的组合。符号计算引擎这里指 SageMath、Mathematica、SymPy 这类工具擅长精确计算、公式推导、代数验证它们的缺点是需要人用代码描述任务不支持自然语言交互。大模型正好补上这层交互短板——它能理解自然语言描述的数学问题把它翻译成符号计算代码再调用引擎执行。反过来符号计算引擎的精确输出又弥补了 LLM 的“幻觉”缺陷模型给一个推断引擎可以负责严格验证。这个组合的价值在于它把“用自然语言做数学研究”变成了一个工程上可行的工作流而不是一个纯聊天式的“AI 猜答案”过程。3. 典型方向与已有关键案例在进入实操之前有必要把你需要知道的关键案例梳理一遍。这些案例来自公开发表的研究资料也最能说明 AI 在数学发展中真实的工作位置。3.1 机器学习辅助发现数学规律在深度学习兴起之前数学家就长期使用计算机枚举和统计分析来寻找规律。LLM 带来的变化在于它能提供更高层次的“模式描述层”——不是简单列数据点而是用自然语言描述观察到的规律并转化为形式化猜测。这类工作最有代表性的是利用机器学习聚类和模式识别在数论、组合学、几何学中发现新猜想。比如有研究通过监督学习在数学对象之间发现隐藏关联导致数学家注意到此前被忽视的规律并由此构造出严格的数学证明。这里机器不是证明者而是“提出值得验证的猜想”的引擎。3.2 定理证明器与 AI 的深度结合严格说数学发展最核心的活动是证明。近年来形式化证明领域发生了一次范式变化Lean、Isabelle、Coq 等证明助手从“专家工具”走向了“LLM 目标环境”。Lean 在数学形式化项目中的应用是一个标志性事件。其思路是由数学家把定理陈述和证明步骤输入到 Lean 环境中由系统严格验证每一步是否成立。而 LLM 在这个流程中扮演的角色是“策略生成器”——它观察当前证明状态生成下一步可能采用的形式化证明策略tactic再由 Lean 的验证核心确认是否有效。这种“LLM 生成候选动作 形式化系统验证”的架构把大模型从“不可靠的推理者”降格成了“可以被审查的方案建议器”。这是目前 AI 参与数学发展最被认可、也最有可能长期演进的方向。2024 年公开的 AI 在数学竞赛题中解决几何问题的案例也采用了类似思路借助语言模型生成证明路径再用符号引擎严格验证。3.3 代码生成将数学推导转化为实验工具这是 CSDN 读者最应该关注的视角对绝大多数工程师而言参与“AI 数学”的切入点不是证明定理而是利用 LLM 把论文中的数学描述变成可运行的实验代码。无论是复现论文里的算法、批量验证一个不等式对海量随机输入是否成立还是把一篇几个月前发表在 arXiv 上的方法在本地跑通LLM 的代码生成能力都已经足够带来明显的效率提升。这也是本文实战环节将要演示的核心场景。4. 环境准备与前置条件下面进入可以实际操作的部分。本节的示例会基于当前主流开源体系不做任何特殊定制保证你在一台普通开发机上就能跑通。4.1 基础环境要求Python 3.10 及以上建议 3.11SymPy 和相关科学计算库兼容性更好一台可联网的机器用于调用 LLM API或本机部署模型建议至少 8GB 内存本示例对 GPU 没有硬性要求一个可用的 LLM API KeyOpenAI、Anthropic、DeepSeek 等均可也可以使用本地模型如通过 Ollama 部署 Qwen2.5 或 Llama 3.1只要提供 OpenAI 兼容接口即可操作系统不限Windows / macOS / Linux 均可。4.2 Python 依赖安装建议先创建独立虚拟环境避免污染全局 Pythonpython -m venv .venv source .venv/bin/activate # Windows 下为 .venv\Scripts\activate安装必要依赖pip install sympy requests openai这里解释一下三个库的用途sympy符号计算引擎负责验证 LLM 给出的数学推断是否真的成立openai调用大模型 API。注意不管后端是哪个厂商只要兼容 OpenAI 接口协议代码逻辑基本一致requests如果你不想用 SDK可以用它直接请求 HTTP 接口本文示例中选择直接用openaiSDK更简洁。如果你使用本地模型例如通过 Ollama 启动一个 OpenAI 兼容服务只需要把base_url指向本机服务地址api_key填任意非空字符串即可。4.3 环境变量配置推荐把 API Key 放到.env文件或环境变量中不建议硬编码在 Python 脚本里。为避免额外引入第三方库本文直接使用os.getenv读取export OPENAI_API_KEY你的密钥 export OPENAI_BASE_URLhttps://api.openai.com/v1 export LLM_MODELgpt-4o-mini如果使用本地模型LLM_MODEL改成你拉取的模型名OPENAI_BASE_URL改成http://localhost:11434/v1。5. LLM 参与数学研究的两种实践模式在写代码之前你需要理解当前 LLM 参与数学发展的两种主流工作模式。把它们想清楚后面写代码时才不会迷失方向。5.1 模式一LLM 提出规律符号引擎验证这是最有数学研究味道的模式。流程是人工构造或让 LLM 生成一个待探索的数学对象集合LLM 对集合进行模式阅读提出一个归纳猜想将猜想写成形式化命题用 SymPy 等工具对大规模样本进行验证如果验证通过把猜想作为线索提交给数学家做严格证明如果失败让 LLM 修正猜想或缩小适用范围。这个模式里LLM 的角色是“探索助手”符号引擎是“验证者”。重要原则LLM 给出的结论本身没有权威性只有经过符号引擎或人工证明的结论才可信。5.2 模式二数学家提出猜想LLM 构造反例参考很多数学问题真正难的不是证明而是找到反例。LLM 擅长在灵活的空间里生成“可能性”这正好用于反例搜索。流程是给定一个研究中的猜想让 LLM 描述在哪些特殊边界条件下猜想可能不成立LLM 生成这些边界条件下需要验证的具体计算任务符号计算引擎执行精确计算并返回结果。这个模式能够显著压缩搜索空间——LLM 虽然不能保证找到反例但往往能提供人类直觉之外的“测试点”候选。这两种模式并不互相排斥。一个充分的“AI 辅助数学”工作流往往两者兼用先让 LLM 提出规律再让它思考边界条件最后用符号计算接管验证。6. 完整示例代码实现下面进入可落地的完整示例。这个示例模拟了一条简化的数学研究流水线让 LLM 观察整数数列提出规律然后用 SymPy 验证。6.1 示例一让 LLM 提出数列猜想并用 SymPy 验证这是一个最小演示目的是让你看到“LLM 符号计算”的完整配合方式。# 文件路径src/llm_math_demo/sequence_explorer.py import os from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) MODEL os.getenv(LLM_MODEL, gpt-4o-mini) SEQUENCE [0, 1, 4, 9, 16, 25, 36, 49, 64, 81] def ask_llm_guess(sequence): prompt f 观察以下整数数列 {sequence} 请用自然语言描述你发现的规律并给出一个你认为能生成这个数列的通项公式。 只需要描述规律和公式不要写额外解释。 resp client.chat.completions.create( modelMODEL, messages[{role: user, content: prompt}], temperature0.2, ) return resp.choices[0].message.content def verify_with_sympy(expression_str, n_values): from sympy import symbols, sympify, lambdify n symbols(n) expr sympify(expression_str) f lambdify(n, expr, math) results [f(k) for k in n_values] return results if __name__ __main__: guess ask_llm_guess(SEQUENCE) print(LLM 提出的规律) print(guess) # 用 SymPy 显式验证平方数通项公式 from sympy import n as sym_n formula n**2 checked [int(v) for v in verify_with_sympy(formula, range(10))] print(\nSymPy 验证 n^2 前 10 项) print(checked) print(\n与原数列一致, checked SEQUENCE)这段代码的核心逻辑是第 8 到 12 行初始化 OpenAI 兼容客户端第 14 到 15 行定义待研究的整数数列ask_llm_guess让模型基于数列给出规律描述verify_with_sympy接收一个字符串形式的数学表达式用 SymPy 把它解析成函数再批量求值最后对比验证结果与真实序列。运行方式python src/llm_math_demo/sequence_explorer.py成功输出大致如下LLM 提出的规律 这个数列是 n^2 的取值其中 n 从 0 开始取值每一项等于 n 的平方。 SymPy 验证 n^2 前 10 项 [0, 1, 4, 9, 16, 25, 36, 49, 64, 81] 与原数列一致 True这个例子看似简单但它展示了一个完整的人机协同闭环LLM 负责从序列中识别模式并给出通项公式SymPy 负责把公式变成可执行代码并验证正确性。如果把SEQUENCE换成更复杂的数学对象比如某个群论相关的特征值序列或者某个组合数序列的前若干项这个流程可以直接复用。6.2 示例二让 LLM 设计反例测试点接下来模拟更接近真实数学研究的工作流。我们给定一个常见的不等式猜想让 LLM 提出可能导致不等式失败的边界条件然后用数值计算验证。这里要演示的不等式是一个非常基础的数学事实实际成立。我们使用它的目的是演示“怎么用 AI 设计反例搜索实验”而不是真的要找它的反例。# 文件路径src/llm_math_demo/counterexample_search.py import os import random from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) MODEL os.getenv(LLM_MODEL, gpt-4o-mini) PROPOSITION 对任意正实数 a, b不等式 (a b)^2 4ab 恒成立。 def ask_llm_for_test_cases(): prompt f 有以下数学命题 {PROPOSITION} 请设计 10 组可能导致该命题不成立的测试输入 (a, b)。 只需要给出 (a, b) 数值列表不要解释。 resp client.chat.completions.create( modelMODEL, messages[{role: user, content: prompt}], temperature0.5, ) content resp.choices[0].message.content return content def parse_pairs(text): # 简单解析模型返回的坐标对容忍一些格式差异 import re pairs re.findall(r\(\s*(-?\d\.?\d*)\s*,\s*(-?\d\.?\d*)\s*\), text) return [(float(a), float(b)) for a, b in pairs] def check_inequality(a, b): return (a b) ** 2 4 * a * b if __name__ __main__: print(LLM 建议的测试点) suggestions ask_llm_for_test_cases() print(suggestions) pairs parse_pairs(suggestions) # 如果 LLM 返回格式不理想补充几组随机边界值 pairs.extend([(0.0001, 9999.0), (-1.0, 0.5), (1e-10, 1e10)]) print(\n实际用于验证的测试点数量, len(pairs)) failed [] for (a, b) in pairs: if not check_inequality(a, b): failed.append((a, b)) if failed: print(以下测试点出现反例) for item in failed: print(item) else: print(所有测试点均通过未发现反例。)运行方式python src/llm_math_demo/counterexample_search.py如果一切正常你会看到类似输出LLM 建议的测试点 可能的测试点包括 (0, 0)、(1, -1)、(-0.5, -0.5) 等边界情况。 实际用于验证的测试点数量 13 所有测试点均通过未发现反例。这个例子的意义在于check_inequality才是真正值得信任的判断逻辑LLM 只是“建议了值得去检查的地方”。在实际数学研究中你也应该按照这个思路设计系统——LLM 的定位永远是“建议器”而不是“验证器”。需要注意如果 LLM 返回了非数值格式parse_pairs可能解析不到。这时你可以人工从控制台输出的文本里挑选坐标或者调整check_inequality让它直接接受更宽泛的输入。在实际项目中更稳妥的做法是用结构化输出JSON mode或再加一层解析校验。6.3 示例三把论文中的数学公式转成可验证代码这个示例最贴近工程实践。我们模拟一个场景你刚读了一篇论文里面给出了一种特殊矩阵的构造公式你想快速验证它是否满足论文声称的性质。让 LLM 帮你把公式翻译成 SymPy 代码你只需要写一个简短的任务描述。# 文件路径src/llm_math_demo/paper_formula_to_code.py import os from openai import OpenAI from sympy import Matrix, symbols, simplify client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) MODEL os.getenv(LLM_MODEL, gpt-4o-mini) FORMULA_DESC 请把以下数学描述转换成 SymPy 代码 构造一个 3 阶矩阵 A满足 A[i][j] i * j 1其中 i, j 从 1 开始。 然后计算 A 的行列式。 只输出 Python 代码不要解释。 def generate_sympy_code(): resp client.chat.completions.create( modelMODEL, messages[{role: user, content: FORMULA_DESC}], temperature0.0, ) return resp.choices[0].message.content if __name__ __main__: code generate_sympy_code() print(LLM 生成的 SymPy 代码) print(code) print(\n---- 执行代码 ----\n) # 直接执行模型生成的代码 # 注意LLM 生成的代码可能包含非 SymPy 写法生产环境需要加沙箱 exec_namespace {Matrix: Matrix, symbols: symbols, simplify: simplify} exec(code, exec_namespace)运行后模型可能会生成类似这样的代码from sympy import Matrix A Matrix([[1, 2, 3], [2, 3, 4], [3, 4, 5]]) det_A A.det() print(det_A)执行结果0这个结果说明该矩阵的行列式为 0即它不是满秩矩阵——这个发现可能意味着论文中某个步骤需要进一步审视或者你需要检查初始条件是否设置正确。需要特别提醒直接exec大模型生成的安全相关代码非常危险。示例中只是因为任务简单、代码来源信任度可控才这么写。在实际项目里应当在沙箱或容器中运行并且对生成的代码做静态审查后再执行。7. 运行结果与效果验证7.1 如何判断你的流水线“真的有效”不是程序跑通就代表有效。一个合格的“LLM 辅助数学研究”系统至少要满足以下条件结果可复现同一个问题重复运行LLM 给出的建议可能有差异但最终经过符号验证后的结论应该稳定。验证逻辑独立验证部分不应依赖 LLM 生成的代码来判断正确性。更稳妥的做法是LLM 只输出数学推断验证逻辑由开发者手写。有失败切换当 LLM 输出无法解析或无法执行时系统应当有降级方案比如重新调用一次或提示人工介入。7.2 验证步骤清单第一阶段检查 LLM 输出格式。如果输出包含代码块标记或 Markdown 语法需要先清洗。第二阶段执行符号验证观察是否有异常或断言失败。第三阶段人工审查关键结论。LLM 给出的规律只有在人工认可后才具备“研究线索”价值。如果某一步失败优先看控制台中打印的 LLM 原始输出再检查解析逻辑是否太严格。8. 常见问题与排查思路问题现象可能原因排查方式解决方案LLM 返回内容包含 Markdown 代码块标记提示词中未要求纯文本输出打印原始响应用于排查在提示词中明确“只输出代码不要代码块标记”或用正则去除反引号SymPy 执行报错SyntaxErrorLLM 生成的代码与当前 SymPy API 不兼容查看堆栈信息定位具体行在提示词中指定 SymPy 版本或让模型先生成伪代码由开发者翻译解析坐标对为空模型返回了自然语言而非严格数值列表检查原始输出格式使用 JSON mode 或增加 few-shot 示例数值验证结果与直觉不符数学公式本身有误或边界条件设置错误人工手算小规模样例先缩小范围验证再扩大到完整样本调用 API 超时或限流任务复杂导致模型推理时间过长检查 API 错误码和网络状况增加重试机制或切换到响应更快的模型本地模型输出质量不稳定模型参数量较小或未设置合理温度尝试 temperature0换用更大尺寸模型或增加推理步数9. 最佳实践与工程建议9.1 把 LLM 当成“实习生研究员”来管理我在多个数学相关项目中总结出一条经验最适合 LLM 的定位不是“权威解答者”而是“可以无限提建议但需要逐条验证的实习生”。这意味着你在设计系统时天然要加一层审核、验证和容错机制。好的做法是设定三条纪律不信任模型的数学结论只信任它提供的线索所有经过验证的结论要立即形成可回归的测试用例每一次探索都要能被日志记录并回溯。这三条纪律能避免“AI 给出一个貌似合理但实际错误的结论被当作研究线索继续投入”的尴尬局面。9.2 使用结构化输出提升解析稳定性很多人一开始用 LLM 做数学辅助时最痛苦的阶段其实是“清洗模型输出”。建议从一开始就要求模型返回 JSON并用代码校验 JSON Schema。下面是一个简化示意from openai import OpenAI import json, os client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) resp client.chat.completions.create( modelos.getenv(LLM_MODEL), messages[ {role: system, content: 你只输出 JSON不要输出其他内容。}, {role: user, content: 请观察数列 0,1,4,9,16,25输出 JSON{\pattern\: \\, \formula\: \\, \confidence\: 0.0}}, ], response_format{type: json_object}, ) data json.loads(resp.choices[0].message.content) print(data)这比让模型自由输出文本再正则解析要可靠得多。如果你的后端模型不支持response_format参数可以通过系统提示词约束再用严格的 JSON 解析函数处理。9.3 用“验证锚点”对抗幻觉经验表明给 LLM 提供“验证锚点”能显著提升数学任务的表现。所谓验证锚点就是你预先告诉它某个中间结论或代数结果是多少让它在推理时以此为界之后的所有步骤都必须与锚点一致。例如在提问时加上在你开始推理之前请注意当 n3 时这个序列的真实值是 9。这个简单技巧能大幅减少模型在长推导中“跑偏”的概率。9.4 安全边界与代码执行风险必须强调不要直接在生产环境执行 LLM 生成的代码。推荐的安全执行方式包括在 Docker 容器或虚拟化沙箱中执行限制执行超时时间比如 10 秒不授予网络权限给执行环境输出只允许标准 stdout/stderr禁止读写任意文件对代码使用静态分析工具做基础过滤。这些措施不仅能防止提示注入也能避免模型生成的错误代码因为意外副作用破坏你的开发环境。9.5 与形式化证明工具的对接建议如果你想把本文的方案推进到更严格的方向下一步是接入 Lean 或 Isabelle。对工程师来说这项工作的技术关键词是将自然语言数学问题翻译为 Lean 策略序列再由 Lean 验证。由于 Lean 的类型系统和策略语言相对复杂建议从一个已有数学形式化项目的基础库开始而不是从零搭建。10. 总结与后续学习方向一个逐渐清晰的共识是AI 和 LLM 在数学发展中的角色已经不再停留在“能不能做题”的讨论层面而是进入了“如何嵌入研究工作流”的工程问题阶段。本文通过几个可运行的示例展示了最基础也最重要的工作模式——LLM 负责提出规律、设计测试点、生成公式代码符号计算引擎负责验证人类负责判断方向。你下一步可以按这个顺序实践把示例一到示例三在本地跑通感受 LLM 与符号计算的配合方式选一个自己领域里简单、可枚举的数学问题设计一个“LLM 提出 SymPy 验证”的小实验记录 LLM 输出和验证结果观察哪些问题类型适合这套流程哪些不适合再加一层形式化验证工具比如从 Lean 基础库开始把“符号验证”升级为“严格证明”。值得记住的一句话LLM 不会解决你解决不了的问题但它能大大缩短你从“不知道往哪走”到“有一个可验证的起点”的时间。这个起点往往是数学发现中最稀缺的东西。