AI会不会杀死数学先给结论不会。它会杀死的是“只会套公式做题、背标准证明、把算力当能力”的机械化劳动。如果把“数学”理解为一种发现规律、构造证明、建立理论体系的人类活动那 AI 目前能做的只是其中很小一段算得更快、检索得更全、模仿得更像。真正需要担心的不是数学被杀死而是很多人会误把 AI 输出的“像答案的东西”当成正确答案整个推理链条因此断掉。这篇不聊空洞的概念给一套可以自己在本地跑起来的 AI 数学能力压测方案。内容包含三层题库怎么设计、本地部署和 API 调用两条路线怎么选、批量评测脚本怎么写、以及如何用 sympy 这类符号计算工具去交叉验证 AI 的答案。看完你可以把同一个问题集丢给不同模型量化比对它们的数学能力而不是凭感觉下结论。1. “AI 杀死数学”的焦虑到底来自哪这个焦虑有三个现实来源。第一个是作业场景。学生把题拍给 AIAI 给出完整解答作业系统判定正确。当 AI 能做对大部分教材练习题时“数学作业”这个评价环节就开始失真。第二个是证明场景。AI 面对证明题时会生成结构完整但未必正确的证明中间可能藏着编造的引理、错误的符号变换、循环论证。对基础不够扎实的人来说这种错误极难识别。第三个是叙事场景。数学一直被当作“人类智能的最后堡垒”一旦 AI 在竞赛题上表现惊艳就会触发“人类还有什么可学”的恐慌。但把这三个来源拆开看核心都不是“数学被消灭”而是“AI 输出被直接采信”。AI 不会杀死数学错误的验证流程会杀死数学教育。所以这篇文章真正要解决的问题是如何建立一个可信的验证闭环让 AI 生成数学内容同时用工具和人审给它兜底。2. AI 数学能力现状速览能做什么不能做什么先给一张当前大模型数学能力的通用观察表。这里的表述偏保守具体水平随模型、量化版本、提示词和题目难度波动需要以本机实测为准。能力项通用水平判断主要风险标准计算求导、积分、极限、解方程较好常规题正确率较高表达式格式不稳定常数项处理随意初等代数变形不错基本能跟步骤可能跳步关键变换缺少解释竞赛类推理题视模型能力而定需逐题实测稳定性差同一题可能时对时错证明题能生成“像证明”的文本编造引理、循环论证、前提漏用开放探索与新定理只能提供思路参考幻觉风险很高数学史、符号语义解释可辅助参考需要交叉核对原始资料这张表说明一件事AI 更适合当“计算脚手架”不适合当“判定裁判”。凡是结果能机器验证的环节比如符号积分、代数化简、数值求解AI 可以参与计算链路凡是需要人类审美和长链条信任的环节比如构造新证明、判断一个证明是否本质正确AI 仍然只是辅助。这也决定了后续压测方案的侧重点用可自动判定的题目做批量测试用符号计算工具做交叉验证把 AI 的输出从“文本”变成“可检查的对象”。3. 可复现的 AI 数学压测方案三层问题设计要客观评估 AI 数学能力不能拿三五道题凭感觉下结论。建议设计三层题库分别覆盖三种不同性质的数学任务。第一层是计算题。包括求导、积分、极限、解方程、矩阵运算。这类题有标准答案能用 sympy 等符号计算库自动判定适合批量跑是成本最低的评测层。第二层是证明题。包括数论、几何、代数中的经典定理证明。这类题没有唯一答案但可以用“步骤完整性、引理真实性、逻辑链条是否闭合”作为人工评分维度。第三层是开放探索题。比如“如何构造一个在所有非平凡点上连续但处处不可导的函数的直观例子”这类问题不要求唯一答案重点观察模型的思路组织、自我纠错和追问能力。题目集可以用 JSON 组织。下面是一个最小可用的结构{ tests: [ { id: calc-001, category: computation, level: basic, question: 计算 ∫(3x^2 2x 1) dx, answer: x^3 x^2 x C, check_mode: sympy }, { id: calc-002, category: computation, level: basic, question: 求 d/dx (x * sin(x)), answer: sin(x) x * cos(x), check_mode: sympy }, { id: proof-001, category: proof, level: intermediate, question: 证明质数有无穷多个, answer: 欧几里得经典证明需检查引理真实性, check_mode: manual } ] }题目数量建议每层至少 10 题三层总共 30 题以上才有统计意义。评测时要固定 prompt 模板控制 temperature 在 0.2 左右关闭流式输出否则结果没有可比性。4. 环境准备API 调用与本地部署两条路线跑数学评测有两个路线调用现成的兼容 API或在本地部署开源模型。两者目标一致都是为了拿到稳定的模型输出。4.1 路线一调用云端或兼容 API很多模型服务都提供 OpenAI 兼容的 chat/completions 接口。评测脚本只需要改 API 地址、模型名和鉴权头。先看一个 curl 级别的连通性测试curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [ { role: system, content: 你是一名数学老师。请逐步推理并用符号表达式明确写出最终答案。 }, { role: user, content: 计算 ∫(3x^2 2x 1) dx } ], temperature: 0.2, max_tokens: 1024, stream: false }这里用的是本地 Ollama 默认端口示例。如果调用云端服务需要把http://127.0.0.1:11434替换成服务商地址并在请求头里加上鉴权信息headers { Authorization: Bearer YOUR_API_KEY, Content-Type: application/json }4.2 路线二本地部署开源模型本地部署最大的好处是数据不出内网适合处理未公开的题目和科研材料。以 Ollama 这种模型运行工具为例启动流程是标准三步。第一步安装并启动服务ollama serve第二步拉取目标模型。模型名需要根据实际可拉取列表确认这里只是占位示例ollama pull qwen2.5:7b第三步确认服务就绪curl http://127.0.0.1:11434/api/tags本地部署的硬件观察重点是显存。可以用nvidia-smi在推理前后分别记录显存占用对比空闲状态和推理状态的差值。模型规模越大、上下文越长显存占用越高。如果显存不够优先选择量化版本。4.3 硬件与资源占用观察部署完成后要在评测前先记录基线资源nvidia-smi更推荐用下面这种方式做定时采样把资源占用写成日志nvidia-smi --query-gpumemory.used,memory.total,utilization.gpu --formatcsv -l 5这里关注两个指标推理时显存峰值和 GPU 利用率。不同模型、不同上下文长度、不同并发数量显存占用差别很大不要轻信网上“7B 模型只占 6G”这种单一结论以本机采样为准。CPU 推理也能跑但速度慢很多适合只跑小批量验证。5. 批量评测脚本实战与结果分类环境通了之后就可以写批量评测脚本。脚本的核心任务是读取 JSON 题目集、循环调用模型接口、记录输出和耗时、把结果落盘。下面是通用的 Python 批量评测模板。请根据实际 API 地址、模型名和鉴权方式调整import json import time import requests API_URL http://127.0.0.1:11434/v1/chat/completions MODEL_NAME qwen2.5:7b HEADERS { Authorization: Bearer EMPTY, Content-Type: application/json } SYSTEM_PROMPT 你是一名数学老师。请逐步推理并用符号表达式明确写出最终答案。 def ask_math(question: str) - str: payload { model: MODEL_NAME, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: question} ], temperature: 0.2, max_tokens: 1024, stream: False } resp requests.post(API_URL, jsonpayload, headersHEADERS, timeout180) resp.raise_for_status() return resp.json()[choices][0][message][content] def run_batch(path: str): with open(path, r, encodingutf-8) as f: data json.load(f) results [] for item in data[tests]: start time.time() try: output ask_math(item[question]) except Exception as exc: output f[ERROR] {exc} cost round(time.time() - start, 1) record { id: item[id], category: item[category], level: item.get(level, unknown), question: item[question], reference_answer: item.get(answer, ), model_output: output, time_cost: cost } results.append(record) print(f {item[id]} | {item[category]} | {cost}s ) print(Q:, item[question]) print(A:, output) print() with open(math_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: run_batch(math_tests.json)运行方式python batch_eval.py一个值得注意的坑并发过高会把本地服务打满导致请求排队或超时。稳妥的做法是先单线程跑通再按需加并发。每条请求的timeout要设置合理数学推理链一旦变长耗时可能超过以往普通问答的预期。拿到结果后不要把“最终答案是否匹配”当成唯一指标。建议把输出归到下面五类正确答案正确推理过程完整。计算错误思路对但某一步算错。逻辑错误步骤之间有跳变或使用了不成立的变换。幻觉编造了不存在的定理、引理或出处。格式错误答案正确但表达式无法被工具解析。这种分类能帮你定位模型的短板。比如一个模型可能是“计算强但证明弱”另一个是“框架完整但细节不可信”。只有分类统计才能判断它适合放进哪条工作流。6. 用 sympy 交叉验证 AI 输出AI 输出天然是自然语言文本不能直接当验证依据。对计算题最可靠的验证方式是交给符号计算引擎重算一遍。sympy 是 Python 生态里很常用的符号计算库。先做一次标准计算import sympy as sp x sp.Symbol(x) expr sp.integrate(3*x**2 2*x 1, x) print(expr)再把 AI 输出的表达式提取出来和 sympy 结果做等价性判断。关键点是先把两边的表达式转成 sympy 对象再做差化简import sympy as sp import re def is_equivalent(expression_a: str, expression_b: str, symbol) - bool: try: a sp.sympify(expression_a) b sp.sympify(expression_b) return sp.simplify(a - b) 0 except Exception: return False def extract_last_expression(text: str) - str: # 简单提取最后一行作为候选答案 lines [line.strip() for line in text.strip().splitlines() if line.strip()] return lines[-1] if lines else text candidate x^3 x^2 x candidate candidate.replace(^, **) # 处理常见写法差异 reference x**3 x**2 x print(is_equivalent(candidate, reference, x))积分题还有一个特殊点原函数差一个常数 C 也是正确结果。直接对表达式做差不为 0 时不要立刻判错。可以先对两边求导再比较导数是否一致# 如果差值为常数也判定为等价 expr_a sp.sympify(x**3 x**2 x 10) expr_b sp.sympify(x**3 x**2 x) diff sp.simplify(expr_a - expr_b) print(diff) print(diff.free_symbols) # 如果diff是一个常数值free_symbols为空或只含无关符号可以判为等价这一步价值很大。它把“AI 说对了”变成“AI 输出被机器验证为对”这是工程上可靠的做法。证明题没有这种符号验证通道只能靠人审和后端检索工具。但至少计算类任务AI 的不可靠性可以被工具压住。7. AI 数学能力边界与教育科研影响把压测结果放在一起看AI 数学能力的边界其实很清晰。边界之一是验证成本。凡是被验证成本低的环节AI 可以大量参与凡是验证成本高的环节AI 只能给思路。计算题验证便宜所以放心让 AI 算证明题验证贵就只能当草稿参考。边界之二是创新属性。数学真正的难点不是按部就班推导而是知道“该证明什么”。这个能力来自大量阅读、对结构的直觉、对反例的敏感。当前 AI 模型是在已有文本上的概率建模它擅长组合已知模式并不擅长“提出值得证明的新命题”。所以更合适的定位是AI 做生成器人类做选择器和验证器。教育影响上AI 会改变数学作业的评价方式。“交答案”会被淘汰“交过程和反思”会被放大。作业里可以要求先写自己的思路用 AI 计算验证后再用自然语言解释为什么这一步成立。教师也可以把 AI 当成出题助手生成同类型变式题再人工筛选。这个过程需要明确边界AI 生成题目只能当素材最终题目要人工审定避免出现错题和歧义。科研场景里AI 更适合处理两类辅助工作一是大规模符号计算验证二是文献检索与草稿重构。涉及未公开研究内容时如果使用云端 API必须注意数据隐私和保密要求优先选择本地部署或经过合规审核的服务。8. 使用 AI 数学工具的常见问题与排查实际跑评测和日常使用中下面这些问题出现频率最高。问题现象可能原因排查方向连续返回错误答案温度过高 / 模型偏弱 / 提示词缺少限定降低温度到 0.2换更强模型增加“请逐步推理并写出过程”输出里有编造的引理模型幻觉要求给出可检索出处再用教科书或文献核对表达式无法被 sympy 解析格式不标准比如用了^而不是**先做文本归一化再提示模型输出 sympy 可解析格式API 请求超时服务排队或本地推理负载过高增大 timeout降低并发切单线程重试本地推理显存溢出模型规模超过显卡容量改用量化版本缩短上下文减小最大生成长度批量任务跑到一半卡住某条请求异常导致线程阻塞给请求加超时逐条写日志失败后跳过端口被占用服务起不来默认端口被其他进程占用检查端口占用切换端口并重启服务批量评测卡住是最常见的问题。脚本里一定要给请求加 timeout并把每道题的结果及时写入文件避免中间异常导致全部结果丢失。可以用下面这种写法try: output ask_math(item[question]) except requests.exceptions.Timeout: output [TIMEOUT] except requests.exceptions.ConnectionError: output [CONNECTION_ERROR] except Exception as exc: output f[ERROR] {exc}9. 最佳实践与结论总结一套可以长期复用的人机协作数学工作流。第一固定评测配置。同一组问题、同一个系统提示词、同一个温度参数才具备横向对比性。不要今天一个 prompt、明天一个参数。第二所有计算类结果走符号验证。让 AI 生成答案sympy 负责判定两者互为校验。做不到自动化的证明题必须留出人工复核环节。第三日志和结果分目录管理。题目集、模型输出、分类结果、验证脚本都单独存放避免后期追溯困难。第四关键任务不要只跑一个模型。如果条件允许用两个不同模型做交叉输出再比较差异点差异处重点核查。最后收敛到最初的问题AI 会杀死数学吗答案是不会。数学的核心是提出概念、构造证明、发现结构这个环节依赖人类对“什么值得被证明”的判断力。AI 改变的是数学的操作方式计算交给工具验证交给符号引擎生成交给模型而选择问题、判断方向、承担结论的责任仍然在人这边。真正该担心的是另一种情况如果所有人都不再亲手做推导、不再理解“为什么正确”只把 AI 输出当终稿那数学教育和数学研究才可能在被错误验证的闭环里慢慢失效。避免这个结果的唯一办法就是建立一套严格的验证和复核机制。这也是这篇文章想让你带走的东西。