这次我们看一个偏“反直觉”的问题菲尔兹奖得主陶哲轩的公开观点经常被总结为“顶级数学思维是可以训练的”但为什么当前的大模型哪怕已经能在竞赛题、高难评测集上拿高分却仍然谈不上“学会顶级数学家的思维”更关键的是为什么普通人反而可以通过学习那些思维方法获得提升而大模型却卡在某个地方这不是一个纯哲学问题而是一个工程问题。大模型在数学推理上的表现本质上是“下一个token预测”与“主动构造反例、自我反驳、概念判断”这两种能力之间的差距。本文会把“陶哲轩式思维”拆解成可操作的认知流程再把它映射到大模型的能力评测、提示词工程、API 工作流和本地部署性能观察上。无论你是 AI 应用开发者、算法工程师还是数学教育工作者都能从这套流程里找到可以立刻验证的部分。全文信息密度比较高先给结论再给方法最后给代码和排查清单。1. 核心能力速览先把这篇文章要讨论的内容做一个速览能力项说明技术主题大模型数学推理能力评析与可落地工作流设计核心问题AI 为什么擅长“计算和检索”却不擅长“概念判断和反例构造”分析对象以陶哲轩式数学思维为参照评估 LLM 的推理边界适用对象AI 工程师、提示词工程师、科研人员、数学教育从业者可验证的能力维度计算还原、概念理解、反例构造、自纠错、可解释性可落地工具思维链提示词、候选解生成、符号计算验证、批量评测脚本接口能力推荐使用 OpenAI 兼容 API 接入可批量跑题批量任务支持评测集批量调用需要自行设计队列和失败重试性能观察维度输出 token 长度、推理延迟、上下文占用、本地推理显存占用主要短板模型缺乏“主动否定自己”的训练目标验证环节需要外部工具补齐需要明确一点本文不是一篇“陶哲轩名言摘录”而是从“顶级数学家的思维方法可以训练”这个判断出发反过来看当前大模型的能力边界。只有先搞清楚“AI 做不到什么”才知道怎么用工程手段补上那些缺位。2. 陶哲轩式思维到底在说什么很多人一听到“顶级数学家”第一反应是“天赋”“灵感”“超强计算力”。但陶哲轩在大量公开课、访谈和写作中反复传达的恰恰是另一套东西数学思维是一组可以被拆解、练习、反馈的习惯而不是某种玄学灵感。这些习惯大致可以归纳为以下几条先算小例子。面对一个大问题不急着抽象先手动算几个具体的小例子找规律。主动找反例。一个命题看起来成立第一步不是急着证明而是先尝试推翻它。多角度重述。同一个问题用代数、几何、概率、组合等不同语言重写往往能暴露出隐藏结构。把难题分解成可验证的小块。不追求一步到位而是把“大证明”拆成若干“可独立验证的引理”。解释给别人听。能把一个推理链清楚地讲给外行代表自己真正理解了。这些习惯有一个共同点它们都是“可控的认知动作”而不是“灵光一现”。换句话说普通人完全可以通过刻意练习逐步接近这种思维方式。现在我们把这个清单翻译成大模型的行为语言先算小例子 → 让模型先输入几个数值观察输出是否合理。主动找反例 → 让模型在完成证明之前先尝试构造反例。多角度重述 → 让模型把同一道题用三种数学语言重新表述。分解成小块 → 让模型每一步只输出一个可验证的断言而不是整篇证明。解释给别人听 → 让模型用非专业语言解释关键步骤。这五条在提示词工程里都能做但问题在于大模型执行得并不稳定。原因是训练目标本身是“预测下一个 token”而不是“验证一个命题是否成立”。所以模型经常会生成一个看起来流畅、实际上有漏洞的证明并且不会主动发现漏洞。这就是整个问题的核心顶级数学思维是“反思性”的而大模型的默认行为是“生成性”的。3. 为什么普通人的思维方式反而可迁移普通人能通过方法论练习提升数学思维大模型却很难差距不在于“聪明程度”而在于学习机制和信息组织方式。普通人学习数学思维时获得的是一种“可迁移策略”。比如“先找反例”这条策略学会了以后换一道新的命题依然能主动执行。这是一种跨任务的认知工具它不绑定在具体数据上。大模型学习到的是 token 序列的条件概率分布。模型会记住大量“证明风格”和“结论模式”但它的默认推理路径是“顺着概率平滑地继续”而不是“主动搜索一个让当前断言失败的反例”。一个直接后果是给大模型一道它没有见过的数学题它能输出与训练数据里“正确证明”风格相似的文本但这个证明可能在第 3 步就悄悄失效了。你让它“检查自己的答案”它往往会说“这段证明是对的”因为对模型来说“这段证明看起来像对的”。这不是说大模型无法改进。实际上通过强化学习、思维链微调、搜索外部验证器模型可以部分获得“自我纠正”的能力。但关键在于推理时计算必须有“外部反馈信号”否则模型只是在用更多 token 把错误包装得更完整。这里也引出了普通人的真正优势人可以主动“否定自己”而大模型的默认参数里没有“否定按钮”。4. 大模型数学推理能力评测维度想验证“AI 是否学会顶级思维”不能只看最终答案对错。需要一套更细的评测维度。这里给出一个适合人工或脚本执行的五维评测框架。4.1 计算还原能力这个维度最传统给定一道题模型能否算出正确数值结果。测试目标确认模型基础计算能力是否正常。输入示例一道不定积分、一个线性方程、一个数值求和。判断标准最终数值正确且关键中间步骤可复现。注意这一项强并不代表模型有数学思维它只代表“检索到正确答案”或“正确执行了符号操作”。4.2 概念理解能力测试目标模型是否理解某个数学概念的本质而不是只匹配关键词。输入示例“请用一句话解释什么是紧致性但不能使用拓扑学教材里的原句。”判断标准解释是否准确、是否原创、是否能应对追问。这类测试最能暴露模型对数学概念是“检索式理解”还是“结构性理解”。如果换一个表述就答不好说明它没有真正形成概念结构。4.3 反例构造能力这是最接近“陶哲轩式思维”的一个维度。输入示例“给定命题任意连续函数都在某点可导。这个命题成立吗如果不成立请给出一个反例。”模型需要给出形如f(x)|x|在x0处连续但不可导的反例并说明为什么它构成反例。判断标准反例是否正确、是否完整、是否对边界条件有讨论。这是多数通用 LLM 表现不稳定的地方。模型可能知道|x|是反例但当你把命题改成“任意连续函数都在无穷多个点不可导”它可能就不知道如何构造分段函数了。4.4 自纠错能力测试目标给定一个含有隐蔽错误的证明模型能否找到错误并修正。输入示例给出一个“所有实数都等于它的相反数”这种明显有问题的伪证明观察模型是否直接认同还是能指出哪一步破坏了运算规则。判断标准是否定位到错误行、是否给出修正建议、修改后是否仍保持原证明结构。这里有一个常见现象模型会指出“步骤 3 有问题”然后给出的修正版本依然是错的。这说明它已经学会了“要被指出错误后再修改”的表层模式但没有真正理解错误根源。4.5 可解释能力测试目标模型能否把一个高深概念解释给“不熟悉该领域的人”听。输入示例“请用初中生能懂的方式解释为什么素数有无穷多个。”判断标准是否避免术语堆砌、是否保留核心逻辑、外行能否听明白。这一项往往和“真正理解”高度相关。可解释性差的模型通常只是从训练集中捞了一段高层次的拼凑式回答。5. 用 LLM 辅助数学推理的可落地工作流理解能力边界之后我们来设计一个能跑的工程流程。核心思想是把 LLM 当作“候选解生成器”而不是“最终裁判”。一个标准工作流如下定义问题输入一个命题或一道题。生成多个候选解让模型用不同策略独立生成 3 个候选解。自动验证用符号计算、数值采样、外部定理证明器去验证候选解。反例搜索针对每个候选解的关键断言强制模型构造反例。人工复核把验证结果和置信度汇总给人类专家。输出结构化结果包括候选解、验证状态、反例、未解决问题列表。这里的核心工程原则模型负责“提出”验证器负责“判断”。5.1 反例优先提示词模板我们可以在提示词里显式加入“先找反例再证明”的规则把它变成模型的推理流程你在解决一个数学问题。请严格遵守以下步骤 1. 先尝试构造一个反例推翻题目中的命题。这一步优先于一切。 2. 如果找不到反例说明你尝试了哪些反例方向解释为什么失败。 3. 然后给出一个候选证明。 4. 最后反过来检查你的证明每一步是否严格成立有没有偷换条件 5. 如果发现证明有漏洞重新回到第 1 步再找反例或修改证明。 输出格式 - 反例搜索结论 - 候选证明 - 自我检查结果 - 最终结论这个模板的核心不是让模型“认真思考”而是改变它的输出顺序把“找反例”强制前置。对很多模型来说这一步能显著降低“直接生成错误证明”的概率。5.2 带验证的工具式工作流如果模型本身不擅长自我检查我们可以引入外部验证器。一个最轻量的方案是把模型生成的数学表达式用sympy或scipy进行数值验证。示例让模型推测一个数列的通项公式然后用程序验证前 100 项。import sympy as sp n sp.symbols(n) # 模型给出的候选通项公式 candidate n**2 2*n 1 # 真实数列前几项这里以题目实际数据为准 true_seq [4, 9, 16, 25, 36] # 验证前 5 项 for i, val in enumerate(true_seq, start1): predicted int(candidate.subs(n, i)) status OK if predicted val else FAIL print(fn{i}: predicted{predicted}, true{val}, {status})这类验证的价值是不依赖另一个大模型来判断而是依赖精确计算结果可复现、可审计。6. 接口 API 与批量评测示例如果你要跑一份评测集批量测量不同模型在“反例构造”维度上的表现可以直接用 OpenAI 兼容接口做脚本化调用。6.1 批量评测脚本思路先准备一个评测集文件每行一个题目[ { id: 1, type: counterexample, problem: 命题任意连续函数都在某点可导。请判断命题是否成立如果不成立给出反例。 }, { id: 2, type: self_correction, problem: 下面的证明哪里错了1. 设 ab2. 两边同乘 a得 a^2ab3. 两边同减 b^2得 a^2-b^2ab-b^24. 分解因式得 (ab)(a-b)b(a-b)5. 两边同除 (a-b)得 abb6. 因为 ab所以 2bb7. 所以 21。 } ]然后用 Python 脚本批量请求import json import time from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, # 本地服务地址按实际环境替换 api_keyEMPTY ) def run_problem(problem): prompt ( 请先尝试构造反例再给出证明或解释。\n f题目{problem}\n 输出格式反例搜索结论 / 候选证明 / 最终结论。 ) response client.chat.completions.create( modelyour-model-name, # 按实际模型名称替换 messages[{role: user, content: prompt}], temperature0.2, max_tokens1024, timeout120 ) return response.choices[0].message.content with open(eval_set.json, r, encodingutf-8) as f: dataset json.load(f) for item in dataset: try: output run_problem(item[problem]) print(f[{item[id]}] {item[type]} - {output[:100]}) except Exception as e: print(f[{item[id]}] error: {e}) time.sleep(1) # 控制请求频率这里有几个工程经验必须把每个请求包装成独立函数加超时和异常捕获防止单题失败导致整个评测集中断。批量任务建议写结果到文件而不是只打印到控制台。每道题之间加time.sleep避免触发服务端的速率限制。评测报告要保留原始输出不要只保存你人工判断的结论。6.2 批量任务队列设计如果评测集很大建议加一个简单的任务队列。不一定要上消息队列用 Python 的ThreadPoolExecutor也可以快速实现from concurrent.futures import ThreadPoolExecutor, as_completed def safe_run(item): try: return {id: item[id], status: success, output: run_problem(item[problem])} except Exception as e: return {id: item[id], status: error, message: str(e)} results [] with ThreadPoolExecutor(max_workers3) as executor: future_map {executor.submit(safe_run, item): item for item in dataset} for future in as_completed(future_map): results.append(future.result()) with open(results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)注意并发数不要开太高。数学推理是长文本输出任务并发过高会把服务端的显存和带宽直接打满。一般 2 到 4 个并发已经足够跑通流程。7. 资源占用与性能观察数学推理任务和普通文本生成的区别在于输出文本可能很长且中间步骤多。如果你在本地部署模型需要重点观察以下指标。7.1 本地推理观察方向显存占用模型加载后的静态占用加上生成过程中的动态占用。复杂推理题会让上下文不断增长导致显存缓慢上升。吞吐量每秒生成多少个 token。数学推理往往需要长输出吞吐低会严重影响批量评测效率。上下文长度模型需要同时保留题目、历史步骤、自我检查结论。长上下文会显著增加计算量。请求排队同时多个批量请求时服务端是否出现排队延迟。观察方法在生成任务运行时用nvidia-smi -l 1查看显存变化或用服务端日志查看每个请求的实际处理时间。7.2 如何控制资源开销限制max_tokens。反例搜索和候选证明不需要无限输出一般 1024 到 2048 token 足够。先小参数测试再开批量。先用 3 到 5 道题跑通流程确认没问题再放大。减少无意义的自我检查轮次。让模型只“自检一次”而不是反复循环否则输出长度会成倍增长。如果追求高吞吐优先考虑云端 API而不是本地小显存跑长上下文推理。没有固定的显存数值可以套用到所有模型因为不同参数量、量化方式、上下文长度差异很大。更稳妥的判断是以你实际本机的nvidia-smi和吞吐数据为准先跑小批量再决定是否扩大并发。8. 常见问题与排查方法在实践 AI 数学推理时常见问题集中在“模型验证不可靠”“批量任务中断”“性能消耗过大”三类。下面给出一份排查清单。问题现象可能原因排查方式解决方案模型能算出正确答案但过程是错的模型记住了答案没有真正理解逻辑换一道同类型但结构不同的题增加反例搜索环节强制模型先找反例让模型检查自己的证明它总说“证明正确”缺乏外部反馈信号自检与推理是同一个网络把模型输出交给符号计算工具验证引入 sympy、计算器或定理证明器做独立验证多轮交互后模型忘了最初的条件上下文过长或注意力衰减检查输入的上下文顺序把关键已知条件放在所有提示词的最前面批量调用时部分题目中断网络超时或服务端速率限制查看服务端日志和报错信息增加超时时间、降低并发、加失败重试本地推理显卡显存不足模型太大或上下文过长观察 nvidia-smi 动态占用换小模型、减少 max_tokens、使用量化版模型给出的反例不构成反例模型只是检索了一个相似概念人工复核反例的每一步运算增加“反例核验”提示要求反例每一步可执行API 返回内容被截断max_tokens 设置过小检查输出末尾是否完整增大 max_tokens 或拆分为多步请求8.1 反例核验提示词如果模型给出的反例总是不完整可以在提示词末尾追加一句核验要求在给出反例后请额外完成以下核验 1. 列出反例函数/对象的所有定义域边界。 2. 验证该对象是否满足题目的所有前置条件。 3. 指出题目结论在哪个具体点上被推翻。 4. 如果无法完成上述核验说明该候选反例无效。这能把“看似合理的反例”筛掉一部分。但要注意这个环节依然可能有遗漏最终人工复核仍然不能省。9. 最佳实践与使用建议从工程角度看把大模型接入数学推理流程最安全、最有效的姿势是“分工明确”。9.1 模型负责发散工具负责证明大模型擅长的是在搜索空间中快速提出候选方案一个可能反例、一个证明思路、一个数值规律。但它不擅长保证每一步推导严格。所以工程上应该把验证环节全部交给精确工具。数值规律用scipy、numpy快速采样。符号推导用sympy验证等式是否成立。逻辑证明交给形式化验证工具或至少由人复核。9.2 给人留最终判断权尤其是“数学教育”场景AI 生成的内容不能直接当作标准答案发给学生。它更适合作为一个“苏格拉底式陪练”由 AI 生成多个候选思路由学生判断哪个方向更可行再一起验证。这既发挥了 AI 的发散优势又保留了对学习者的思维训练价值。9.3 维护一套自己的反例库这是最容易被忽略但价值很高的工作。每次让 AI 构造反例你人工验证并修正后把它存进一个结构化文件{ proposition: 任意连续函数都在某点可导, counterexample: f(x)|x|在 x0 处连续但不可导, check: 当 x0 时导数为 -1当 x0 时导数为 1左右导数不相等故不可导, source: 实分析基础反例 }长期积累后你可以用这批反例库去评测不同模型看哪个模型真正学会了“反例优先”的推理风格。这才是从“模型能力分析”走向“模型能力测评”的关键一步。9.4 教育场景的合规提醒如果你把 AI 数学推理能力用于教学、出版或公开传播要特别注意版权和内容合规数学题目、教材内容可能受版权保护不要批量抓取后直接喂给模型再全文发布。涉及学生数据、评测成绩、实名信息时务必匿名化。AI 生成的证明和解答务必经过人工复核后再对外发布避免传播错误结论。10. 总结与下一步陶哲轩式思维之所以对普通人可迁移是因为它本质上是一组“认知动作”先算小例子、主动找反例、多角度重述、分解成小块、解释给别人听。这些动作不依赖天赋而依赖训练和反馈。大模型之所以还没学会这套思维根本原因是它的默认训练目标不是“寻找并验证一个命题的真假”而是“生成一段看起来合理的文本”。模型可以模仿证明的语法却难以保证证明的语义。要跨越这个差距不能指望模型“自我反思”就能做到必须在工程链路里引入外部验证器、反例优先提示词和人工复核。如果你准备自己动手试建议按这个顺序来找一道你熟悉的数学题用“反例优先”提示词模板跑一次观察模型的自我检查是否有效。把模型生成的候选证明交给sympy或数值工具验证体验“模型提出、工具判断”的流程。建立一个小型评测集至少包含 5 道反例构造题和 3 道自纠错题跑一批模型对比输出质量。慢慢积累自己的反例库用于后续模型选型和能力测评。最后给你一个可以直接用的小技巧下次让 AI 解数学题时别急着让它证明先强制它写三行“为什么这个命题可能是错的”。你会发现真正让你有收获的不一定是模型的最终答案而是你为了判断它哪里错了所完成的那些推理步骤。