推理模型解决问题的关键步骤

很多人用推理模型解数学题、写复杂逻辑代码或做方案推演，结果要么卡在「想太久还答错」，要么答案看着对、一验算全是漏洞。问题往往不在模型，而在题目没拆、约束没给、结果没验。这篇按顺序讲清每一步做什么、什么时候该换路子。

很多人用推理模型解数学题、写复杂逻辑代码或做方案推演，结果要么卡在「想太久还答错」，要么答案读着挺顺、一验算全是漏洞。问题往往不在模型本身，而在题目没拆、约束没给、结果没验。这篇按顺序讲清每一步做什么、什么时候该换路子。整篇只讲一个角度：把成功率提上去的可执行步骤。

先说明白一点：下面这套步骤不是万能药。如果任务本身是开放式的、没有唯一可验证答案，或者你根本没法判断输出对错，那执行力再强也提不上成功率，这时候该换的是任务类型，不是提示词。

先判断这题该不该交给推理模型

第一步不是写提示词，而是判断该不该上推理模型。用错模型，后面的拆题和验算全是在给一个本来就不合适的任务打补丁。判断标准很简单：看标准答案长什么样。

• 适合的题：逻辑推演、复杂计算、代码排错这类多步推导、需要传递中间量、答案唯一可验的任务
• 不适合的题：纯改写润色、格式转换、单轮事实查询，这些用普通对话模型更快更省
• 拿不准时的分界线：标准答案是「一个能验证的结果」就值得上；标准是「读起来顺」，就别浪费等待时间
• 术语拿不准的，先去 /ai-dict/category/tips 对照一下说法，避免把一个查询任务当成推理任务

把题目拆成模型能一步步走的台阶

确定要上推理模型之后，别急着把整道题丢进去。推理模型擅长在给定台阶上一步步走，不擅长自己找台阶。你要做的是把大问题切成分问题，并把每步的输入输出关系交代清楚。

1. 定输入输出格式先告诉它已知条件有哪些、最后要什么形式的结果。格式越死板越不容易跑偏，比如要求「最后一行只给数值，不写单位」。
2. 切子问题把大问题拆成几个可判断对错的子问题，逐个说明依赖关系，明确哪一步的输出要喂给下一步，避免模型自己跳步。
3. 补隐含条件把单位、取值范围、边界情况、必须满足的约束都显式写出来。这些是推理模型最常见的翻车点，不写它就自己猜。
4. 逐个击破再合并一次只让它解决一个子问题，全部做完再合并。比一句话丢一个大问题稳得多。

拆得对不对有个简单检验法：把拆解后的每一步单独拿出来，问自己「这一步的结果我能不能独立判断真假」。如果某一步你也没法判断，说明台阶还是太大，得继续切。返回去补条件之前，可以顺手到 /tools/speed-test 看看当前用的通道响应情况，等待时间长不代表推得对。

提示词怎么写：给约束、要过程、留退路

题目拆好之后，提示词的写法决定模型会不会把该省的省了、该说的说了。核心就三件事：先给约束，再要过程，最后给一条「不知道就说不知道」的退路。

先结论还是先过程

两者选一个并写清楚，否则容易得到一段读着通顺但没结论的推理

要过程的具体问法

要求它列出每一步用到的条件，方便你事后逐步核对，哪一步条件用错了能直接定位

留退路

要求它在信息不足时说明缺什么，而不是编一个假设继续推，这一步能过滤掉大量看着合理实则虚构的答案

换问法复跑

同一道题换一种问法再跑一次，两次结果不一致的部分就是重点验算对象

这里说的复跑是通用方法，不涉及任何具体跑分。换问法时不要只改措辞，最好改变切入角度，比如第一次从已知推向结论，第二次从结论反推条件，两次对不上的地方才有排查价值。

• 明确写出「如果不确定，请指出缺哪条信息」，而不是留白让它自由发挥
• 要求分步输出，但别要求「请一步步详细思考」，重点是每步的条件，不是字数
• 把变量、单位、边界条件用清单形式列在题面开头
• 一次对话只处理一道题，混着问会互相污染上下文

验算与纠错：把答案当成待验证的草稿

推理模型的输出一律当作草稿，不是结果。验算不是重读一遍看顺不顺，而是把答案代回原始条件、逐步核对。验不过去，就带着「哪一条不满足」回去追问，而不是简单说「你错了再算一次」。

• 正向验算不通过时，别只说「错了」，把「哪一条不满足」原样贴回去追问
• 反向验算别问「对不对」，要问条件和反例，模型对「对不对」往往只会重复原答案
• 分歧处理顺序：先查自己有没有漏给条件，再查题目本身有没有歧义，最后才怀疑模型能力，前两种占大多数
• 多轮时每轮结束把已确认的中间结论固定下来带上，避免模型后面把前面推好的结果改掉

把模型当成一个会写草稿的同事：草稿可以快，签字前必须自己核。