本文深度解析了 OpenAI o1 的正确使用方式，是一份不容错过的实操指南。文章核心涵盖三大要点：揭示以往与 o1 对话的常见误区；详解如何将 o1 作为“报告生成器”高效运用；分享 o1 提示语结构的关键技巧。

这个看似反直觉的结论，连奥特曼（Sam Altman）本人也转发认可。他同时反思，OpenAI 接下来的一项重要任务就是让推理模型更加易用。

简而言之，以往与 GPT、Gemini、Claude 等聊天模型对话的惯性方法，反而会降低 o1 的性能。例如，每次提问等待五分钟，得到的却常常是乱码、自相矛盾的答案，甚至间歇性生成失败的负面效果。难道每月 1500 元的订阅费白花了？Sora 没玩痛快，o1 pro 也没用对？

为了真正掌握推理模型的使用诀窍，本文将拆解 Ben Hylak 得出这一结论的过程，并带领大家了解 o1 的正确打开方式，同时探讨这套方法是否适用于其他推理模型。

技巧一：o1 作为“报告生成器”

如果 o1 不是传统意义上的聊天模型，那它应当如何定位？答案是：将其视为一个“报告生成器”。需提供大量上下文，甚至可以在你常用提示语长度基础上乘以 10。一个参考数值：日常提示语平均长度为 279 tokens。理论上，只要给予足够丰富的上下文，并明确告知 o1 期望的输出格式，它就能一次性生成高质量的答案。

当然，o1 的提示语结构也发生了显著变化。根据官方文档，有三个关键要点：提示语应保持简单直接，o1 不需要过多的指导；避免使用思维链提示，因为 o1 自带推理能力，无需额外要求“一步一步思考”；提供上下文或文档时，仅包含最相关的信息，以防模型响应过于复杂。

Ben Hylak 还推出了一套完整的提示语结构，去掉了常见的角色扮演，保留了四大部分：目标、返回格式、给模型的限制以及上下文。

### 目标（Goal）
我想要一份在旧金山两小时车程内的最佳中等长度徒步路线清单。
每条路线都应该提供一次很酷而独特的冒险，并且相对不那么大众化。

### 返回格式（Return Format）
对每条徒步路线，需要返回：
- 在 AllTrails 上查找时的路线名称
* 徒步起点的地址
* 徒步终点的地址
* 距离
* 开车时间
* 徒步时长
* 这条路线有什么特别之处，能带来一次酷且独特的体验
请只返回排名前 3 的路线。
务必确保路线名称正确存在，并且时间信息准确。

### 警示（Warnings）
小心核实路线名称是否正确存在，以及时间是否准确。

### 上下文（Context Dump）
我的女朋友和我非常爱徒步！我们几乎把旧金山本地所有的徒步路线都走遍了，无论是 Presidio 还是金门公园。我们现在想离开市区活动一下 —— 最近我们刚去过 Mt. Tam（从楼梯起点一路走到 Stinson），那次真的很长。这周末我们想找些不一样的路线！能看到海景还是不错的。我们也很喜欢美味的食物。我喜欢 Mt. Tam 徒步的一个原因是它在旅程结束后会有种庆祝的感觉（进城后吃早餐！）。Discovery Point 附近那片导弹发射井遗址也很酷，但我已经走过那条路线大概 20 多次了。接下来几周我们见不到面（她因为工作要留在洛杉矶），所以这次路线的独特性对我们来说很重要。

为什么上下文长度如此重要？日常使用 GPT-4o 等聊天模型时，通常只需抛出一个问题和部分上下文，模型若需更多背景信息，会在对话过程中主动提问。通过多轮交互，逐步纠正模型错误，直至获得满意答案。但 o1 有所不同——网页版 o1 并不支持像 o1 API 那样显式设置低、中、高三档推理深度（resoning_effort）。因此，网页版 o1 容易出现“过度思考”现象：面对简单问题，也会耗费大量时间推理，且不会主动询问来挖掘更多上下文。最直接的方法，就是将全部上下文一次性提供给 o1。

此处补充一个小技巧：使用 Mac 或手机自带的语音备忘录录制口述内容，然后将转录文本粘贴到对话框，无需担心表述过于口语化。这样能一次性为 o1 提供数千 tokens 的上下文。

技巧二：不要教 o1 如何做

除了长上下文之外，提示语的第二个关键要素是在开头明确阐述“目标”——不是教模型如何操作，而是直接告诉它“我想要什么”。以往与聊天模型对话时，我们常会指示模型：“你是某个领域的专家，请慢慢思考并仔细推理”，即告诉它“怎么做”。但 o1 具备强大的自动推理能力，能够自行规划并执行所需步骤，因此无需告知具体方法，只需强调期望的结果即可。附注：最好一次只问一个具体问题，因为 o1 仅能在初始阶段进行推理。

技巧三：明确 o1 的擅长领域

o1 擅长以下几个领域：

• 一次性生成整个文件或多个文件：提供大量代码和相关上下文，o1 通常能一次性完成整个文件（甚至多个文件）的生成，几乎不出错，并会遵循已有的代码风格。
• 医学诊断：根据 Ben Hylak 提供的数据，o1 能正确诊断 60% 的皮肤问题，并生成一份相当准确的鉴别诊断清单，其专业程度足以供医生参考。
• 概念解释：o1 擅长解释极为复杂的工程概念，并附带实例，基本相当于生成一篇完整的文章。此外，还可让 o1 生成多个可行方案，并逐一分析优缺点，甚至进行相互比较。

而 o1 目前不适合用于写作或从零构建应用。很难通过提示语改变其写作风格，由于它思考过度，生成的内容往往偏向学术报告。尽管前面提到 o1 能一次性生成整个或多个文件，但当前它仍无法直接创建完整的 SaaS 应用，更实际的用法是提供完整的代码上下文，实现一个个小模块。

对其他推理模型是否同样有效

此前我们集中测试了六大推理模型的效果（智谱正式发布 GLM-Zero，对比了六款类 o1 模型），这次从剩余五个中随机抽取了一个进行尝试。待 o3-mini 登场后，将进行全模型测试——预计不会等待太久，奥特曼本人已回复：“o3 暂时不会开放，o3-mini 上线时间不远，将先提供给 Plus 用户。API 定价尚未确定，但不会很贵。”

在不带推理提示语的情况下，gemini-2.0-flash-thinking 在生成代码过程中确实会出现乱码，思考输出大量内容却忘记生成代码的情况：

而加入推理提示语后，gemini-2.0-flash-thinking 会思考不同的代码格式，主动解释代码的每个部分，最重要的是终于完成了代码生成。

此外，还可以利用 Coze 等 AI 工作流平台构建来回对话的流程，从而自动生成“推理模型专用提示语”。不过目前仍需更多调试以加长上下文，有几个优化点，例如通过“知识生成”这一提示语技巧，让模型主动罗列与问题相关的知识，后续可持续迭代。

结语

在整理本文参考资料时，发现 Ben Hylak 还提出了一个疑问或研究课题：延迟会从根本上改变产品体验。许多聊天模型已能做到 1-2 秒内开始流式生成结果，而以 o1 为代表的推理模型却往往需要等待 5 分钟以上。可以合理推测，推理时间差异也将影响未来 AI 应用的形态。o1 将催生出能合理利用长时间后台推理的产品，但用户愿意为哪些任务等待 5 分钟？1 小时？1 天？甚至 3-5 个工作日？这或许将为更多产品带来新的可能性。值得期待。