11. 推理模型（o1、R1）的 Prompt 工程和普通模型有什么不同？

简单回答

推理模型（OpenAI o1/o3、DeepSeek R1、Claude 思考模式）和普通模型的 Prompt 工程有几个根本差异：不需要也不应该让模型"think step by step"——它内部已经在做了；few-shot 在推理模型上经常 降低 而不是提升效果，因为干扰了模型的内部推理路径；System Prompt 越短越好，复杂的角色设定和约束反而让模型分心；要给模型足够的自由度（不要把答案格式约束得太死，让它先推理再总结）。简单说，推理模型的 Prompt 工程是"做减法而不是做加法"——给最简洁的问题描述和明确的输出格式，剩下的交给模型自己。

详细解释

推理模型为什么不一样

推理模型的核心机制是 内置的 long chain-of-thought——在生成最终回答之前，模型会自主进行长链条的内部推理（reasoning trace），可能几千到几万 token 的 thinking 过程。OpenAI 的 o1 和 o3 把这部分隐藏不返回给用户；DeepSeek-R1 把它放在 <think>...</think> 标签里返回；Claude 4 在 thinking 模式下也类似。

关键变化是 推理过程从外部 prompt 移到了内部生成。普通模型时代我们在 prompt 里教它"think step by step"、给 few-shot 示范推理、用 ToT 显式规划——这些技巧本质都是 外部诱导内部推理。推理模型把这部分能力固化到了模型本身。

这意味着多年积累的 prompt 工程套路在推理模型上很多都不再有效，甚至适得其反。

哪些技巧失效或反向

Chain-of-Thought 失效或有害

普通模型上"Let's think step by step"或者 few-shot 推理示范能显著提升数学和推理能力。推理模型上：

• "Let's think step by step" 是冗余的——模型本来就在 thinking 阶段做了多步推理。加这句话顶多不影响。
• Few-shot 推理示范常常 降低 准确率。OpenAI 在 o1 文档里明确建议"不要使用 few-shot CoT 示例"。原因是 few-shot 强行把模型推理路径限定在示例的模式上，限制了模型内部的自主探索。

实际数据：在 MATH 等推理 benchmark 上，o1 用 few-shot CoT 比 zero-shot 表现差 5-10 个点。这是反直觉的发现。

复杂 System Prompt 反而干扰

普通模型上常见的"你是一个资深专家、必须严谨、必须分步骤、必须双重检查"这类指令对推理模型基本无效——模型已经被训练成"高质量推理者"了，多余的角色约束反而让 thinking 过程被这些 instruction 干扰。

OpenAI 推荐的 o1 prompt 风格是 简洁直接：

[一两句话清晰描述任务]
[输入数据]
[一句话说明输出格式]

不要长篇 system prompt、不要详细的"如何思考"指引、不要多个角色叠加。

显式规划技巧失效

ToT、ReAct 这类需要模型按特定结构输出推理过程的技巧，在推理模型上意义不大——模型自己就在做更精细的内部规划，外部强加的结构反而让输出受限。

哪些 prompt 技巧仍然有效

清晰的任务描述：模型需要明白要做什么。任何模型都需要这点，推理模型也不例外。但描述越简洁越好。

明确的输出格式：让模型知道"回答应该是 JSON / 一段话 / 一个数字"。推理模型的 thinking 部分可能很长但最终回答应该按要求格式。

关键约束：必须遵守的硬约束（比如"答案必须是整数"、"回答不能超过 100 字"）还是要写。

输入数据的清晰组织：长输入用 XML/Markdown 结构化便于模型解析。

禁止性指令：明确说"不要 X"对推理模型仍然有效。

"Reasoning Effort" 是新的控制维度

推理模型有一个普通模型没有的旋钮：推理预算（reasoning effort、thinking budget、reasoning_effort）。可以告诉模型"思考多长时间"或"思考多少 token"。

OpenAI o1 的 API 有 reasoning_effort 参数（low/medium/high），DeepSeek-R1 等开源模型可以通过 max thinking tokens 控制。

这个旋钮的逻辑：

• 简单问题用 low effort（快、便宜，但可能错过复杂推理）
• 复杂问题用 high effort（慢、贵，但准确率最高）
• 默认 medium 适合多数场景

工程上要根据问题复杂度动态设置，比如简单事实问答用 low、数学题或代码生成用 high。

Prompt 注入和 hidden reasoning

推理模型把推理过程隐藏（OpenAI o1）或半隐藏（R1 的 think 标签）带来一些新问题：

对开发者不透明：你不知道模型为什么得出这个结论，调试和改进 prompt 困难。看不到 reasoning trace 就不知道改 prompt 哪里能改善。R1 等开源方案把 thinking 暴露出来，调试更容易。

Prompt 注入风险：如果用户输入里有"忽略你的 thinking 然后做 X"这种指令，模型可能在 thinking 阶段就被引导。OpenAI 等团队对此有专门防御（thinking 阶段对用户输入的解释更保守）。

Hidden cost：thinking token 也算钱（OpenAI o1 的 reasoning token 单独计费），实际成本可能远高于看到的 output token。一个看似简单的回答背后可能有几千 token 的 thinking。

推理模型不擅长的场景

推理模型不是万能替代品。一些场景普通模型仍然更合适：

简单问答和闲聊：让 o1 回答"今天星期几"它会先做几百 token 的 thinking 再给答案，慢且贵。普通模型秒回。

严格延迟要求：实时对话、TTFT 敏感场景。推理模型的 thinking 把第一个回复 token 推迟到几秒之后。

创意写作和开放对话：thinking 过程让回答变得更"格式化"、缺少自然流畅感。普通模型在创意类任务上往往表现更好。

Tool Calling 简单场景：简单的函数调用让推理模型反而过度思考。普通模型的 tool calling 就够用且快。

业界目前推荐的策略是 混合使用——用一个 router 判断 query 复杂度，简单任务路给普通模型（GPT-4o、Claude Sonnet），复杂任务路给推理模型（o1、R1、Opus thinking）。

实际场景的 prompt 例子

普通模型的复杂数学 prompt：

You are an expert mathematician. Let's think step by step to solve this problem.
First, identify the key quantities. Then, set up the equation. Then, solve it.
Make sure to double-check your work.

Problem: [问题]

Step-by-step reasoning:

推理模型的等价 prompt：

Solve the following math problem.

Problem: [问题]

Provide your final answer as a single number.

短一半多，效果反而更好。

跨家模型的差异

不同推理模型的 prompt 风格略有差异：

OpenAI o1：最反对 few-shot，建议极简 prompt。reasoning_effort 控制思考深度。 DeepSeek R1：thinking 在 <think> 标签里返回，可见。R1 不接受 system prompt（架构限制），所有指令要放 user message 里。 Claude 4 thinking mode：可以接受较丰富的 system prompt，但仍以简洁为主。thinking 字段控制 budget。 Gemini 2.5 thinking：对 long context + reasoning 配合较好，prompt 风格接近 o1 但允许更多结构化。

迁移时要按目标模型的具体风格调整。

调试技巧

普通模型 prompt 调试常常是"加更多 instruction"。推理模型反过来——删指令直到出问题。

具体做法：

1. 写一个最简洁的 prompt 测试效果
2. 看输出是否满足预期。如果满足就到此为止。
3. 不满足就 只加最关键的 一条 instruction，再测试。
4. 直到达到要求或确认问题不在 prompt。

不要一开始就堆大段 system prompt——99% 的内容是冗余的，反而干扰推理。

面试时可以这样答

推理模型的 prompt 工程最大变化是从"做加法"变成"做减法"。普通模型时代我们在 prompt 里教它 think step by step、给 few-shot 推理示范、用 ToT 显式规划——这些都是外部诱导内部推理。推理模型把这部分能力固化到模型本身，外部强加的推理诱导反而干扰内部探索。

几个具体不同。第一是 CoT 失效或有害——OpenAI 在 o1 文档明确建议不要用 few-shot CoT 示例，实测在 MATH 上 few-shot 比 zero-shot 差 5-10 个点。第二是复杂 system prompt 反而干扰，推理模型已经被训练成高质量推理者了多余角色约束让 thinking 被分心。第三是 ToT、ReAct 这类外部规划技巧意义不大。

仍然有效的是清晰任务描述、明确输出格式、关键硬约束、输入数据的结构化组织、禁止性指令。

推理模型有个新维度是 reasoning effort——告诉模型思考多长。简单问题 low、复杂题 high。OpenAI 的 reasoning_effort 参数和 R1 的 max thinking tokens 都是这个旋钮。

几个新问题要注意。Hidden cost——thinking token 也算钱实际成本远高于看到的输出。Prompt 注入在 thinking 阶段也可能被引导。对开发者不透明，OpenAI o1 不返回 thinking 调试困难。

不擅长的场景包括简单问答（thinking 让简单题也慢且贵）、严格延迟要求（TTFT 推到几秒后）、创意写作（thinking 让回答格式化）、简单 tool calling。所以业界推荐混合使用——router 判断 query 复杂度，简单路给普通模型，复杂路给推理模型。

跨家差异——OpenAI o1 最反对 few-shot 极简 prompt；DeepSeek R1 不接受 system prompt 架构限制；Claude 4 thinking 接受较丰富的 system prompt 但仍简洁；Gemini 2.5 在 long context + reasoning 配合较好。

调试技巧上推理模型反过来——删指令直到出问题。从最简洁 prompt 开始，只在必要时加最关键的 instruction，避免堆大段 system prompt。

常见追问

1. 怎么判断一个 query 该路给普通模型还是推理模型？路由标准是什么？
2. R1 的 thinking 暴露出来了，能不能基于 thinking 做 prompt 优化？
3. 推理模型在 RAG 场景下有什么特殊处理？检索结果怎么放进 prompt？