在使用大语言模型解决数学题、逻辑推理或代码生成任务时，输出结果与预期不符的情况并不少见。更让人困扰的是，模型给出的错误答案往往看起来头头是道，很难一眼发现错在哪一步。错误分析提示词就是针对这一痛点的解决方案：通过精心设计的提示词，引导模型拆解自己的推理链条，暴露出错的具体环节，并进行有针对性的修正。本文将系统介绍这套方法的原理、模板和实践技巧。
一、大模型推理错误的常见类型与成因
要设计有效的错误分析提示词，第一步是弄清楚模型到底会在哪些环节出错。总体来看，推理错误可以分为四类：事实性错误、逻辑跳步、计算失误和前提误解。事实性错误指模型引用了不正确的知识，例如把某个历史年份记错；逻辑跳步指推理过程中遗漏了必要的中间步骤，直接从条件跳到结论，导致结论不成立；计算失误在数学题中最常见，模型列出正确的算式却算错了结果；前提误解则是模型对题目条件的理解出现偏差，比如忽略了“不包含重复元素”这样的限制条件。
这些错误的成因与大模型的生成机制有关。模型是逐个token生成文本的，一旦前面的步骤出错，后面的内容会基于错误前提继续生成，形成所谓的“错误累积”效应。也就是说，一个早期的小错误会被后续推理不断放大，最终答案看起来荒谬却难以定位源头。理解这一点非常重要，因为错误分析提示词的核心思路就是打断这种累积过程，强制模型在关键节点停下来自查。
另外还要区分两种情况：一种是模型“知道自己可能错”的不确定性场景，另一种是模型“坚信自己正确”的幻觉场景。前者通过自我检查类提示词就能显著改善，后者往往需要引入外部验证信息，例如让模型重算一遍、列出已知条件逐条核对，或者提供参考答案让它做对比分析。
二、错误分析提示词的核心结构设计
一个完整的错误分析提示词通常包含四个部分：任务回顾、步骤分解、逐步检验和错误定位。任务回顾要求模型先复述原始题目和已知条件，这一步看似多余，实际上能有效减少前提误解类错误，因为复述过程会强制模型重新读题。步骤分解要求模型把推理过程写成编号步骤，每步只做一件事，这样后续检查才有明确的检查单元。逐步检验是让模型对每个步骤问自己三个问题：这一步的依据是什么、依据是否成立、结论是否真的由依据推出。错误定位则要求模型明确指出哪一步出了问题，并说明出错原因。
下面是一个可直接套用的通用模板：
请分析以下推理过程是否正确，按以下步骤操作： 1. 复述题目：用自己的话完整复述题目条件和目标， 检查是否有遗漏或误解的条件。 2. 分解步骤：把原始推理过程拆分为编号步骤， 每个步骤只包含一个推理动作。 3. 逐步检验：对每个步骤回答三个问题： - 这一步的依据是什么？ - 该依据是否成立？ - 结论是否严格由依据推出？ 4. 定位错误：如果发现错误，指出具体是第几步、 错误类型是什么（事实错误/逻辑跳步/计算失误/前提误解）。 5. 修正重做：从出错步骤开始重新推理， 保持后续步骤与修正后的前提一致。
使用这个模板时有一个关键技巧：不要只让模型回答“对还是错”，而要它输出完整的检验过程。实践经验表明，让模型先写出检验分析再下结论，准确率明显高于直接要结论。这是因为生成检验文本本身会迫使模型重新审视每个推理环节，相当于给思考过程增加了额外的计算量。
三、追问式定位：让模型暴露出错的具体环节
当模型第一次自查没有发现问题，但答案仍然可疑时，需要使用追问技巧。追问的本质是缩小检查范围，把笼统的“检查一下”变成针对特定环节的质询。常用的追问角度包括：反例检验（“能否构造一个满足所有前提但违反该结论的反例”）、量级估算（“用粗略估算验证这个结果的量级是否合理”）和条件核查（“列出题目所有约束条件，逐一确认答案是否满足”）。
以一道数学题为例，假设模型算出某个商品打折后的价格是负数，明显不合理，但模型自查时没发现问题。这时可以用这样的追问提示词：
你给出的答案是 -35 元。请先不要重新计算， 回答以下问题： 1. 价格这个量的合理取值范围是什么？ 2. 你的答案在这个范围内吗？ 3. 如果不在，说明推理链中哪一步引入了 不合理的运算？请指明具体步骤编号。 4. 只在完成以上分析后，才重新计算并给出新答案。
这个提示词的关键在于“先不要重新计算”。如果直接让模型重算，它很可能重复同样的错误路径，因为它倾向于保持前后一致。强制它先做合理性检查，相当于在旧路径上插入了一个断点，再重新计算时模型往往会选择不同的推理路线，从而规避之前的错误。这种方法在数学和代码场景中效果尤其明显，因为在这些场景中错误通常集中在一两个具体步骤，而不是整体思路问题。
四、自我验证与角色对抗：两种修正策略的对比
在修正阶段，有两种主流策略可以选择。第一种是自我验证，让同一个模型扮演检验者的角色，对前面的推理进行审核；第二种是角色对抗，在同一个会话中设定两个立场对立的角色，一个负责推理，一个负责找茬，通过多轮交锋逼近正确答案。
自我验证的提示词写法比较直接：
以下是你之前的推理过程和最终答案。 现在请你切换为严格的审稿人角色， 你的唯一任务是找出推理中的漏洞。 审稿时不考虑答案是否“看起来合理”， 只关注每一步逻辑是否严密。 找出漏洞后，以审稿人身份给出修改意见， 再切换回解题者身份，根据意见修改推理。
角色对抗的写法则更复杂一些：
在接下来的对话中，你将同时扮演两个角色： 【解题者】：负责给出推理过程。 【质疑者】：负责对解题者的每一个关键 步骤提出质疑，包括依据是否可靠、 计算是否正确、是否存在遗漏情况。 流程：解题者先完成推理，质疑者逐条 质疑，解题者回应质疑，质疑者确认 是否满意。只有当质疑者无法再提出 新的有效质疑时，才输出最终答案。
两者的适用场景不同。自我验证成本较低，适合错误率不高、错误类型单一的任务；角色对抗消耗的token更多，但在逻辑关系复杂、容易存在隐藏漏洞的题目上效果更好，因为质疑者的职责就是主动搜索边界条件和反例。需要注意的是，角色对抗不宜设置过多轮数，一般两到三轮即可，轮数过多时模型可能陷入“为质疑而质疑”的循环，反而降低效率。
五、实践建议与常见误区
最后总结几条实践中容易踩的坑。第一，不要在一条提示词里同时塞入太多检验要求，检验点过多会让模型的注意力被稀释，每个检验都做得浅尝辄止。更好的做法是分多轮进行，每轮聚焦一类错误。第二，给模型提供输出格式约束，例如要求它以“错误步骤：第X步；错误类型：XXX；修正方式：XXX”的固定格式输出，格式约束不仅能方便阅读，也能提升定位准确率。第三，对于数学计算类错误，单纯的语言提示有时不够，可以要求模型把关键计算写成竖式或分步算式的形式，显式的计算过程能显著降低运算失误率。
还有一个容易被忽视的点是温度参数的配合。错误分析本身需要模型保持严谨，此时应使用较低的温度（如0到0.3），避免模型在自查阶段引入随机性。而如果采用角色对抗策略，质疑者角色的发挥可以适当容忍稍高的温度，以发现更多潜在问题。此外，建议把错误分析的输出结果保存下来，积累成错误案例库，这些真实出错样本是后续优化提示词的宝贵素材，也能帮助你判断当前使用的模型在哪类推理任务上可靠性最低，从而决定哪些任务必须引入人工复核。
错误分析提示词的价值不只是修正单个错误，更在于它把模型的黑盒推理过程变成了可检查、可干预的对象。掌握这套方法后，你会发现在数学求解、逻辑分析和代码调试等场景中，模型的输出可靠性可以得到稳定提升，而这正是提示词工程相比单纯等待更强模型发布的务实选择。