推理模型的提示词用法大不同：为何你现有的模式在 o1、o3 和 Claude 扩展思考上会失效
大多数团队在采用推理模型时都会做同一件事：把现有的系统提示词复制过去，指向 o1 或带扩展思考的 Claude Sonnet，然后期待模型升级完成剩余工作。基准测试分数上去了，生产准确率却原地踏步——甚至下滑。问题不在模型，而在于提示词的思维模型从未改变。
推理模型的工作方式与指令跟随模型截然不同。那些能从 GPT-4o 榨取性能的策略——精心设计的系统提示词、精选的 few-shot 示例、明确的"逐步思考"指令——都是为另一种推理架构设计的。把这些策略用在推理模型上，恰恰会限制那些让这类模型具有价值的核心能力。
本文是一份实用指南，聚焦于真正重要的差异以及切实有效的调整方法。
解释一切的架构差距
标准大语言模型被优化为在给定上下文窗口的情况下预测下一个 token。它们非常擅长模式匹配：如果你给它们展示想要的输出格式示例，它们就会按那个格式输出；如果你让它们逐步思考，它们就会输出看起来像逐步思考的文字。
推理模型的运行方式不同。在生成响应之前，它们会运行一个内部搜索过程——一种隐藏的思维链，在给出答案之前探索并剪枝解题路径。这个思考过程发生在可见输出之外（或者在单独的思考块中，取决于具体实现）。最终的响应不是思考过程本身，而是模型在思考之后做出的决策。
这一区别重塑了"好提示词"的含义。对于指令跟随模型，你是在塑造 token 预测；对于推理模型，你是在界定一个搜索问题。有助于前者的指令往往会干扰后者。
为何"逐步思考"已成废话
经典的思维链提示——"逐步思考"、"仔细推理"、"在回答前逐一分析每个部分"——是大语言模型提示词工程中最经过验证的技术之一。它能持续提高指令跟随模型的准确率，做法是强制模型将中间推理过程作为输出 token 呈现出来，这些 token 再反过来影响后续 token 的预测。
在推理模型上，这些指令毫无用处。模型已经在内部逐步思考了，你是在要求它做它本来就在做的事，代价是消耗 token 并可能引入干扰。
OpenAI 针对 o 系列模型的官方指南对此说得很明确：这些模型在你信任其固有推理能力、而非指导其推理过程时表现最佳。加入思维链指令 不能改善内部搜索，只会给上下文窗口增添噪音。
这不是微小的性能差异。有些团队把包含大量思维链的复杂提示词迁移到推理模型后，反而看到准确率下降，因为模型把上下文和注意力分配给了那些与其本来就会进行的推理相互竞争的指令。
Few-Shot 的逆转
对于标准模型，few-shot 提示是方法库中性价比最高的技术。提供 4 到 8 个精心挑选的示例，能显著改善输出格式、风格和任务准确率。支持这一结论的研究数量众多，几乎没有争议。
但对于推理模型，这一结论发生了翻转。2025 年一篇重审思维链提示的论文发现，对于 Qwen2.5 系列等强推理模型，加入传统思维链示例相比零样本并未改善性能。其背后机制在于：强模型不像弱模型那样从示例中学习，它们基本上会忽略示例，直接响应任务描述。这些示例限制了模型的探索空间，却没有提供有效信号。
DeepSeek 记录了推理语言模型上的同一问题：标准的 few-shot 思维链示例会损害性能，这也是他们自己的评测基准使用直接推断而不带示例的原因。OpenAI 对 o 系列的指南同样明确："推理模型通常不需要 few-shot 示例也能产出好结果。"
对实践者的直接影响：对推理模型，你的默认选择应该是零样本。只有当你有实证证据证明示例对特定任务有帮助时，才添加示例——并且要用消融实验来验证这个假设，而不是凭直觉。
长系统提示词是税，不是资产
对于指令跟随模型，更长、更详细的系统提示词通常会在一定程度上产生更好的结果。把预期的输出格式、人设、约束列表和行为准则都写清楚，对这类模型都有帮助。模型是模式匹配器；你提供的模式越多，它匹配得越精准。
推理模型颠覆了这种关系。扩展思考需要空间来探索。一个列举了 20 条行为约束的系统提示词，不会让模型推理得更好——它会制造 20 个相互竞争的目标，模型会对这些目标进行优化，而不是探索完整的解题空间。模型会满足约束，而不是寻找最优答案。
Claude 扩展思考的指南特别指出：精心设计的系统提示词往往会以降低复杂任务质量的方式约束推理搜索空间。最优的做法是简短、以目标为中心的提示词，说明你需要什么，而不指定如何实现。
这对于拥有多年积累的系统提示词工程实践的团队来说是个艰难的调整。在指令跟随模型上，精确指定一切的直觉是通过实践磨练出来的，通常是正确的。在推理模型上，同样的直觉会产生更差的输出。更短通常更好——不是因为精确度不重要，而是因为推理模型填补空白的方式与模式匹配模型不同。
多目标指令失效
当你向推理模型加载多个相互竞争的目标时，会出现一个相关的失效模式。标准模型在 token 预测期间平衡目标，处理起来相当优雅。推理模型的处理方式不同：内部搜索过程会锚定在满足约束集上，模型会找到一个局部最优解 来通过所有要求，而不是进行全局最优推理。
症状看起来像是一个技术上合规但错过了重点的模型。每条指令都被遵循了，但实际的任务质量却低于只给出核心目标的简单提示词所能达到的水平。
解决方案是提示词分解：如果你有多个目标，就无情地排列优先级，只陈述最重要的一两个。将复杂的多目标任务路由到专门的提示词，而不是试图在一个系统提示词中处理所有情况。如果你构建的系统围绕着一个处理所有情况的"全能提示词"——这是反直觉的，但推理模型更偏向窄而深的提示词，而不是宽而浅的提示词。
过度指定下的优先级倒置
多目标问题有一个更微妙的变体：优先级倒置。当你在推理模型上堆叠大量指令时，模型的内部搜索不会保留你的隐式优先级排序。系统提示词顶部的指令，不会自动优先于中间某处的指令。
标准模型通过注意力机制表现出可预测的优先级递减——长上下文窗口末尾的指令获得较少的注意力。推理模型有不同的失效模式：它们会整体满足约束集，低优先级的边缘情况指令可能最终主导解决方案，因为它们成了约束条件中的瓶颈。
实际含义：如果你有关注层级（例如正确性 > 格式 > 冗余度），请明确写出来，而不是依赖排序。并保持列表足够短，以避免隐式优先级造成倒置陷阱。
真正有效的方法：一套框架
基于官方指南和实证研究，推理模型的提示词模式大致如下：
从零样本开始。 默认不添加示例。清晰陈述任务，附上明确的成功标准，让模型推理。如果准确率不足，先添加领域上下文，再考虑添加示例。
陈述目标，而非过程。 告诉模型你需要什么，而不是如何思考。"分析这份合同条款是否在 GDPR 下存在任何合规风险"，比一套规定推理路径的逐步分析框架效果更好。
保持系统提示词最简。 两到三条有针对性的指令，优于十条分散的指令。如果你的系统提示词超过几百个词，就寻找可以删除而不是精炼的指令。
明确注入领域上下文。 推理模型的世界知识召回往往比指令模型更窄——它们以广度换深度。如果你的任务需要特定的技术上下文，直接提供，而不是依赖模型自行回忆。
用分隔符提供结构，而非指令。 使用 XML 标签或 Markdown 标题来分隔输入的不同部分（指令、上下文、实际查询），有助于推理模型解析你的意图，而不会约束其搜索空间。构建问题的结构；不要讲述解题方法。
若确实需要 few-shot 示例，务必精确。 如果消融测试表明示例对特定任务有帮助，确保示例与你想要的输出格式和质量完全一致。噪声或不一致的示例在推理模型上的危害，比在标准模型上更大。
识别你正在与模型对抗的信号
最有价值的诊断方法是零样本消融。对于任何未达到准确率目标的推理模型提示词，把所有东西精简为任务的最简零样本版本，然后测量准确率。如果零样本匹配或超过了你精心设计的提示词，那问题就出在提示词上。
除此之外，以下几个信号表明你正在限制模型的推理：
- 简单查询上思考 token 消耗激增：如果直接了当的任务消耗了大量思考预算，模型可能在围绕你的约束推理，而不是直接解决问题。
- 技术上合规但语义上错误的输出：模型满足了所有明确要求，却错过了实际目标——这是约束优化而非真正完成任务的典型信号。
- A/B 测试中零样本优于 few-shot：直接证明示例在限制探索空间。
推理模型的提示词调试，要求把提示词视为搜索范围，而不是行为规范。关键问题不是"这条指令是否告诉模型该做什么？"——而是"这条指令是否不必要地缩小了推理空间？"
思维模型的转变
一个有用的重新框架是：给标准大语言模型写提示词，像是在为模式匹配器写规范；给推理模型写提示词，像是在向分析师做汇报。你给分析师目标、相关上下文和你想要的格式。你不会引导他们的思维过程。你越是规定他们应该如何推理，输出就越差。
这意味着减少在结构上的提示词工作量，更多聚焦于问题定义。任务到底是什么？什么算是好的答案？模型需要哪些它无法自行推导的上下文 ？这些问题比系统提示词设计的技巧更重要。
从推理模型中获益最多的团队，是那些停止试图设计推理路径、开始专注于清晰框定问题的团队。对于任何花了多年时间打磨精心提示词的人来说，这是反直觉的——但这才是杠杆所在。
从指令跟随模型到推理模型的转变，不只是模型升级，它需要更新那套花了多年时间建立的提示词思维模型。核心调整是：去除脚手架，陈述目标，让模型去思考。最难的部分是抵制再多加一条指令的冲动。
