不同提供商以不同方式提供推理能力。OpenAI在受支持的模型上使用推理强度和模式，Anthropic记录了自适应思考和扩展思考，Google则为受支持的Gemini模型记录了思考级别或预算。产品名称和参数会变化，因此应根据提供商的最新文档和任务实测表现作出选择，而不是依赖固定的模型名单。
部分推理模型适合的提示方式不同于非推理配置。对于OpenAI推理模型，当前指南建议从直截了当的提示词开始，不要索要思维链。至于脚手架、角色和自我批评等更广泛的说法，应将其视为需要在你的模型和工作负载上检验的假设，而不是可在不同提供商之间自动套用的规则。
本文将介绍推理模型是什么、何时使用、如何有效地提示它们，以及那些连经验丰富的AI用户也会踩中的坑。
推理控制项会改变什么
提供商使用推理、思考、强度和预算等名称来表示可能改变token用量、延迟和输出质量的控制项。根据提供商和配置不同，推理内容可能被隐藏、概述、省略，或在单独的数据块中返回。不要根据某个标签或最终答案的文风推测提供商隐藏的处理过程。
推理可以改善某些高难度多步骤任务的结果，但收益取决于模型、推理强度设置、提示词和评估。它也可能增加延迟和计费的推理token。因此，应通过基准测试决定选择低延迟配置还是增加推理，而不能把增加推理视为普遍升级。
2026年的推理产品系列示例包括：
- **OpenAI推理模式。**OpenAI已推出o系列模型和GPT推理模式；可用性和退役日期因产品和方案而异，因此在确定标准前请查看最新模型指南。
- 带思考能力的Claude模型。Anthropic最新文档说明当前Claude模型支持思考，但支持的配置各不相同：部分模型使用自适应思考，其他模型则不支持或已弃用手动
budget_tokens。应遵循各模型对应的表格，而不是套用一种通用参数配置。 - DeepSeek R1。R1论文介绍了这一模型系列及其训练方法。请查阅DeepSeek最新官方文档，确认受支持的模型和访问方式。
- **Gemini思考模式。**受支持的Gemini API模型提供由Gemini思考指南记录的提供商专用思考控制项。
- **其他提供商的产品。**产品名称、使用权限和控制项都具有时效性。在采用或推荐前，请通过提供商的最新官方文档核实。
这些产品的模型行为、支持的控制项、成本、延迟和推理输出的可见程度各不相同。不要假定某个参数或提示规则可以原样迁移到另一家提供商。
何时应测试增加推理
推理模型或更高推理强度可以作为对比候选。设计实验时，可以参考以下任务信号和边界：
- **问题包含相互衔接的多个步骤。**例如数学、逻辑、多步骤规划，以及需要跟踪状态的代码。
- **较低推理配置在相同评估用例上反复失败。**这时可以尝试推理模型或更高推理强度，并在同一批用例上比较两种配置。
- **任务需要仔细比较或分析权衡。**例如多标准决策、架构选择和供应商评估。
- **评估中包含较低推理配置会遗漏的边缘情况。**应直接测量这些情况，而不要根据文字是否流畅来推断推理质量。
- **任务影响重大。**不要仅仅因为风险高就选择增加推理。在财务、法律、医疗、安全或生产运维中，应使用权威来源、合格人员审核、经过验证的控制措施和有记录的决策边界，然后再测试推理配置是否改善了真正重要的用例。
以下场景中，较低推理的基线也可能具有竞争力：
- **对延迟敏感的对话式聊天。**只有实测质量收益足以抵偿较慢的交互时，才增加推理。
- **评估未显示收益的生成和起草任务。**较低延迟的配置可能更适合创意迭代；应比较输出质量，而不要预设增加推理一定有益或有害。
- **简单检索。**有依据的查询或较低推理配置可能以更低延迟和成本达到质量目标，但无论采用哪种方式，都要核实来源。
- **快速迭代优化。**较低延迟可能改善交互，但应比较最终任务成功率，而不是只计算对话轮数。
- **需要可审计中间证据的任务。**要求提供计算过程、来源、测试结果或其他可核验工件。可见的思维链叙述并不能证明结论正确。
一个实用的决策原则是：只有预期质量收益值得为该工作流付出实测延迟和成本时，才提高推理强度。
要比较的提示模式
先采用直接、以结果为中心的提示，再在可能显著影响结果时比较以下模式：
1. 将直接提示作为OpenAI基线
对于OpenAI推理模型，OpenAI的推理最佳实践指出，“逐步思考”等提示没有必要，有时还会妨碍表现。其他提供商提供不同的控制方式，因此请将直接提示与任何更结构化的备选方案进行测试比较。
**错误示范：**逐步思考。认真解决这个问题。展示你的解题过程。[problem]
正确示范：[problem]
清楚陈述问题并核验结论。对于其他提供商，请遵循最新文档，测试其支持的提示或控制项。
2. 比较直接提示与程序化脚手架
大量脚手架可能与推理模型已经执行的工作重复。先提供目标、相关上下文、硬性限制、所需证据和输出格式。只有评估表明简化后的提示仍能保留所需行为时，才删除程序化步骤。
**程序化候选：**首先列出关键限制条件。然后逐一列举选项。接着根据每项限制条件评估各个选项。然后作出选择，再说明理由。输出格式：……
**直接候选：**帮我在选项A和选项B之间作出决定。背景：[…]
更简洁的提示给模型留出选择方法的空间，同时保留真正需要遵守的限制和输出约定。
3. 测试技巧叠加，而不要预设它有效
思维链、自我批评和树搜索提示会增加指令和token。不要假定叠加它们可以改善评估结果。
如果提示词中包含“逐步思考，然后批评自己的答案，再进行修改”，请将其与更简洁的版本比较，并在有代表性的用例上保留表现更好的版本。
4. 仅在角色信息与任务有关时使用角色
复杂人设往往只会增加无法核实的细节，而不会改变任务。角色如果能界定范围、受众、政策或术语，就可以使用；否则应直接说明要完成的工作。如果角色看似改善了结果，应在同一批评估用例上确认收益，而不要凭直觉把效果归功于人设。
简短角色可以帮助设定语气和语域。需要一致性时，应将其与包含同等具体指令的版本比较。
**错误示范：**你是一位拥有20+年经验的世界级资深后端工程师……
**正确示范：**帮我分析这个分布式系统问题。[problem]
5. 索要证据，而不是隐藏的思考过程
部分产品会隐藏或概述内部推理。要求模型“展示推理过程”得到的是新生成的解释，不一定是模型的私有推理记录，也不能证明结果正确。
如果需要可审计性，请要求提供简洁理由和可核验证据。Anthropic当前API会根据模型和配置返回推理摘要或省略推理；两者都不能替代对结果的核验。
提示词中应包含什么
一个实用的基线应包括：
**具体信息。**提供解决和核验任务所需的数字、日期、确切限制、文件及其他输入。
输出约定允许时采用开放式表述。“情况是这样的。这是我想弄清楚的事情。你怎么看？”可以作为候选方案，用来比较更严格的模板。
**坦诚表达不确定性。**告诉模型你不知道什么。“我不确定是X还是Y；请帮我找出能区分二者的证据”比掩盖歧义更有帮助。
允许提出异议。“如果我的问题框架有误，请直接指出”或“告诉我还有什么没有考虑到”可以呈现那些寻求确认的提示会压制的备选观点。
**具体数据。**电子表格、代码和文档为模型提供可检查的真实工件。只有工具获准处理这些数据时才能共享，并删除任务不需要的信息。
完整示例
示例1：调试任务
假设你遇到了一个棘手的bug。
程序化脚手架提示：
你是一位专长TypeScript的资深软件工程师。逐步思考这个bug。
首先，找出相关代码。 其次，追踪数据流。 第三，找出可能的原因。 第四，建议修复方案。
bug描述：[description] 代码：[code]
直接提示：
帮我找出这个bug。
症状：[description] 相关代码：[code] 我已经尝试过：[list]
请在有代表性的bug上比较直接提示与脚手架版本，同时衡量正确性、所需证据、延迟和成本。不要仅凭这个示例推断直接版本更好。
示例2：战略决策
结构化提示：
你是一位资深战略顾问。我正在决定是否推出产品X。应用[framework name]框架。首先，……[long structured prompt]
直接提示：
我正在决定是否推出产品X。背景：
- 我们是一家有50名员工、ARR为$5M的公司。
- 这款产品需要2个季度才能完成开发。
- 它与我们的主要产品相邻，但不构成直接竞争。
- 我们排名前10的客户中，有两家提出了这项需求。
- 我们的团队产能已经非常紧张。
帮我全面分析。反驳薄弱的推理，并告诉我还有什么没有考虑到。
直接提示让模型可以自行选择分析结构。在将任一版本作为模板前，请依据相同决策标准，将其与结构化版本进行比较。
示例3：复杂代码分析
程序化脚手架提示：
分析这段代码的性能问题。逐步思考。首先识别数据结构，然后追踪算法复杂度，接着指出具体瓶颈。[code]
直接提示：
这段代码为什么这么慢？目前处理典型输入大约需要3秒；我希望将其缩短到500ms以内。
[code]
测试直接提示能否找出相关瓶颈并给出有效修复方案。请使用性能分析数据、测试和基准结果核验每一项建议。
推理模型特有的陷阱
以下是一些连经验丰富的用户也会踩中的坑：
**延迟。**增加推理可能延长响应时间，有时影响很明显。应测量你的模型和工作负载的实际延迟分布，包括超时，而不要按照笼统估计来规划。
**成本。**各提供商对推理的计费方式不同，模型价格也会变化。测量代表性请求实际计费的输入、输出和推理token，再比较整个任务的总成本，而不要假定固定倍数。
**响应达到生成上限。**各提供商对推理token和答案token的限制方式不同。如果响应提前停止，请检查提供商返回的停止原因和token统计。然后缩小任务范围，或只调整该模型明确支持的控制项；不要假定每个API都接受通用的思考预算。
**响应冗长、停滞或无效。**你可能观察到延迟异常漫长、超时、重复，或最终答案偏离任务。记录可观察到的故障及配置，然后在政策允许范围内重试、缩小任务，或比较另一项受支持的设置；不要仅凭输出声称自己知道隐藏原因。
**流畅但缺乏依据的结论。**增加推理不能证明答案正确。对于关键输出，应要求提供来源、计算过程、测试、假设，以及哪些新证据会改变结论；模型自报的置信度并不是经过校准的保证。
**请求之间的成本可变。**推理token用量会随任务和配置而变化。应跟踪实际用量，不要假定每次请求成本相同，也不要假定成本会随主观难度按可预测方式增长。
值得测试的路由工作流
一种候选方案是分阶段路由：
- 用较低延迟配置确定任务范围并识别子问题。
- 对基线未达到要求的已评估子问题，使用更高推理配置。
- 用获批的生产配置将已核验结果整理成目标格式。
将该路由与单一配置基线比较。测量任务通过率、证据完整性、交接错误、服务等级达标情况、端到端延迟和总成本。只有最终工作流表现改善到足以抵偿运维复杂性时，额外阶段才有价值。
下面以市场分析任务为例：
- 范围界定阶段：“我想了解X的市场。帮我确定分析范围：应该关注什么、需要哪些数据、哪些问题很重要？”
- 分析阶段：“根据我收集并核验的数据，可以针对[specific strategic question]得出什么结论？指出假设和证据缺口。”
- 格式整理阶段：“把核验后的发现整理成一份面向领导团队的单页简报。保留来源和不确定性。”
这种拆分是可测试的工作流，并非一定最优。应将其与单模型基线比较，测量质量、延迟和成本。
几个实用习惯
**定义符合条件的基线。**对比基线必须满足与推理候选相同的数据、安全、工具和输出要求。
**预先定义决策规则。**在看到结果前，确定质量指标、服务等级目标、成本边界和最低改善幅度。
**跟踪推理模型的成本。**无论是通过订阅服务级别监控还是API账单，都要了解自己每月的推理模型费用大致是多少，并相应调整使用方式。
**留意低延迟基线反复失败的情况。**这是在相同用例上测试更多推理的有效触发条件。
**一次只比较一项提示变化。**响应较弱时，分别测试更短的提示、补充上下文或不同的受支持推理设置，确保结果可以解释。
依据证据选择
推理配置并非自动更好或更差。先使用清晰、直接的提示，保留真实限制和证据要求；只有代表性评估证明有益时，才增加结构或推理强度。
请有意识地使用推理，并从简洁提示开始。先用低延迟模型探索，再针对评估暴露的瓶颈增加推理，这是一种值得与单模型工作流比较的模式。
