o1 不是一个聊天模型（这正是它的意义）[译]
Ben Hylak 如何从最初对 o1 Pro 持怀疑态度，到克服“技能问题”后成为粉丝。
swyx 在此：我们很高兴为大家呈现 2025 年的第一篇客座文章1。它在 gdb、Ben 和 Dan 的页面上引发了非常热烈的讨论。
自 10 月份 o1 发布以及 12 月份 o1 pro/o3 公告以来，很多人一直在努力形成自己的看法——无论是积极的，还是消极的。我们在 o1 Pro 负面情绪的最低谷 时就已经明确表达了强烈的正面支持，并分析了 OpenAI 如何有可能推出每月 2000 美元的 Agent 产品（传闻会在接下来几周内发布）。从那时起，o1 一直稳稳占据所有 LMArena 榜单的第一名（很快就会默认支持我们在播客中讨论过的 Style Control）。
我们一直在关注 Ben Hylak 关于 Apple VisionOS 的相关工作，并邀请他到世界博览会演讲。他后来发布了 Dawn Analytics，并持续针对 o1 发表自己的不加修饰的想法——最初对它大加批评，后来却逐渐成为了日常用户。我们非常喜欢“改变想法的人”（mind-changers）在这两个含义上的诠释，也认为这种讨论正发生在世界各地：当人们艰难地从对话式的模型转变到全新的推理模式，以及像 Devin 这样的每月几百美元级的专业级 AI 产品（他也在 WF 发表了演讲，现已全面上线）时，这些话题都是绕不开的。以下是我们的一些思考。
公共服务公告：由于需求量巨大（申请人数是名额的 15 倍以上），我们将于明天截止 AI Engineer Summit 的演讲提案征集（CFP）。这是最后的召集！感谢大家，我们会尽快联系所有人！
o1 不是一个聊天模型（这正是它的意义）
我为什么会从厌恶 o1，到现在每天用它来解决最重要的问题？
因为我学会了如何正确使用它。
https://x.com/sama/status/1877814065088663763
当 o1 pro 发布 时，我毫不犹豫地就订阅了。要想证明它每月 200 美元的费用是合理的，它只需要给我省下 1-2 个工程师小时的工作量（我们在 dawn 雇的人越少越好！）
但在真正尝试了一整天，想要让这个模型产出好结果之后——我的结论是：它太垃圾了。
每次我提问，都要等上 5 分钟，结果只得到一大堆相互矛盾的“乱七八糟”内容，还附带一些我并没想要的架构图加上优缺点列表。
我在推特上说了我的看法，很多人跟我观点一致，但更让我惊讶的是，也有人和我完全相反——他们对 o1 的表现非常震惊，觉得好得离谱。
当然，每次 OpenAI 有新东西发布时，人们往往会极度吹捧（这几乎是引发病毒式传播的第二有效方式，仅次于唱反调）。
但这次感觉不太一样——提出截然相反观点的人大多是位于实战前线的开发者。
我跟这些意见不同的人聊得越多，就越发意识到是我用错了方法：
我把 o1 当成了一个聊天模型——但它根本就不是一个聊天模型。
如何正确“愤怒地”使用 o1
如果 o1 不是一个聊天模型——那它到底是什么？
我更倾向于把它当作一个“报告生成器”。只要你提供足够多的上下文，并告诉它你希望生成什么样的输出，它通常能一次性就给出非常好的答案。
swyx 的注：“OpenAI 确实发布过一些关于如何给 o1 提示的信息，但我觉得还不够全面。从某种角度看，你可以把这篇文章当作一份基于实际使用经验、关于如何真正利用 o1 和 o1 pro 的‘缺失手册’。”
1. 不要只是写提示，而要写完整的“简报” (Brief)
要提供大量上下文。无论你觉得“多”是多少，请在此基础上再乘以 10 倍。
o1 提示的结构
目标（Goal）
我想要一份在旧金山两小时车程内的最佳中等长度徒步路线清单。
每条路线都应该提供一次很酷而独特的冒险，并且相对不那么大众化。
对每条徒步路线，需要返回：
在 AllTrails 上查找时的路线名称
徒步起点的地址
徒步终点的地址
距离
开车时间
徒步时长
这条路线有什么特别之处，能带来一次酷且独特的体验
请只返回排名前 3 的路线。
务必确保路线名称正确存在，并且时间信息准确。警示（Warnings）
小心核实路线名称是否正确存在，以及时间是否准确。上下文（Context Dump）
我的女朋友和我非常爱徒步！我们几乎把旧金山本地所有的徒步路线都走遍了，无论是 Presidio 还是金门公园。我们现在想离开市区活动一下 —— 最近我们刚去过 Mt. Tam（从楼梯起点一路走到 Stinson），那次真的很长。这周末我们想找些不一样的路线！能看到海景还是不错的。我们也很喜欢美味的食物。我喜欢 Mt. Tam 徒步的一个原因是它在旅程结束后会有种庆祝的感觉（进城后吃早餐！）。Discovery Point 附近那片导弹发射井遗址也很酷，但我已经走过那条路线大概 20 多次了。接下来几周我们见不到面（她因为工作要留在洛杉矶），所以这次路线的独特性对我们来说很重要。
在使用类似 Claude 3.5 Sonnet 或 4o 等聊天模型时，你往往只需先简单抛出一个问题和部分上下文。如果模型需要更多信息，它通常会向你提问（或者从输出中就能看出缺失的信息）。
你会在与模型的来回对话中一步步纠正它、补充需求，直到最终得到想要的答案。这有点像捏陶器皿。聊天模型本质上是通过对话从你这里“拉取”上下文。随着时间的推移，我们的问题也就越来越简短和随意——但还能维持一个不错的输出。
o1 则不然——它会直接把你随意的简短问题当真，而且并不会主动去帮你“挖掘”更多上下文。你需要主动“推送”大量的上下文给 o1。
即便只是问一个简单的工程问题，也要：
说明你曾尝试过什么方法以及为何没成功
把所有数据库模式（schema）都贴出来
解释你们公司是干什么的，公司规模有多大（以及所有专有名词的含义）
总之，要把 o1 当作一个刚入职的新员工来对待。要注意的是，o1 的失误有时体现在它不知道自己需要“思考多少”。 有时即便任务很简单，它也会意外地开启大段推理，陷入不必要的细节中。需要注意的是：o1 的 API 确实允许你设定低/中/高的推理努力度（reasoning_effort），但在 ChatGPT 界面里并没有暴露这个功能。
给 o1 提供上下文的小技巧：
我建议使用 Mac/手机自带的语音备忘录，把你要做的事情口述 1-2 分钟，然后把转录文本贴进来。
我实际有一个笔记文档，专门存放一些长段文本，方便快速复用。
swyx：我用的是 Careless Whisper（出自 LS Discord 的 Sarav）
各种内置 AI 助手可以让你更方便地提取信息。比如，如果你用 Supabase，可以让 Supabase Assistant 转储/描述所有相关的表和 RPC 等。
swyx： 我也会把开头改成“在提示上多花 10 倍精力”
今天我有了一个新的见解：如果你期望输出质量提高 100 倍，那么就需要在提示词上多投入 100 倍的时间。
大语言模型（o1）能完成许多任务，但它仍然无法读懂你的想法。
随着推理计算时间的提升（如规划和推理能力），精心设计提示词和提供上下文的回报也会成倍放大，甚至达到 100 倍。
因此，我现在以完全不同的方式使用 o1，不是从一场对话开始，而是直接告诉它我的整个情况，并说明我对哪些地方不满意。这种用法更像是在将 o1 作为顾问，而非简单的聊天机器人。这意味着，你需要花时间提供足够的上下文、明确目标、设定约束，而不是单纯享受一场轻松的对话。
额外提示：永远要求提供替代方案。既然它本身会搜索各种选项，不妨让它详细列出每种可能性，这样你可以更好地做出最终决策。
2. 专注于目标：明确告诉它“想要什么”，而非“怎么做”
当你给模型提供了海量上下文后，最重要的是在开头就说明你期望输出的“成果”是什么。
在大多数其他模型中，我们通常会告诉模型“你是某个领域的专家。请慢慢思考并仔细推理”，即告诉它“怎么做”。
而我在使用 o1 时的成功经验恰恰相反：我并不会告诉它具体的“做法”，我只强调“我需要的最终目标是什么”。然后让 o1 自己去规划和执行所需步骤。这就是它支持“自动推理”的意义所在，而且往往比你在“人类反馈回路”里手动干涉更快。
swyx 糟糕的插画尝试
swyx 的高级技巧：为你认为的“好”或“坏”输出制定非常清晰的判断标准，让模型可以用这种标准自评自身输出，并进行自我改进/修复。本质上，你是在把 LLM 作为评审 的逻辑放入提示之中，让 o1 在需要时自动调用。
额外好处是，等到你以后可以做 Reinforcement Finetuning（官方发布后），就可以直接用这些“LLM 作为评审”评估指标了。
以上做法要求你非常明确地知道自己想要什么（此外，最好一次只问一个具体问题——毕竟 o1 只能在最开始时进行推理）。
听起来简单，其实并不容易！例如，我要 o1 真正在生产环境实现某个特定架构？还是要它写一个最小可行测试 App？或者只是想让它对不同方案的优缺点做下评估？这些其实是完全不同的需求。
o1 通常默认会以“报告式”的写法输出结果，带着分级标题、小标题等。如果你不想要这种解释式的东西，而希望得到完整的文件内容——那就一定要在提示里明确说清楚。
自从学会了以上使用 o1 的方法后，我对它能一次性给出正确答案的能力真是非常惊讶。它几乎在各方面都更胜一筹（除了费用和延迟）。以下是我在使用中感觉特别惊艳的一些时刻：
3. 要清楚 o1 擅长什么、不擅长什么
o1 擅长的：
完美地一次生成整个文件或多份文件：这是 o1 最令人惊叹的能力。给它贴大量代码、贴上关于你在做什么的背景信息，它往往能一次性把整个文件（甚至多个文件）都搞定，基本不出错，而且还会遵循你已有的代码风格。
更少的“胡编乱造”（Hallucination）：总体而言，o1 更不容易搞混。如果你让它写一些 ClickHouse、New Relic 这种比较特殊的查询语言，Claude 往往就会把这些和 Postgres 混在一起，o1 则在这方面好多了。
医学诊断：我女朋友是皮肤科医生，几乎我所有的亲友如果有皮肤问题都会发图片给她。我出于好奇，也会同时问 o1。o1 大概有 3/5 的概率能给出非常接近的正确诊断，更厉害的是——它几乎每次都能给出一份非常准确的鉴别诊断清单（differential diagnosis），对专业医生来说很有用。
解释概念：在解释一些非常困难的工程概念上，o1 也相当擅长，并且会提供例子。简直像是生成了一篇完整的文章。
我在做艰难的架构决策时，会让 o1 生成多个可行方案，并给出优缺点甚至做互相比较。然后我把这些回复复制下来做成 PDF，就像在对比多份提案一样。Bonus：Evals（评估）。我之前对用 LLM 做评审一直很怀疑，因为一般让模型评价自己时会面临相同的失误模式。但在 o1 这里，它往往只要非常少的上下文就能判断一个结果是否正确，表现相当不错。
o1 不擅长的（目前）：
以特定风格或语气来写作：不，我没有用 o1 来写这篇文章 :)
我发现它在写东西时（尤其是特定风格/语调）不太行，表现相当学术或正式，像官方报告一样。大概是因为有太多推理时长的 Token 偏向了这个方向，很难让它转变风格。
这里有个示例：我想让它帮忙写这篇文章，经过多次迭代后，依然只有干巴巴的“学校报告”风格：
从零构建完整应用：o1 在一次性生成完整文件方面的能力非常强大。但即使你在推特上看到一些十分“乐观”的演示，o1 仍不足以直接给你创建一个完整的 SaaS，至少需要很多的迭代。
不过，o1 确实可以几乎一次性完成一个前端功能，或比较简单的后端功能，这点表现非常出色。
题外话：为“报告生成器”设计界面
延迟会从根本上改变产品体验。
swyx：我们非常同意——AI 推理的六种不同延迟等级 在现在非常普遍。
[推理：快与慢](https://www.latent.space/p/inference-fast-and-slow)
2024 年 11 月 4 日
想想邮件、电子邮件、即时通讯的差别——最核心的区别就是“延迟”。语音留言和电话的区别——依旧是延迟。视频和视频会议的区别——还是延迟。等等。
我之所以把 o1 称为“报告生成器”，是因为它明显和对话式模型不一样——更像是电子邮件往来。
而这种产品逻辑在 o1 的界面上其实还没真正体现出来。我很希望界面在设计上能更坦诚地承认这一点。
如果你在用 o1 开发产品，以下是我对AI UX的一些建议：
让用户更容易看到回复的层级结构（比如一个小型目录）
同样地，让层次化的内容可以被更方便地展开或折叠。现在每次回复都比窗口高很多行，我希望能像 Perplexity 一样，把每个问答都作为一个独立的页面段落，而不是简单的无限下拉。对于答案本身，可以做粘性标题、可折叠标题等。
让用户更方便地管理和查看自己提供给模型的上下文。在这方面，Claude 的界面做得其实更好——当你粘贴一大段文本时，会显示成一个小附件形式。ChatGPT 的“项目”功能在 o1 上表现并不好，我还是经常要复制粘贴大量内容。
顺便说一下：
ChatGPT 用 o1 时真是超级不稳定。它产生的推理描述往往滑稽可笑，经常会生成失败，也经常在移动端无法使用。
在肯尼亚度过的一个美好日子？？
接下来呢？
我对这些模型的实际应用方向充满好奇。
我觉得 o1 会首次让某些产品成为可能——特别是那些可以利用高延迟、长时间后台推理的场景。
用户愿意为哪些任务等待 5 分钟？1 小时？1 天？甚至 3-5 个工作日？
我觉得其实可能性非常多，只要设计得当。
随着模型越来越昂贵，试错的成本上升，随便几分钟就可能烧掉几千美元。
o1-preview 和 o1-mini 支持流式输出，但它们不支持结构化生成或 system prompts。o1 支持结构化生成和 system prompts，但暂不支持流式输出。
考虑到它的回复往往需要等待较长时间，流式输出几乎可以算是必需品。
随着 2025 年的到来，开发者会开始真正动手使用这些模型，我很期待看到他们会做出什么。
（完）