这个念起来很拗口的观点连奥特曼都转发了，

他还反思 OpenAI 后续要做的一件事就是让推理模型更易用。

简单来说，就是我们以往跟聊天模型（GPT、Gemini、Claude等）的对话习惯反而会拖累 o1。就比如每次提问都要等上5分钟，结果出来的几乎都是乱码、回答内容自相矛盾、还附带间歇性生成失败 debuff。

所以我那1500白花了？Sora 没用爽，o1 pro 也没用对？

为了能真正上手推理模型，我决定在这篇文章里拆解出这老哥是如何得到这个结论的！并带大家一起看看 o1 正确的打开方式是什么？以及是不是对其他推理模型也有效？

Here we go！

 技巧一、o1 是个“报告生成器” 

如果 o1 不是一个聊天模型，那它应该是什么呢？我们应该把它当作一个“报告生成器”。给它提供大量的上下文，在你常用提示语的长度基础上*10都不为过。给大家一个数值参考，我日常使用的提示语长度是 279 tokens。

理论上只要提供足够多的上下文，并告诉 o1 你希望生成什么样的输出，它就能一次性给出相当好的答案。

当然，o1 的提示语结构也发生了很大的改变。从官方文档里可以得知3个关键点：

1. 保持提示简单直接，o1 不需要大量的指导
2. 避免思维链提示，o1自带推理，所以没有必要再提示 o1 “一步一步思考”
3. 提供上下文或文档时，仅包含最相关的信息，以防止模型的响应过于复杂。

官方文档?：https://platform.openai.com/docs/guides/reasoning#advice-on-prompting

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 的显式设定，提供低/中/高3档来控制模型的推理深度（resoning_effort）。

所以有时候网页版的 o1就会出现“过度思考”的情况，也就是面对简单的问题，o1 也会用大量时间进行推理，且它还不会主动询问你，挖掘更多的上下文。

那最直观的方式就是把所有的上下文都丢给 o1。

这里补充一个一次性给 o1 输入几千 tokens 上下文的小技巧：

用 Mac / 手机自带的语音备忘录，口述要做的事情，然后把转录的文本贴到对话框，不需要担心过于口语化。

 技巧二、别教 o1 做事 

除了长上下文，提示语第二重要的part就是在开头明确说明自己的“目标”，这里不是指教模型怎么做，而是直接告诉它“我想要什么”。

以前跟聊天模型对话时，我通常会告诉模型：

“你是某个领域的专家。请慢慢思考并仔细推理”，也就是告诉它“怎么做”。

但 o1 有聪明的脑子，支持“自动推理”，自己去规划和执行所需的步骤，因此不需要告诉它具体的“做法”，强调我们要什么就好。

PS：最好一次只问一个具体问题，o1 只能在最开始时进行推理

 技巧三、清楚 o1 擅长什么 

1. 一次生成整个文件或多份文件

给它贴大量代码、贴上关于你在做什么的上下文，o1 往往能一次性把整个文件（甚至多个文件）都搞定，基本不出错，而且还会遵循已有的代码风格。

1. 医学诊断

据 Ben Hylak 给出的数据，o1 能正确诊断出 60% 的皮肤问题，而且会出一份相当准确的鉴别诊断清单（differential diagnosis），是可以将这个给医生参考的程度。

1. 概念解释

o1 擅长解释一些非常困难的工程概念，还会提供例子。基本上是生成了一篇完整的文章。还可以让 o1 生成多个可行方案，并给出优缺点甚至做互相比较。

而 o1 目前不适合用来写作、或者从零构建应用。

你很难通过提示语改变 o1 的写作风格，它想得太多，写出来的内容基本都是学术报告。

虽然前面提到了 o1 能一次性生成整个或多个文件，但它目前还不能直接创建出完整的Saas，更实际的用法是提供完整的代码上下文，实现一个个小模块。

 对其他推理模型是否有效 

刚好上次我集中测试了六大推理模型的效果，

智谱正式发布GLM-Zero，我对比了6款类o1模型，这就是最会端水的AI ！

这次从剩下五个随机抽了1个来试试水，等 o3-mini 登场，我们再来个全模型测试。

应该不会等很久才能测上吧……奥特曼自己都偷偷回复了：“o3暂时不会开放，o3-mini 上线的时间不远了，会先提供给 Plus用户使用。API的定价还没确定，但不会很贵。”

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

带了推理提示语后，gemini-2.0-flash-thinking会思考不同的代码格式，主动解释起了代码每个部分，最重要的是可算完成了代码生成（感动）

为此我还额外做了一个 Coze，让大家更好地从对话式的模型转变到全新的推理模式，通过来回对话，你就能得到一个“推理模型专用提示语”。

不过目前还需要更多的调试来加长上下文，我想了几个优化点，比方说通过“知识生成”这个提示语技巧，让模型主动罗列与问题相关的知识，后面会持续迭代更新。

Coze链接?：https://www.coze.cn/s/iy3y9BKP/

 写在最后 

在整理这篇文章参考资料的时候，

我发现 Ben Hylak 还提出了一个疑问❓，或者应该叫研究课题。

 延迟会从根本上改变产品体验 

很多聊天模型已经可以做到1-2秒就开始流式生成结果，

而以 o1 为代表的推理模型却动不动就要等5分钟以上。

那我们可以合理推测，推理时间带来的差异也将影响未来 AI 应用的形态。

o1 将会催生出能合理利用长时间后台推理的产品，

但用户愿意为哪些任务等待 5 分钟？1 小时？1 天？甚至 3-5 个工作日？

这也许会为更多的产品提供了更多新的可能。

我期待着。