推理模型提示工程指南：什么时候用、怎么写提示、怎么控成本

同一句提示，丢给普通 GPT 模型和丢给推理模型，效果可能完全不同——不是模型能力问题，而是写法错位：普通模型的提示工程教你怎么"教步骤"，推理模型恰恰不需要你教。本文基于官方 Reasoning Best Practices（2026-09-01 核对），讲清推理模型的适用任务、提示写法规则与推理 token 的成本控制，并把 GPT-5.6 时代的 reasoning.effort 与 o-series 的分工讲清楚。

1. 先分清：谁是 planner，谁是 workhorse

官方对两条模型线的定位比喻很直白：o-series 是 planner（规划者）——为复杂任务想得更久更深，擅长策略制定、方案规划、基于大量模糊信息做决策，适合本来需要人类专家的领域（数学、科学、工程、金融、法务）；低延迟的 GPT 模型是 workhorse（执行者）——为明确定义的任务的快速执行而生。

最常见的生产架构是两者混用：推理模型做规划与决策，GPT 模型做执行。选择标准官方也给了：

GPT-5.6 时代的特殊之处：GPT 模型自己也有了推理旋钮——reasoning.effort 从 none 到 max 连续可调。所以现在的决策顺序是：先在 GPT-5.6 上调 effort，不够再上 o-series（o-series 的 effort 固定 max，慢且贵，留给必须答对的场景）。调参细节见本站 《reasoning.effort 调参实战：把推理深度变成可调参数》。

2. 七类最值得交给推理模型的任务

官方从客户与内部实践中总结的七类高价值场景，可以直接当作用例清单：

1. 歧义任务：信息不全、多源信息混杂时，推理模型能用简单提示理解意图、补全空隙——甚至会先提澄清问题，而不是瞎猜。
2. 大海捞针：传入大量非结构化信息时，擅长只抽出与问题最相关的部分——典型场景是从几十份合同里找出影响交易的关键条款。
3. 跨文档综合：对几百页稠密文档（法务合同、财报、保险理赔）做关系推理，能在任何单一文档都不明说的层面上得出结论。
4. 多步智能体规划：推理模型当 planner，产出详细的多步方案，再把每步分配给合适的 GPT 模型执行（按"高智能"还是"低延迟"选执行者）。
5. 视觉推理：结构模糊的图表、画质差的照片这类难视觉输入的解读。
6. 代码评审：大批量代码的评审与质量改进——延迟高但可以后台跑，对跨文件 diff 的细微改动检出率高。
7. 模型输出评审（LLM-as-judge）：用推理模型给其他模型的输出打分、做数据校验，尤其是细粒度差异的评判。

反面清单同样重要：定义明确的执行类任务（分类、格式化、改写、简单抽取）不值得上推理模型——慢且贵，收益为零。

3. 提示写法：少技巧，多约束

官方最佳实践的核心结论只有一句话：推理模型用简单直接的提示效果最好。展开成六条可执行规则：

1. 删掉思维链指令。"think step by step"、"explain your reasoning" 这类提示不仅无益，有时有害——模型内部已经会推理，你教的是它默认就在做的事。
2. 提示保持简短直接。模型擅长理解简短清晰的指令；堆砌技巧不如把要求说清楚。
3. 用分隔符组织输入。markdown、XML 标签、小标题，把背景资料、任务、输出要求切成清晰的区块，帮助模型正确解读各部分。
4. 先试 zero-shot。推理模型通常不需要示例就能产出好结果；确有复杂输出要求时再加少量示例，且示例必须与指令严格一致——不一致会劣化结果。
5. 显式给出约束。"给一个预算 500 美元以内的方案"式的硬约束直接写进提示，不要指望模型自己猜边界。
6. 把成功标准说具体。告诉模型什么样的响应算成功，并让它持续推理迭代直到满足标准。

一个对照示例——同一个需求，左边的写法是普通模型习惯，右边才是推理模型习惯：

# 旧习惯（对推理模型是反模式）
请一步一步思考，先列出所有可能的付款条款位置，
再解释你的推理过程，最后给出总结……

# 推理模型习惯
总结以下合同中的付款条款：金额、账期、违约利息。
只输出 JSON 数组，每项含 amount / term_days / penalty_rate 字段，
金额无法确定时对应字段填 null。

<contract>
{合同全文}
</contract>

要点全在第 3、5、6 条：分隔符包住原文、输出格式是硬约束、成功标准可验证——一个"怎么想"的字都没写。

4. 成本控制：推理项（reasoning items）的传递机制

这是多轮工具调用场景下最容易被忽略的一笔账。官方文档的机制描述：

• Responses API：从 o3 / o4-mini 一代起，函数调用相邻的部分推理项会被带进模型上下文。官方推荐用法：store 设为 true，用 previous_response_id 延续对话（或把上一轮的 output items 作为下一轮的 input 传入）——OpenAI 会自动纳入相关推理项、忽略无关项。模型不必在函数调用后重头推理，函数调用表现更好、总 token 更少。要更精细控制时，至少把"最近一次函数调用与上一条用户消息之间"的推理项都带上。
• Chat Completions：无状态 API，从不携带推理项。涉及复杂多轮函数调用的智能体场景，模型性能略降、推理 token 消耗更高；不涉及复杂多轮函数调用时，两种 API 表现没有差别。

落到一行结论：多轮工具调用的智能体，用 Responses API + store: true + previous_response_id，是官方推荐的省钱姿势。

from openai import OpenAI

client = OpenAI()
resp = client.responses.create(
    model="gpt-5.6-terra",
    reasoning={"effort": "high"},   # 多步任务开高档
    store=True,                     # 官方推荐：保存以便延续推理项
    input="在库存系统里查询 SKU-1234 的现货，若低于 10 件则生成补货单草稿",
)
print(resp.output_text)

# 后续轮次：用 previous_response_id 延续，推理项自动被复用
resp2 = client.responses.create(
    model="gpt-5.6-terra",
    reasoning={"effort": "high"},
    store=True,
    previous_response_id=resp.id,
    input="补货数量改为 50 件，重新生成",
)

Node.js 写法同构（reasoning: { effort } 同名参数）：

import OpenAI from "openai";

const client = new OpenAI();
const res = await client.responses.create({
  model: "gpt-5.6-terra",
  reasoning: { effort: "high" },
  store: true,
  input: "检查这份部署清单里的回滚步骤是否完整",
});
console.log(res.output_text);

5. 常见错误与排查

• 提示写得太"教练"：堆步骤、要过程、给一堆 few-shot——推理模型面前这些大概率是负资产。先做减法。
• 该用 effort 的场景上了 o-series：日常产品的"想深一点"需求，GPT-5.6 调 reasoning.effort 更便宜；o-series 留给必须答对的任务。
• 多轮函数调用还在用无状态方式：每轮都把历史重新拼进 input、不带推理项，模型每轮重头推理。切到 Responses API 的 previous_response_id 模式。
• 输出预算没给够：effort 高时内部推理消耗输出预算，预算太紧会拿到不完整的响应——调高输出上限或在提示里压缩不必要的输出格式。详见 《reasoning.effort 调参实战：把推理深度变成可调参数》 里的 incomplete 状态处理。
• 把"会推理"当"会澄清"：按官方描述，信息不全时推理模型往往会先提澄清问题、而不是瞎猜——前提是你的提示没有假装信息完备。

6. 下一步

• effort 档位怎么选、怎么算账：《reasoning.effort 调参实战：把推理深度变成可调参数》。
• 函数调用与工具使用的完整机制：《OpenAI API 函数调用实战：Responses API 工具使用完全指南》。
• 模型怎么选（speed vs accuracy 的完整决策表）：《GPT-5.6 选型指南：Sol / Terra / Luna 到底怎么选（2026）》。
• 提示工程的通用模式（与本文互补）：《Prompt Engineering 进阶：多轮上下文、结构化输出与 GPT-5.6 调优》。