o1 不是聊天模型，教你如何正确的激发o1能力

如何正确使用 o1：不要写提示词；要写简报，专注于目标：描述你想要什么，而不是你想要如何得到它，并且要了解 o1 的优点和缺点！

自从 o1 在 10 月份发布以及 o1 pro/o3 在 12 月份宣布以来，许多人一直在努力理解他们的看法，包括正面和负面的。我们在 o1 Pro 情绪低谷时采取了强烈的积极立场，并规划了 OpenAI 要推出每月 2000 美元的代理产品可能需要什么（传闻将在未来几周内推出）。从那时起，o1 在所有 LMArena 排行榜上一直稳居第一。

此后，他推出了 Dawn Analytics，并继续发布关于 o1 的未经过滤的想法——最初是一个大声的怀疑者，并慢慢成为日常用户。我们喜欢改变想法的人的各种含义，并且认为当人们努力从聊天模式过渡到推理和每月数百美元的专业 AI 产品，现已 GA））的新世界时，世界各地都在发生同样的对话。以下是我们的想法。

我是如何从讨厌 o1 到每天用它来解决我最重要的问题的？

我学会了如何使用它。

当 o1 pro 发布时，我毫不犹豫地订阅了。为了证明每月 200 美元的价格是合理的，它只需要每月提供 1-2 个工程师的工作时间

但在尝试让模型工作的一天结束后，我的结论是它就是垃圾。

每次我问一个问题，我必须等待 5 分钟，然后迎接我的却是大量自相矛盾的胡言乱语，还附带了未经请求的架构图 + 优缺点列表。

o1 回答我的问题，多次自相矛盾。

当然，人们在发布后经常对 OpenAI 非常狂热（这是走红的第二好策略，仅次于负面评价。）

但这感觉不同——这些看法来自身处困境的人们。

当我开始与那些不同意我的人交谈时，我越发意识到我完全错了：

我像使用聊天模型一样使用 o1——但 o1 不是聊天模型。

如何正确使用 o1

如果 o1 不是聊天模型，那它是什么？

我认为它像一个“报告生成器”。如果你给它足够的上下文，并告诉它你想要输出什么，它通常会一次性解决问题。

swyx 的说明：OpenAI 确实发布了关于提示 o1 的建议，但我们认为它不完整，而且在某种意义上，你可以将这篇文章视为在实践中使用 o1 和 o1 pro 的实际经验的“缺失手册”。

1. 不要写提示词；要写简报

提供大量的上下文。无论你认为我说的“大量”是什么意思——都要乘以 10。

当你使用像 Claude 3.5 Sonnet 或 4o 这样的聊天模型时，你通常从一个简单的问题和一些上下文开始。如果模型需要更多上下文，它通常会向你索取（或者从输出中可以明显看出）。

你与模型来回迭代，纠正它 + 扩展需求，直到获得所需的输出。这几乎就像陶器。聊天模型本质上通过这种来回的方式从你那里提取上下文。随着时间的推移，我们的问题变得更快 + 更懒——在仍然获得良好输出的同时，尽可能地懒惰。

o1 只会按字面意思接受懒惰的问题，并且不会尝试从你那里提取上下文。相反，你需要尽可能多地将上下文推送到 o1。

即使你只是问一个简单的工程问题：

• 解释你尝试过但没有奏效的所有方法
• 添加所有数据库架构的完整转储
• 解释你的公司是做什么的，规模有多大（并定义公司特定的术语）

简而言之，将 o1 视为新员工。请注意，*o1 的错误包括推理它应该推理多少。*有时，方差未能准确地映射到任务难度。例如，如果任务真的非常简单，它通常会毫无理由地陷入推理的兔子洞。注意：o1 API 允许你指定低/中/高 reasoning_effort，但 ChatGPT 用户无法使用。

让 o1 更容易获得上下文的提示

1. 我建议使用你的 mac/手机上的 Voice Memos app。我只需描述 1-2 分钟的整个问题空间，然后粘贴该文本。
   • 我实际上有一个笔记，我在其中保存了要重复使用的长段上下文。
   • swyx：我使用 LS Discord 中的 Sarav 的 Careless Whisper
2. 产品内部弹出的 AI 助手通常可以使这种提取更容易。例如，如果你使用 Supabase，请尝试要求 Supabase Assistant 转储/描述所有相关的表/RPC 等。

swyx：我将开头改为“在提示上多花费 10 倍的时间”

2. 专注于目标：描述你想要什么，而不是你想要如何得到它

一旦你尽可能多地用上下文填充模型——专注于解释你希望输出是什么。

对于大多数模型，我们已经习惯于告诉模型我们希望它如何回答我们。例如，“你是一位专业的软件工程师。慢慢地、仔细地思考”

这与我发现 o1 成功的相反。我不指导它如何做——只指导它什么。然后让 o1 接管并计划和解决自己的步骤。这就是自主推理的目的，实际上可能比你手动审查和聊天作为“人工在环”要快得多。

swyx 的糟糕插图尝试

这要求你真正确切地知道你想要什么（并且你真的应该在每个提示中要求一个特定的输出——它只能在开始时进行推理！）

听起来比实际更容易！我是希望 o1 在生产中实现一个特定的架构，创建一个最小的测试应用程序，还是只是探索选项并列出优缺点？这些都是完全不同的要求。

o1 通常默认使用报告式的语法来解释概念——完全带有编号的标题和副标题。如果你想跳过解释并输出完整的文件——你只需要明确说明即可。

• swyx 的专业提示：为“好”与“坏”建立真正好的标准有助于你让模型有一种评估自身输出并自我改进/修复自身错误的方法。

作为额外的好处，这最终会给你提供 LLM 作为评估者的工具，你可以在 GA 时将其用于强化微调。

自从学会如何使用 o1 以来，我对其第一次就生成正确答案的能力感到非常震惊。它实际上几乎在各个方面都更好（除了成本/延迟）。

以下是一些特别突出的时刻：

3. 了解 o1 的优点和缺点

o1 的优点：

• 完美地一次性生成整个/多个文件：到目前为止，这是 o1 最令人印象深刻的能力。我复制/粘贴了大量的代码，以及关于我正在构建的内容的大量上下文，它会完全一次性生成整个文件（或多个文件！），通常没有错误，并遵循我代码库中的现有模式。
• 更少产生幻觉：总的来说，它似乎更少混淆事情。例如，o1 确实擅长定制查询语言（如 ClickHouse 和 New Relic），而 Claude 经常混淆 Postgres 的语法。
• **医疗诊断：**我的女朋友是一位皮肤科医生——所以每当任何朋友或我大家庭中的任何成员有任何皮肤问题时，他们都会给她发一张照片！为了好玩，我开始同时询问 o1。它通常非常接近正确的答案——大约 3/5 的时间。对于医学专业人士更有用——它几乎总是提供极其准确的鉴别诊断。
• **解释概念：**我发现它非常擅长用示例解释非常困难的工程概念。这几乎就像生成一整篇文章。当我在处理困难的架构决策时，我经常会让 o1 生成多个计划，每个计划都有优点/缺点，甚至比较这些计划。我会将响应复制/粘贴为 PDF，并对其进行比较——几乎就像我在考虑提案一样。
• **奖励：评估。**我一直对使用 LLM 作为评估的评委持怀疑态度，因为从根本上说，评委模型通常会遇到与最初生成输出的模型相同的失败模式。然而，o1 显示出了巨大的希望——它通常能够在很少的上下文下判断生成是否正确。

o1 的缺点（目前）：

• **以特定的声音/风格写作：**不，我没有使用 o1 来写这篇文章 🙂
  我发现它非常不擅长写任何东西，尤其是在特定的声音或风格方面。它有一种非常学术/公司报告的风格，它想要遵循。我认为只是有很多推理 Token 将语调偏向那个方向，很难摆脱它。
  这是一个我试图让它写这篇文章的例子——这是经过多次来回之后——它只是想制作一份平淡的学校报告。

构建整个应用程序：o1 非常擅长一次性生成整个文件。尽管如此，尽管你可能会在推特上看到一些更……乐观的……演示——o1 不会为你构建整个 SaaS，至少不会经过大量的迭代。但是它可以** 几乎一次性生成整个功能，尤其是前端或简单的后端功能。