如果你只把提示词工程当成“把问题描述得更清楚”那你大概率会在数学推理上碰一鼻子灰。我最近做了一组很简单的对比测试让同一个大模型计算一道包含加权平均和混合运算的数学题用普通的 Prompt 直接问它一本正经地给出了一个错误答案而且错得很有自信同一道题换成 CoTChain of Thought思维链提示词让模型先把解题步骤一步步写出来结果一次就对了。这个对比让我重新理解了 Prompt 和 CoT 之间的本质差距——它根本不是“描述清不清楚”的差距而是“有没有给模型搭好推理脚手架”的差距。这篇文章我不打算讲高深理论而是把我实际测试的完整过程、提示词模板、参数设置、踩坑点都摊开来说。内容包括普通 Prompt 在数学推理上为什么会失败、CoT 的底层机制、三个对照实验的完整记录、从零到一构造 CoT 提示词的实战套路以及几个非常容易被忽略的细节。如果你正在做数学题、逻辑题或任何需要多步推理的 AI 应用这篇内容可以直接拿来用。1. 数学推理场景下普通 Prompt 为什么经常“翻车”1.1 一次令人哭笑不得的失败案例先看一道非常典型的小学应用题某班有男生 20 人平均分 90 分女生 30 人平均分 80 分。问全班平均分是多少这道题的知识点只有一个加权平均数。正确算法是 (20×90 30×80) ÷ 50 84 分。但我在测试里发现用普通 Prompt 让模型直接回答时它给出的答案是 85 分也就是直接把 90 和 80 做了算术平均。更麻烦的是它的解答过程只有一行“全班平均分 (9080)÷2 85”没有任何对人数权重的分析。这个案例很经典因为它暴露了一个核心问题模型不是不会算除法也不是不理解“平均分”这个概念而是它在“一步到位”的回答模式下跳过了对题目条件的检查默认两个平均数拥有相同的权重。这种错误在人类身上也很常见——心算时忽略了题干里的“20 人和 30 人”只有动手列式时才会发现。1.2 直接作答时模型在做什么一场“一锤子买卖”普通 Prompt 下模型的工作方式本质上是“看到问题直接预测答案”。这个过程类似一个人做复杂计算时完全靠心算不借助任何草稿纸。问题在于大模型的每一步预测都基于前面已经生成的 token一旦中间结果没有被显式写出来它就只能在隐层状态里“硬扛”而隐层状态对多步中间变量的保持能力是非常有限的。我另一个测试更直观计算 3×(84×(12−7))÷6−5。正确结果是 9但普通 Prompt 下模型算出过 15、9、19 等好几个版本而且经常在展开括号之后丢掉前面已经计算出来的 28。这就像你心算一串长数字算到第三步时突然忘了第二步的结果只能重新乱猜。没有草稿纸人也会犯错模型也一样。所以普通 Prompt 在数学推理上的失败并不是“模型太笨”而是任务结构本身要求多步状态保持但回答模式却不允许中间状态落盘。两者不匹配翻车就是必然的。1.3 数学推理失效的常见错误类型我整理了多次测试中出现的错误发现其实可以归纳成几个稳定的类型错误类型典型表现示例加权平均错误直接对两个均值取算术平均忽略权重男生女生平均分算成 85中间状态丢失展开括号后遗忘前一步数值混合运算得到 15 或 19运算顺序错误不遵守括号优先级从左到右硬算先做 3×8 再做 4×(12−7)条件混淆把题干中不同数字张冠李戴把“12 元的笔”和“6 元的笔”搞混这四种错误里第一种和第二种出现频率最高原因是它们都需要模型“同时”记住多个信息片段而直接输出模式下模型几乎没有任何机制来显式管理这些片段。普通 Prompt 没有给模型提供任何记忆外挂所有信息都挤在一个隐层向量里自然容易出问题。2. CoT 的核心机制把思考过程“外置”之后发生了什么2.1 工作记忆与“草稿纸效应”CoT 的思路用一个生活化的类比就能说清楚让模型在草稿纸上把每一步都写下来而不是要求它心算。所谓“草稿纸效应”是指当模型把中间步骤生成出来之后这些步骤立刻变成了后续预测的可见上下文。模型不需要在隐层里苦苦维持“28 这个中间结果”因为它已经写在序列里了后续每一步都可以直接“看到”它。这个机制非常关键。大模型的预测本质上是给定前面所有 token 预测下一个 tokenCoT 正是利用了这个特性——把需要记忆的中间状态转化为 token从而把记忆负担从隐层转移到了上下文窗口。上下文窗口是显式的、可靠的而隐层记忆是隐式的、容易衰减的。这就是 CoT 在数学推理上能比普通 Prompt 稳定这么多的根本原因。我实际测试中的感受是CoT 并不是“教会”了模型数学而是给了它一个可以把脑子里的东西先写出来的机会。写出来之后模型自己都会发现前面算错了会主动修正。2.2 数学题的“隐性约束”为什么总被忽视数学应用题里有一类特别阴险的陷阱叫“隐性约束”。比如上面那道加权平均题题干没有明说“需要按人数加权”但这个约束就藏在整个问题的结构里。普通 Prompt 下模型很容易忽略这类约束因为它只在最后生成阶段做一次模式匹配匹配到的往往是“平均 总和 ÷ 数量”这个最粗糙的模板而不会去回溯人数的权重。CoT 破局的方式是强制模型先复述条件。我测试时发现只要提示词引导模型“先列出已知条件”模型就会自己写出“男生 20 人平均分 90女生 30 人平均分 80”然后它在下游步骤中看到“20”和“30”这两个数字就会自然地意识到权重不能忽略。一旦隐性约束被显式化到上下文里错误就消失了。这个过程的本质是把一个模型可能忽略的隐性条件变成它必须“经过”的一个显式文本节点。只要它在生成路径上经过这个节点后续推理就会受到它的约束。2.3 “先写思路”为什么等价于降低任务难度还有一个角度值得展开直接给出答案是一个从问题到答案的“大步跳跃”而 CoT 把一次跳跃拆成了很多小碎步每一步都极其简单。我把这个过程理解为“任务难度的线性化”。一道三位数乘法题直接出答案需要模型在一步之内完成所有进位计算这对神经网络来说太难了。但如果让它先算个位、再算十位、最后算百位每一步只需要处理一位数的乘法和一个进位预测难度显著下降。大模型不是不能做复杂推理而是每“一步”能承载的推理量有限CoT 恰好把每一步的复杂度压到了模型可以稳定处理的区间。这也可以解释为什么 CoT 对“简单但多步”的题目效果最好而对“单步但困难”的题目帮助有限——比如让它判断一个非常冷门的科学常识CoT 并不能凭空变出知识它只能让已知的推理路径走得更稳。3. 对比实验同一道题普通 Prompt vs CoT 的完整实测3.1 实验设计与题目选取为了把对比说得更清楚我设计了一个简单的实验同一个模型、同一组参数只改变提示词观察不同提示方式在同一批数学题上的表现。模型我选了当时可用的通用对话模型采样温度固定为 0.2所有题目各跑 5 次取多数结果。我选取了三类具有代表性的题目多步混合运算计算 3×(84×(12−7))÷6−5考察中间状态保持能力。加权平均数前文那道男生女生平均分题考察隐性条件提取。反向验证题一个数乘以 4 再加 6 等于 38求这个数考察逻辑回溯能力。这三类题分别对应三种不同的推理负担计算展开、条件提取、逻辑反向。单靠“描述清楚”的普通 Prompt 很难覆盖全部而 CoT 理论上可以对三类都有帮助只是帮助的方式不同。3.2 分组实录普通 Prompt、零样本 CoT、少样本 CoT先看普通 Prompt。三道题全部直接提问不加任何额外引导。结果非常稳定地翻车第一道题 5 次里错了 3 次错误集中在括号展开后遗忘 28 这个中间值第二道题 5 次全错全部输出 85第三道题 5 次里对了 3 次但另外 2 次把“这个数”直接算成了 38×46158完全做反了运算方向。再看零样本 CoT。我在问题后面加了一句“请一步一步地思考并把每一步都写出来”。第一道题 5 次全对第二道题 5 次全对第三道题 5 次里对了 4 次但仍有 1 次在设方程时把“乘以 4 再加 6”翻译成了“除以 4 减 6”。整体效果提升非常明显但反向验证题还是会出现翻译错误。最后是少样本 CoT。我在提示词里给出了一个完整的示范示范中包含已知条件提取、设未知数、列方程、求解、反向验证五个步骤。这次第三道题的 5 次结果全部正确而且模型在输出时会主动加一句“验证8×4638结果无误”。少样本示范把最后一块短板也补上了。3.3 结果统计与直观对比把上述结果整理成表格题目类型普通 Prompt零样本 CoT少样本 CoT多步混合运算2/5 正确5/5 正确5/5 正确加权平均数0/5 正确5/5 正确5/5 正确反向验证题3/5 正确4/5 正确5/5 正确这个表格非常清楚地展示了三档能力。普通 Prompt 整体在 33% 左右徘徊零样本 CoT 提升到 93%少样本 CoT 则是 100%。虽然样本量不大不能算是严谨的学术测评但这个趋势在多次重复测试中非常稳定——只要题目需要两步以上推理CoT 的增益就几乎是确定的。这里有个值得强调的结论零样本 CoT 和少样本 CoT 之间的差距主要不是“推理能力”的差距而是“推理习惯”的差距。模型在零样本时也有能力算对但缺少示范时它不知道你希望它做到多细、要不要做反向验证。示范的真正作用是把推理的“颗粒度”和“边界”固定下来。4. 构造高质量 CoT 提示词的实战套路4.1 零样本 CoT一句话触发的“魔法”零样本 CoT 是最轻量的 CoT 使用方式不提供任何示例只通过在问题后面追加一句话来引导模型逐步推理。英文环境中经典的魔法句是“Lets think step by step”我在中文环境里实测最稳定的版本是让我们一步步来分析这个问题请写出你的完整推理过程最后再给出最终答案。这句话之所以有效是因为它显式地改变了模型后续的生成策略。模型在训练中见过大量“先分析后解答”的文本这句话相当于一个模式开关把采样路径从“直接预测答案”切换到了“先预测分析步骤”。注意它不保证分析一定正确但至少让中间过程暴露出来给模型自我修正的机会。不过零样本 CoT 有一个明显短板它控制不了分析的结构。模型可能只写两三行就结束也可能跳步甚至可能用错误的逻辑写了一大段。对于那些需要特定推理格式的题目零样本 CoT 往往是“有过程但不够规范”。4.2 少样本 CoT示范的质量比数量更重要少样本 CoT 的核心是给模型一到三个完整的解题示范让它在模仿示范的结构时完成新题。很多人误以为示范越多越好但实际测试下来数学推理场景 2 到 4 个高质量示范就已经足够再多反而会引入干扰。示范的质量比数量重要得多。一个合格的 CoT 示范应该包含五个部分已知条件提取把题干里的数字和关系单独列出来。思路规划说明要用什么方法比如“用加权平均公式”。分步计算每一步写清计算式和中间结果。最终答案单独一行格式固定。反向验证可选把答案代回原题检查。下面是我在加权平均题上使用的示范模板示范 题目某班男生 20 人平均分 90女生 30 人平均分 80求全班平均分。 已知条件男生 20 人平均分 90女生 30 人平均分 80。 思路需要计算总分数再除以总人数。 步骤总分数 20×90 30×80 1800 2400 4200。 总人数 20 30 50。 平均分 4200 ÷ 50 84。 最终答案84 分。这个示范最关键的一点是把“思路”单独列了一步模型看到这种结构后会在新题里主动模仿。示范里的所有步骤都会成为模型输出的“格式锚点”你希望模型怎么输出就把示范写成什么样。4.3 CoT-SC自洽性多次采样投票提升稳定性如果你已经用了 CoT 但发现结果还是偶尔抖动可以试试 CoT-SCSelf-Consistency自洽性。思路非常简单同一个问题用 CoT 提示词配合稍高的温度运行多次让模型生成多条不同的推理路径然后对最终答案做投票取出现次数最多的答案。这个方法的基本逻辑是错误的推理路径往往各式各样而正确的路径通常只有一条所以正确的答案会在投票中自然胜出。我在反向验证题上做过测试单次 CoT 的正确率是 80%把温度调到 0.5 采样 5 次后投票正确率直接变成了 100%。提示CoT-SC 会消耗更多 token也会让响应时间变长适合对准确性要求高、对延迟不敏感的场景。如果只是日常提问单次 CoT 基本够用。4.4 一道题从普通 Prompt 到完整 CoT 的改造实例为了直观展示改造过程我以第三道题为例把从普通 Prompt 到完整 CoT 的逐级变化写出来。第一版普通 Prompt一个数乘以 4 再加 6 等于 38这个数是多少第二版加零样本 CoT一个数乘以 4 再加 6 等于 38这个数是多少 请一步一步思考写出完整推理过程再给我最终答案。第三版加结构约束一个数乘以 4 再加 6 等于 38这个数是多少 请你先列出已知条件再说明思路然后分步计算最后给出最终答案并对答案进行验证。第四版加少样本示范在第三版前面附一个同类示范。从第二版开始模型的正确率已经明显提升但从第三版开始输出格式会变得非常稳定从第四版开始模型会主动做反向验证。每一级改造加的都是“约束”和“锚点”并不是加知识但稳定性就是这么上来的。5. 真正的坑都在细节里参数、边界与反模式5.1 温度与采样参数对 CoT 的关键影响很多人在数学推理场景忽略了温度设置。温度直接控制生成概率的尖锐程度温度太高会让模型在推理步骤中“漂移”——中间步骤开始产出奇怪的数值温度太低又会让模型偷懒例如只写“然后计算得结果”却跳过了实际计算过程。我的实测建议分两种情况。追求单次稳定答案时温度设为 0 到 0.2 之间让采样尽量确定使用 CoT-SC 时温度可以调到 0.3 到 0.7 之间太低的话多次采样结果几乎相同投票失去了意义。你在同一个模型上只改温度不改提示词都能看到明显的差异。另外控制最大生成长度也很重要。CoT 需要额外的 token 来输出中间步骤如果最大 token 数设置太短模型会在推理到一半时被截断只能仓促给一个结论。我在早期测试中就因为 max_tokens 设了 100导致模型经常只写出两三步就强行结束效果还不如普通 Prompt。5.2 CoT 的边界哪些题目不适合硬套CoT 不是万能药。我梳理了几种不适合硬套 CoT 的情况纯事实记忆题比如“法国的首都是哪里”CoT 没有任何增益反而可能让模型开始“推理”出一个错误答案。超长逻辑链题目如果问题本身需要 20 步以上的推理CoT 可能会因为某一步走偏而全盘崩溃且错误会在后续步骤中被不断放大。依赖外部知识的题目模型不知道某个事实时CoT 无法通过推理凭空得出该事实相反它可能用流畅的假推理包装一个错误答案让问题更隐蔽。我见过的最常见的误用场景是在事实题上强行要求“逐步推理”结果模型一本正经编出了一个带推理过程的错误答案。结论很简单先判断题目的类型再决定要不要用 CoT。5.3 常见反模式伪装成 CoT 的“伪提示词”有些人以为只要在提示词里写了“推理”两个字就是 CoT 了其实不然。我见过几种典型的反模式只要求“给出过程”但没有要求“分步写出中间计算”模型最终只写了一句“根据公式可得”没有任何实际计算步骤。示范本身有错例如示范中的小学数学加法都算错了模型会把这个错误的结构和计算结果一起学走。把 CoT 和普通提示词混在一起写中间夹了大量无关描述模型被干扰后输出混乱。判断一个提示词是不是合格的 CoT最直接的方法就是看模型输出中是否产生了“中间状态”。如果模型输出的每一个中间步骤都能被后续步骤显式引用就是合格的 CoT如果只是一段修饰性文字就不是。5.4 输出格式控制的实操建议最后一个细节是输出格式。直接让模型“自由推理”你会得到一大段冗长的分析后续解析答案非常麻烦。我建议在提示词里段化输出结构请严格按以下格式输出 思路你的推理过程 最终答案单独一行这样做有两个好处一是模型在输出“思路”段落时被迫展开过程二是“最终答案”的单独成行使得程序解析变得非常容易。对于批量处理场景你甚至可以在提示词里要求“最终答案只输出数字不要包含其他文字”能极大减少后续清洗成本。我在实际项目里就是把这个格式要求写死在系统提示词里的配合闭源模型的接口做批量测评解析成功率从没低于 98%。相比普通 Prompt 的输出这种结构化的 CoT 输出在工程上友好太多。6. 我的实测体会与后续扩展方向把这一整套方法跑完之后我心里最深的感受是CoT 的本质是把模型的“隐性计算负担”转换为“显性序列生成”它没有改变模型的智力上限却把模型已有的能力更充分地释放了出来。在我自己的项目里我现在遇到数学推理类问题会默认走一套固定流程先判断题目类型然后选择零样本 CoT 直接生成如果效果不稳定就加少样本示范再不稳定就开 CoT-SC 做投票。这套流程帮我处理过不少原本需要人工复核的计算题尤其在批量数据处理和评测集验证时省下来的时间相当可观。后续我打算在三个方向上继续深入一是把 CoT 与外部的计算工具结合让模型只负责拆题和组装步骤把真正的大数计算交给代码执行避免 token 级别的算力浪费二是尝试在代码生成的 bug 定位场景里用类似思路让模型先描述代码的执行轨迹再定位问题目前初步实验效果不错三是探索不同语言环境下 CoT 措辞的敏感度中文和英文的“逐步思考”触发效果其实存在差异这块还没有特别系统的结论。如果你也在做与大模型推理相关的应用建议先从今天这篇文章里的零样本 CoT 开始花半小时跑一遍对比实验大概率会重新认识自己手头这个模型的真实推理水平。等到踩过几次输出的坑之后再回头来看少样本示范和参数调节会有完全不同的体会。