我把 o1 当成了一个聊天模型，但它根本就不是一个聊天模型。 –Ben Hylak｜前苹果、SpaceX工程师
这个念起来很拗口的观点连奥特曼都转发了，
他还反思 OpenAI 后续要做的一件事就是让推理模型更易用。
简单来说，就是我们以往跟聊天模型（GPT、Gemini、Claude等）的对话习惯反而会拖累 o1。就比如每次提问都要等上5分钟，结果出来的几乎都是乱码、回答内容自相矛盾、还附带间歇性生成失败 debuff。
所以我那1500白花了？Sora 没用爽，o1 pro 也没用对？
为了能真正上手推理模型，我决定在这篇文章里拆解出这老哥是如何得到这个结论的！并带大家一起看看 o1 正确的打开方式是什么？以及是不是对其他推理模型也有效？
Here we go！
技巧一、o1 是个“报告生成器”
如果 o1 不是一个聊天模型，那它应该是什么呢？我们应该把它当作一个“报告生成器”。给它提供大量的上下文，在你常用提示语的长度基础上*10都不为过。给大家一个数值参考，我日常使用的提示语长度是 279 tokens。
理论上只要提供足够多的上下文，并告诉 o1 你希望生成什么样的输出，它就能一次性给出相当好的答案。
当然，o1 的提示语结构也发生了很大的改变。从官方文档里可以得知3个关键点：
-
保持提示简单直接，o1 不需要大量的指导 -
避免思维链提示，o1自带推理，所以没有必要再提示 o1 “一步一步思考” -
提供上下文或文档时，仅包含最相关的信息，以防止模型的响应过于复杂。
官方文档🔗：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 擅长什么
-
一次生成整个文件或多份文件
给它贴大量代码、贴上关于你在做什么的上下文，o1 往往能一次性把整个文件（甚至多个文件）都搞定，基本不出错，而且还会遵循已有的代码风格。
-
医学诊断
据 Ben Hylak 给出的数据，o1 能正确诊断出 60% 的皮肤问题，而且会出一份相当准确的鉴别诊断清单（differential diagnosis），是可以将这个给医生参考的程度。
-
概念解释
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 个工作日？
这也许会为更多的产品提供了更多新的可能。
我期待着。
@ 作者 / 卡尔 @ 动手学AI知识库 / learnprompt.pro
（文：卡尔的AI沃茨）