如果你用过 OpenAI 的 o 系列模型（如 o1, o3, o4），你肯定注意到了一个令人不安的现象：停顿 (The pause)。
多年来，我们一直在为速度优化大型语言模型（LLM）。我们追求近乎即时的文本生成，以毫秒为单位衡量延迟。但 2024 年末标志着计算机科学的一个关键转折点：从 训练时计算 (Training-Time Compute) 向 推理时计算 (Inference-Time Compute) 的转变。
所谓的 “o1 范式” 不仅仅是一次模型更新；它是 AI 系统 2 思维 (System 2 thinking) 的工业化。它以速度换取智力，在开口说话之前，先消耗计算资源进行沉默的“思考”。
这就是为什么这一变化彻底改变了开发者和工程师的游戏规则，以及你需要如何调整你的工作流。
核心概念：推理时计算 (Inference-Time Compute)
要理解 o1，你必须理解 推理扩展定律 (Scaling Laws of Inference)。
以前，AI 的智力上限取决于在其训练阶段（从互联网学习的那几个月）投入了多少算力。一旦训练完成，模型就是静态的。它是一个“系统 1”思考者——反应迅速、依靠直觉，但在处理复杂逻辑时容易产生幻觉。
o1 范式引入了一个新变量：测试时计算 (Test-Time Compute)。通过允许模型生成“隐藏 Token”——即用户永远看不到的内部思维——模型可以在 API 调用期间进行自我修正、规划和回溯。
系统 1 vs. 系统 2
- 系统 1 (GPT-4o, Claude 3.5 Sonnet): “快思考”。模式匹配。擅长创意写作、简单代码生成和总结摘要。
- 系统 2 (o1, o3-mini, DeepSeek R1): “慢思考”。深思熟虑的推理。擅长架构设计、复杂数学和法律分析。
性能与算力之间的关系已经改变。我们现在的扩展定律可以近似为：
这意味着我们不仅可以通过训练更大的模型来获得更高的智能，还可以通过让模型“思考”更长时间来实现。
可视化隐藏思维链
下图展示了推理模型 (Reasoning Model) 与标准 LLM 的区别。
graph TD
A["用户提示词 (User Prompt)"] --> B{"模型类型"}
B -- "标准 LLM (GPT-4o)" --> C["Token 预测"]
C --> D["即时输出"]
B -- "推理模型 (o1)" --> E["启动隐藏思维链 (Hidden Chain-of-Thought)"]
E --> F["拆解问题"]
F --> G["起草方案"]
G --> H{"需要自我修正吗?"}
H -- "是 (发现错误)" --> F
H -- "否" --> I["综合最终答案"]
I --> D
style E fill:#333,stroke:#fff,color:#fff
style F fill:#333,stroke:#fff,color:#fff
style G fill:#333,stroke:#fff,color:#fff
style H fill:#333,stroke:#fff,color:#fff
代码实战：处理推理 Token
在使用 o1 类模型进行开发时，你需要为 推理 Token (Reasoning Tokens) 付费。这些是模型在思考过程中生成的隐藏 Token。它们不会出现在最终回复中，但会消耗你的上下文窗口 (Context Window) 和预算。
以下是如何使用 OpenAI SDK (v1.50+) 构建请求的示例，特别关注用于控制模型思考强度的 reasoning_effort 参数。
from openai import OpenAI
import os
client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))
# 定义一个复杂的逻辑任务
prompt = """
设计一个用于分布式任务调度器的 Python 类层次结构。
它必须使用乐观锁处理竞争条件，并支持具有不同层级的优先级队列。
"""
response = client.chat.completions.create(
model="o1", # 或 "o3-mini"
messages=[
{"role": "user", "content": prompt}
],
# 'reasoning_effort' 控制隐藏思维链的深度。
# 选项: "low", "medium", "high"
reasoning_effort="high"
)
# 提取内容
final_answer = response.choices[0].message.content
# 查看用量以了解“思考成本”
usage = response.usage
input_tokens = usage.prompt_tokens
output_tokens = usage.completion_tokens
# 'reasoning_tokens' 是 completion_tokens 的子集
reasoning_tokens = usage.completion_tokens_details.reasoning_tokens
print(f"最终答案长度: {len(final_answer)} 字符")
print(f"总输出 Tokens: {output_tokens}")
print(f"隐藏推理 Tokens: {reasoning_tokens}")
代码的关键启示：
如果 reasoning_tokens 是 4000，而你看到的可见输出只有 200 个 Token，这说明模型在写第一行代码之前，已经消耗了大量算力来“思考”架构。
分步指南：如何为推理模型写提示词 (Prompting)
旧习惯很难改。那些对 GPT-4 行之有效的提示词工程技巧（如思维链提示 CoT、“深呼吸”）现在已经变成了反模式 (Antipatterns)。它们会干扰模型原本的推理过程。
- 停止要求“一步步思考”：
不要要求模型“一步步思考 (think step-by-step)”。它在隐藏层中原本就在做这件事。强迫它在可见输出中这样做会降低性能并浪费 Token。 - 使用 “Developer” 消息，而非 “System”：
对于 o1-preview 和早期 o1 版本，system角色通常被弃用，取而代之的是user或developer角色，以避免限制其推理能力。（随着 API 的快速演进，请随时查阅最新规范）。 - 重上下文，轻指令：
不要告诉模型如何思考（指令），而要给它更多关于思考什么的数据（上下文）。- 坏写法： “解决这个逻辑难题。首先列出变量，然后定义约束条件……”
- 好写法： “解决这个逻辑难题。这是变量、约束条件以及期望的输出格式。”
- 管理上下文窗口：
推理 Token 计入上下文限制。如果你的输入提示词极其巨大（例如 100k Token），模型用于思考的“草稿纸”空间就会变少。对于复杂任务，请使用 RAG（检索增强生成）只投喂相关的片段。 - 使用分隔符：
清晰地构建你的提示词。当数据被模块化隔离时，推理模型表现最佳。<policy_document> [插入文本] </policy_document> <user_query> [插入查询] </user_query>
o1 范式标志着“凭感觉 (vibe-based)” AI 时代的终结，以及可验证推理时代的开始。我们不再只是在提示文本；我们是在提示思维。你的工作不再是手把手地引导模型，而是清晰地定义问题，让它能够引导自己。
外部资源
- OpenAI 研究： Learning to Reason with LLMs
- arXiv 论文： Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
- 官方文档： OpenAI Reasoning Best Practices