如果你让一个大语言模型算“367 × 824 等于多少”它可能犹豫几秒后给你一个接近但不对的答案。如果你让它解一个偏微分方程的数值格式、总结一篇论文里的证明思路或者解释傅里叶变换为什么在信号处理里无处不在它反而能讲得头头是道。这个反差非常有意思LLM 到底擅长什么数学不擅长什么数学这个问题不是学术消遣——它直接决定了你在做 LLM Agent、RAG 知识库、数学辅助工具、数据分析应用时应该让模型自己算还是让它调用工具还是干脆换一条技术路线。这篇文章想给出一个清晰判断LLM 擅长的是“数学的模式、语言和相似性”不擅长的是“数学的形式化推理、精确计算和符号操作”。它的数学能力本质上来自海量语料里的记忆和概率预测而不是一套可靠的计算引擎。理解了这一点你才能在设计 RAG 流程、编排 Agent 工具、选择推理精度fp16/fp32/bf16时做出正确决策。读完这篇文章你会得到三样东西第一一套用来区分“LLM 能做什么数学任务、不能做什么数学任务”的判断框架第二几个可以直接跑起来的最小实验脚本用来评估你手里的模型第三一套工程上扬长避短的实践方法包括如何用工具调用、符号计算和检索增强来补齐数学短板。1. 这篇文章真正要解决的问题过去两年大语言模型在数学基准测试上的分数一直在涨从 GSM8K 到 MATH 再到各种竞赛级数据集榜单上的数字很漂亮。但很多开发者在实际项目里发现模型在榜单上能解竞赛题在真实业务里却可能把一份采购订单的总价算错它能写出正确的微积分公式却无法稳定地完成一次多步骤的代数展开。这种“看榜单一套用起来另一套”的落差才是工程上真正要面对的问题。数学能力对 LLM 应用开发的影响面比想象中大。你在做 LLM Agent 时模型需要把用户的问题拆成步骤、决定先调用哪个工具、判断结果对不对这个过程本身就包含数学逻辑你在做数据分析应用时模型要写 SQL、写 Python 代码、解释统计结果每一步都涉及数学语义你在做 RAG 数学知识库时模型要判断检索到的公式和定理是否真的适用于当前问题。如果对 LLM 的数学边界没有清晰认知这些问题都会变成上线后的雷。所以这篇文章不是来论证“LLM 是不是会做数学”这种哲学问题的而是解决一个非常具体的工程问题在你自己的项目里如何判断一个数学任务该不该交给 LLM以及如果不该应该用什么方案替代。最适合读这篇文章的读者是正在做 LLM 应用开发、Agent 编排、知识库问答、数据分析产品的工程师以及在本地部署推理引擎并纠结精度选型的技术爱好者。2. 基础概念为什么 LLM 看起来会数学但并不是真的在“算”要理解 LLM 的数学能力边界先要理解它的工作原理。LLM 本质上是一个“下一个 token 预测器”给定一段文本它根据训练时学到的统计规律预测最可能接在后面的 token。它没有内存中的数字寄存器没有符号计算引擎也没有一套能保证每一步都正确的推理演算规则。它有的只是参数里压缩的、海量文本中的模式。这就带来了一个关键结论数学是人类发明的形式系统而 LLM 是一个统计语言模型。形式系统要求精确统计模型天然带概率。当一个数学问题恰好对应训练语料中大量出现过的模式时模型能够“回忆”出正确答案当问题需要多步组合、精确进位、严格推导时模型的每一步都带着概率误差误差累积起来答案就不可靠了。很多初学者会误解以为 LLM 的数学能力差是因为“训练数据不够多”。实际上数据量只是其中一个因素更根本的问题是架构层面的它根本没有一套可靠的符号操作机制。你给它看再多的乘法题它也学不会“进位”这个操作本身的确定性——它只能学习“进位之后大概会长什么样”。这也是为什么你让 LLM 做三位数乘法它偶尔会对偶尔会错而且错了之后如果你追问它还可能一本正经地道歉然后继续错。另一个容易混淆的概念是推理能力。人们常说的“LLM 有推理能力”在数学场景里表现为 chain-of-thought思维链。但也有研究者认为思维链更多是让模型更接近训练语料中“解题过程”的分布而不是让模型真正学会了逻辑推导。对工程人员来说这个争议可以先放一边更重要的判断是思维链能提升 LLM 在常见数学题上的表现但不能把它当作可靠的计算依据。涉及金额、数量、身份认证、安全阈值等场景必须让计算发生在模型之外。3. LLM 擅长什么数学不擅长什么数学把数学任务细分成若干类型会有更清楚的认识。下面这张表是一个粗略分类数学任务类型LLM 的表现原因工程场景概念解释、公式语义、数学史很好语料丰富本质是语言生成数学知识问答、教学助手算法步骤描述、伪代码较好语料中大量代码和算法讲解辅助编程、方案设计应用题理解与列式中等到较好能提取关键信息但计算环节可能出错题目解析、教育产品多位数算术、精确浮点运算差无确定计算机制概率输出叠加误差财务计算、订单金额符号展开、化简、方程求解差到中等规则繁琐偶尔能“背”出来但不可靠数学辅助工具严格证明、复杂逻辑推理不稳定需要长程一致性模型容易自相矛盾论文辅助、科研工具统计结果解读、图表语义较好输出的是语言解释不需要精确计算数据分析报告这张表的核心结论有两层。第一层LLM 擅长的是“关于数学的语言”而不是“数学计算本身”。你可以让它解释回归系数的含义也可以让它描述贝叶斯定理在医学检验中的应用场景这些它都能做得不错。但如果你让它精确算出某个回归系数的标准误或者对一组数做累计求和它就不一定靠得住了。第二层LLM 在数学任务上的上限往往由它是否能调用工具来决定。如果应用架构是“LLM 负责理解问题 工具负责精确计算”那么用户体验会好很多如果架构是“LLM 直接输出答案”那么数学类需求就是高风险区域。从行业趋势看这也解释了为什么现在 LLM Agent 和函数调用会成为热点LLM 本身不是可靠的计算器但它很擅长“决定应该用哪个工具、如何把用户问题翻译成工具参数”。这套分工正好避开了它的短板放大了它的优势。所以你在设计系统时与其反复调 prompt 逼模型把数学算对不如在架构上承认它的边界把精确计算交给确定性的工具。4. 精度问题fp16、fp32、bf16 与 LLM 数学能力的关联在中文技术社区里LLM 精度问题是一个高频搜索词尤其涉及 fp16、fp32、bf16 的换算和选择。很多人以为这只是“训练时用什么精度”的细节但在数学任务场景里精度选择会影响模型最终输出的可靠性而且推理时的量化精度也可能改变同一个数学问题的正确率。先快速解释这三个概念精度格式位数特点常见使用场景fp3232 位单精度浮点动态范围大精度较高但内存和算力开销大传统深度学习训练基线fp1616 位半精度浮点内存减半训练提速但尾数少、范围小容易溢出混合精度训练部分推理bf1616 位 bfloat16动态范围与 fp32 接近精度牺牲主要在尾数训练稳定性好大模型预训练、多精度推理要注意bf16 虽然也是 16 位但它保留了更多指数位所以数值范围比 fp16 大很多不容易溢出。这让它在大模型训练中很受欢迎。但从数学任务的角度看尾数精度的损失意味着它在处理某些需要高精度小数的运算时结果可能与 fp32 有差异。如果你在跑一个需要反复累加的数值算法这种差异会被放大。对普通开发者来说这一节不需要背公式只需要记住两个工程建议。第一用 bf16 或 fp16 做训练和推理时不要默认最终数学输出和 fp32 完全一致。如果业务对数值精度敏感最好做一轮对照测试同一道数学题分别用不同精度跑一遍看结果差异有多大。第二本地推理引擎的精度格式与模型量化策略相关不同引擎比如 llama.cpp 系列、MLX 等支持的精度转换方式不同。选型时除了看推理速度还要看你关心什么任务类型如果以数学问答为主尽量保留更高精度的加载方式或者用外部工具补齐计算。这部分的结论可以提炼成一句话精度问题不是纯粹的训练技巧它和 LLM 的数学表现直接相关但也不应该指望通过调精度来让模型变成可靠计算器。精度调整是“止损”不是“补能”。真正可靠的做法是把精确计算交给确定性的外部工具。5. 环境准备与前置条件如果想亲自动手验证 LLM 的数学能力不需要很复杂的实验环境。本文的示例基于一个通用前提你有一个可以通过 OpenAI 兼容接口访问的 LLM 服务它可以是你本地推理引擎暴露的服务也可以是一个远端的模型 API。使用这种兼容接口的好处是你不需要绑定某个具体厂商也很容易换成本地环境。建议环境如下项目建议说明操作系统Linux / macOS / Windows 均可只要 Python 能运行即可Python3.9 及以上因为用到类型标注和标准库LLM 接口OpenAI 兼容接口形如http://localhost:8000/v1或云厂商提供的 endpoint访问方式Pythonopenai客户端库社区标准适配大多数兼容服务辅助库sympy用于符号计算示例便于对照配置文件环境变量或.env文件用于保存 API Key 和 base_url版本说明具体库版本请以你实际安装为准本文不绑定某个训练好的模型版本也不假设你使用哪个推理引擎。重点演示的是“如何验证一个模型的能力边界”而不是“某个模型一定能跑出某个分数”。如果你还没有本地环境一个常见路径是安装 llama.cpp 或 MLX 系工具在本地加载一个开源模型然后把服务暴露为 OpenAI 兼容接口。这样你既能控制推理精度又能用同一套 Python 代码做实验。不同推理引擎在工具调用支持上差别较大如果后续要做 Agent 实验选型时优先确认它是否支持 function calling 接口。6. 核心流程拆解如何评测一个 LLM 的数学能力评测 LLM 数学能力看起来简单实际容易踩坑。如果只是问模型几个题然后看它答对没有结果会非常不稳定。更稳妥的方法是把评测拆成四个步骤设计任务集、构造调用逻辑、判定结果、记录并分析。第一步设计任务集。不要只用一个类型的数学题应该覆盖“口算能力、符号代数、应用题、概念解释”四类。比如口算题可以是一道两位数乘法符号代数可以是一个多项式化简应用题可以是一道涉及单价和数量的采购问题概念解释可以问“最大似然估计的直觉是什么”。每类任务各准备 5 到 10 道数量不用多但要能暴露差距。第二步构造调用逻辑。注意给模型统一的系统提示词并设置一个合理温度比如 0 或接近 0。数值和数学任务应该用低温度避免随机性干扰判断。如果模型本身支持思维链可以保留但不建议把思维链和最终答案混在一起解析最好让模型输出 JSON 结构便于程序处理。第三步判定结果。这是最容易出问题的地方。对于有确定答案的题不要只判断“最终数字对不对”还要判断“推导过程是否合理”。但程序自动判定过程比较难更实用的做法是先让模型输出结果再用一个确定性程序去校验答案。比如乘法题用 Python 的整数乘法算一个标准答案再比较模型输出和标准答案。这一步的核心是判定标准必须可复现不能靠肉眼打分。第四步记录并分析。把所有输入、输出、是否正确、耗时、token 消耗都记录到表格或 JSON 文件里。很多人在这一步直接看“正确率”但更有价值的观察是错误集中在哪一类任务模型是“差一点”还是“完全不对”比如两位数乘法经常错在末尾数字说明它根本没有可靠执行进位应用题经常列式正确但计算出错说明问题出在计算而不是理解。这些观察能直接指导你的架构决策。7. 完整示例与代码实现下面给三个可以直接运行的 Python 示例。第一个示例是数学能力评测脚本第二个示例演示如何用符号计算工具补足 LLM 的数学短板第三个示例演示如何用 RAG 思路构建一个数学知识问答的最小闭环。三个示例都允许你通过环境变量切换远端或本地 LLM 服务。7.1 示例一LLM 数学能力最小评测脚本这个脚本负责给定一组数学问题调用 LLM 获取答案再用确定性方法判定正误。文件路径llm_math_eval.py。# 文件路径llm_math_eval.py import os import re import json from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY, your-key), base_urlos.getenv(LLM_BASE_URL, http://localhost:8000/v1), ) model os.getenv(LLM_MODEL, your-model) # 任务集每一项包含问题、答案类型、预期答案校验函数 def check_mul_2digit(answer_text: str) - bool: m re.search(r\*\*结果\*\*[:]\s*(\d), answer_text) if not m: return False return int(m.group(1)) 47 * 83 def check_poly_expand(answer_text: str) - bool: # 简化判断只判断关键项是否存在 # (x2)^2 x^2 4x 4 return x^2 in answer_text and 4x in answer_text def check_word_problem(answer_text: str) - bool: # 3 支笔每支 2.5 元加上 1 个 1.5 元的橡皮共 9.0 元 m re.search(r\*\*结果\*\*[:]\s*([\d.]), answer_text) if not m: return False return abs(float(m.group(1)) - 9.0) 1e-6 def check_concept(answer_text: str) - bool: # 概念解释题不判断数值只判断是否提到关键概念 return 最大似然 in answer_text or likelihood in answer_text.lower() tasks [ { name: 两位数乘法, question: 请计算 47 * 83并严格按照下面的格式输出\n**结果**数字, check: check_mul_2digit, }, { name: 多项式展开, question: 请展开 (x2)^2并说明展开步骤。, check: check_poly_expand, }, { name: 应用题, question: 小明买了 3 支笔每支 2.5 元又买了 1 个 1.5 元的橡皮一共多少钱请严格按照格式输出\n**结果**数字, check: check_word_problem, }, { name: 概念解释, question: 请用两句话解释什么是最大似然估计。, check: check_concept, }, ] def ask(question: str) - str: resp client.chat.completions.create( modelmodel, temperature0, messages[ {role: system, content: 你是一个数学助手回答要简洁、准确。}, {role: user, content: question}, ], ) return resp.choices[0].message.content or if __name__ __main__: results [] for task in tasks: answer ask(task[question]) ok task[check](answer) results.append({task: task[name], ok: ok, answer: answer}) print(f[{PASS if ok else FAIL}] {task[name]}) print(answer) print(- * 40) with open(math_eval_result.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)这段脚本的核心价值不是告诉你某个模型分数如何而是给你一套可以重复使用的评估框架。你很容易把tasks换成你自己关心的数学任务也可以替换check函数来适配不同的输出格式。这里用正则解析模型输出所以要求模型的输出格式尽量规范。如果模型经常不按格式输出可以在 system prompt 里补充“只输出 JSON”或“只输出答案”这会显著提高自动评测的稳定性。7.2 示例二用 sympy 补足 LLM 的符号计算能力真实产品中更常用的做法是把“理解问题”和“执行计算”分开。下面这段代码演示一个混合流程LLM 判断用户是否需要一个可靠计算如果需要就从文本中提取数学表达式交给 sympy 精确计算然后把计算结果和解释拼接起来。文件路径math_assist_with_sympy.py。# 文件路径math_assist_with_sympy.py import os import sympy as sp from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY, your-key), base_urlos.getenv(LLM_BASE_URL, http://localhost:8000/v1), ) model os.getenv(LLM_MODEL, your-model) def extract_expression(user_input: str) - str: # 实际项目中可以结合 LLM 抽取这里用一个极简规则作为演示 # 假设用户输入形如请计算 (x1)**2 的展开式 if ( in user_input and ) in user_input: start user_input.find(() end user_input.rfind()) return user_input[start:end 1] return def llm_explain(question: str, calc_result: str) - str: resp client.chat.completions.create( modelmodel, temperature0, messages[ {role: system, content: 你是一个数学助手根据计算结果向用户解释计算过程。}, {role: user, content: f用户问题{question}\n精确计算结果{calc_result}\n请给出简洁解释。}, ], ) return resp.choices[0].message.content or if __name__ __main__: q 请计算 (x1)**2 的展开式 expr_text extract_expression(q) if expr_text: try: expr sp.sympify(expr_text) expanded sp.expand(expr) calc_result str(expanded) except Exception as e: calc_result f符号计算失败{e} else: calc_result 未能从输入中识别出表达式 print(符号计算结果, calc_result) print(LLM 解释) print(llm_explain(q, calc_result))这段代码演示了一个关键模式LLM 不对最终数值负责它只负责解释和对话。符号操作由 sympy 完成结果可信、可复现。实际系统中你可以让 LLM 先对用户输入做信息抽取再通过代码解释器或函数调用触发 sympy最后把结果交回给 LLM 生成自然语言回答。这种做法比让 LLM 直接写 sympy 代码更稳因为它保证了“计算发生前表达式来源是明确的”。7.3 示例三用 RAG 查询数学公式和知识RAG检索增强生成在数学知识问答里同样是重要技术路径。它解决的问题是当用户问到一个训练数据里没有、或模型记忆不确定的数学知识时先从一个受控的知识库中检索相关资料再让模型基于资料回答减少幻觉。下面代码演示一个最小闭环把几个公式文档存入内存索引用关键词检索相关内容然后把检索结果和用户问题一起交给 LLM。文件路径math_rag_demo.py。# 文件路径math_rag_demo.py import os from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY, your-key), base_urlos.getenv(LLM_BASE_URL, http://localhost:8000/v1), ) model os.getenv(LLM_MODEL, your-model) # 一个极简的数学知识库实际项目可替换为向量数据库 KNOWLEDGE_BASE [ 泰勒公式若函数 f(x) 在 xa 处有 n 阶导数则 f(x) 可展开为 f(a) f(a)(x-a) f(a)(x-a)^2/2! ..., 勾股定理直角三角形两直角边的平方和等于斜边的平方即 a^2 b^2 c^2。, 贝叶斯定理P(A|B) P(B|A) * P(A) / P(B)用于描述两个条件概率之间的关系。, 欧拉公式e^(i*pi) 1 0是复分析中的著名等式。, ] def retrieve(query: str, top_k: int 2) - str: # 极简检索按关键词匹配得分实际项目中请使用向量检索或全文检索 scores [] for doc in KNOWLEDGE_BASE: score sum(1 for kw in query if kw in doc) scores.append(score) top_indices sorted(range(len(scores)), keylambda i: scores[i], reverseTrue)[:top_k] return \n---\n.join(KNOWLEDGE_BASE[i] for i in top_indices if scores[i] 0) def ask_with_rag(question: str) - str: context retrieve(question) messages [ {role: system, content: 你是数学知识助手。回答时优先使用提供的上下文不要编造没有依据的公式。}, {role: user, content: f上下文\n{context}\n\n问题{question}}, ] if not context: messages.append({role: user, content: 提示没有检索到相关上下文请直接说明无法确认。}) resp client.chat.completions.create( modelmodel, temperature0, messagesmessages, ) return resp.choices[0].message.content or if __name__ __main__: while True: q input(请输入数学知识问题输入 exit 退出).strip() if q exit: break print(回答, ask_with_rag(q)) print(- * 40)这个示例在工程上有两点提示。第一检索质量决定了回答质量。如果你的知识库是大量 PDF、博客、笔记建议用向量库 embedding 模型做语义检索而不是简单关键词匹配。第二embedding 服务经常需要单独配置很多项目会遇到“LLM 文本向量 API 未配置”的报错解决方式通常是检查环境变量里的embedding相关配置确认 base_url 和模型名是否匹配。另外不要忘了 RAG 是限制来源不是保证正确如果知识库本身有误模型也会照着错。8. 运行结果与效果验证运行第一个评测脚本的命令很简单export LLM_API_KEYyour-key export LLM_BASE_URLhttp://localhost:8000/v1 export LLM_MODELyour-model python llm_math_eval.py预期输出会按任务名打印[PASS]或[FAIL]并在最后生成一个math_eval_result.json文件。判断成功的标准不是“全部 PASS”而是你能从输出里看出模型的能力模式。比如概念解释题通过两位数乘法失败应用题列式正确但结果错误。这种分化本身就说明问题也验证了本文开头那个判断LLM 擅长数学语言不擅长精确计算。第二个脚本运行方式python math_assist_with_sympy.py如果能打印出符号计算结果x**2 2*x 1和一段自然的 LLM 解释说明混合计算流程跑通。这一段的验证重点是LLM 是否只负责解释而把精确计算留给了 sympy。第三个脚本运行后输入“什么是贝叶斯定理”如果回答中引用了知识库里给出的贝叶斯公式说明 RAG 链路生效。如果回答“无法确认”大概率是检索阶段没有命中。可以先打印context变量看看检索结果是否为空。如果第一个脚本报错第一步不是查模型能力而是检查接口连通性直接 curl 一下 base_url 的/models端点确认服务可用、key 正确。其次是看模型输出格式——很多评测脚本的失败其实是解析失败而不是模型不会做数学题。9. 常见问题与排查思路问题现象可能原因排查方式解决方案LLM 数学答案不稳定同一道题两次结果不同温度设置过高采样随机性检查请求参数 temperature数学任务统一设为 0 或接近 0评测脚本大量 FAIL但人工看模型“好像会”输出格式不规范正则解析失败打印原始 output 内容人工查看格式在 prompt 中强制 JSON 输出或改用更宽松的判定规则LLM 应用题列式正确但最终数字错模型在计算阶段发生概率误差分离“理解”和“计算”环节用工具、代码解释器或 sympy 完成实际计算本地推理引擎加载 bf16 模型后数学表现下降精度格式对数值细节有影响对照 fp32 与 bf16 同一道题的输出数学敏感场景降低量化程度或让计算走外部工具RAG 回答“无法确认”或答非所问检索未命中知识库质量和覆盖不足打印检索到的 context 内容切换向量检索补充分块和 embedding 配置调用 embedding API 报“文本向量 API 未配置”环境变量或服务配置缺失查看配置文件中的 base_url 和模型名单独配置 embedding 服务确认 key、模型名、维度和索引一致模型工具调用跟不上Agent 流程经常中断推理引擎不支持 function calling或模型能力不足查阅推理引擎文档确认接口是否支持 tools 参数更换推理引擎或在 Agent 框架中加入重试与回退逻辑10. 最佳实践与工程建议如果你要把 LLM 用在与数学相关的业务里下面这些建议来自工程实践而不是理论推演。第一区分“解释数学”和“计算数学”。让 LLM 解释回归系数的经济含义是安全的让它计算回归系数的具体数值是有风险的。业务上所有金额、数量、校验码、统计口径相关的输出都应该经过确定性代码复核。一个简单规则是如果这个数字错了会引发投诉或损失就不要让模型直接输出它。第二在 Agent 设计中把工具调用作为默认路径。当下 LLM Agent 的主流实践是函数调用模型负责判断“用户想做什么”然后调用一个确定性的函数执行计算。这个函数可以是 Python 代码解释器、sympy、SQL 查询甚至是一个外部数值库。编排框架的流行正是因为它把这种“模型 工具”的分工变成了可配置的流程。第三精度和量化选择要服务于任务类型。如果你主要做数学问答、代码生成、数据分析加载模型时尽量选择精度损失较小的格式或者在关键路径上调用高精度工具如果你的场景是聊天、摘要等对精确数字不敏感的任务fp16 或量化模型可以明显降低部署成本。关键是要有意识地区分而不是盲目追新。第四RAG 是知识补充方案不是计算替代方案。用 RAG 检索公式和定理可以降低幻觉但公式检索到了代入公式求解的过程还是要交给确定性程序。更好的做法是RAG 负责召回“该用什么公式”代码负责“把公式算出来”LLM 负责“把过程和结论讲清楚”。三个环节各干各最擅长的事。第五对模型数学能力做回归测试。建议把一组固定的数学任务纳入 CI每次换模型、换推理引擎、换精度配置时都跑一遍。这能帮你快速发现“这次升级到底有没有让数学能力变好”。数学能力评测不一定要追求完整覆盖固定一二十道覆盖面广的题就足够发现趋势。11. 总结与后续学习方向这篇文章想讲清楚的不是“LLM 能不能做数学”这种空泛判断而是一条可以落地的工作准则LLM 擅长数学的模式、语言和解释不擅长精确计算和形式化推导。在工程上这意味着我们不应该试图把模型变成计算器而应该让它成为一个会调用计算器、会组织知识、会解释结果的“数学助手”。如果你想继续深入有四个方向值得关注。第一个是 LLM Agent 与工具编排重点学习函数调用、带状态的多步任务和错误恢复第二个是 RAG 与个人知识库把公式、定理、题目解析整理成可检索的结构化资料典型的思路是把笔记库和 LLM 结合成知识库工作流第三个是推理精度与本地部署理解 bf16、fp16、量化对输出质量的影响以及不同推理引擎对工具调用的支持差异第四个是评测方法论学会设计自己的评测集而不是只看公开榜单。最后提醒一句无论模型在各种基准上分数多高真实业务里一定要给数学输出加一层确定性校验。能用工具算的就用工具算能查知识库的就查知识库让模型做它真正擅长的事——理解用户、组织信息、生成解释。这条原则比任何 prompt 技巧都更可靠。