o1不是聊天模型？24小时热度暴涨，奥特曼、Brockman在线围观

机器之心报道

机器之心编辑部

不要再将 o1 当做聊天模型了。

如何定位 o1 模型？你是否常常将其当做一个聊天模型来使用。

在刚刚过去的一天，一篇名为《o1 isn’t a chat model（and that’s the point）》的文章引发了包括 OpenAI CEO Sam Altman、总裁 Greg Brockman 的关注。

这篇文章表示 o1 不是一个聊天模型，我们可以将它想象成一个报告生成器。

原文链接：https://www.latent.space/p/o1-skill-issue

2024 年，OpenAI 接连放出了 o1、o1 pro、o3 模型，随着模型推理能力的提升，随着而来的是高昂的订阅费。但很多人在订阅使用后发现 o1 的表现并不如宣传的那样好，当然也包括本文的作者——曾任SpaceX软件工程师、苹果VisionOS人机交互设计师的Ben Hylak。

Hylak 表示每次他问 o1 一个问题时，都要等上 5 分钟的时间，结果看到的只是一大堆自相矛盾的胡言乱语，还有未经请求的架构图 + 优缺点列表。这让 Hylak 很是恼火，因此直言 o1 就是垃圾。

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

为了表达心中的愤怒，Hylak 还在社交媒体上分享了这种观点，「我今天一整天都在使用 o1 pro—— 我再怎么强调也不为过 —— 它真的很糟糕。」

「输出内容几乎接近胡言乱语，在同一个答案中多次自相矛盾。例如：我向它征求关于重构的建议。它建议合并文件，但输出的代码块中文件并未合并，然后又出现了完全不相关的结论。」

图源：https://x.com/benhylak/status/1864835651725910023

对于 Hylak 的观点，有人表示赞同，但也有人强烈反对，他们认为 o1 表现非常好。

随着 Hylak 与那些持反对意见的人交流越来越多，他逐渐意识到自己完全错了：他把 o1 当作聊天模型来使用，但实际上 o1 并不是聊天模型。

对于作者态度的转变，奥特曼很是欣慰，表示道：「随着人们学会如何使用 o1（包括 pro 版），观察人们对它态度的转变真是很有趣。」

奥特曼关于这条博客的推文浏览量达到 1.5M 。

Greg Brockman 表示：「o1 是一个不同类型的模型。要获得出色的性能，需要以一种与标准聊天模型不同的新方式来使用它。」

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

我们可以把它想象成一个报告生成器（report generator）。如果你给定足够的上下文，然后告诉它你想要的输出，o1 通常会一下子确定解决方案。

接下来的问题是，如何使用 o1。

不要写提示，要写 Brief

给它大量的上下文，上下文的数量作者用 ton 来形容，我们可以把它想象成提示的 10 倍。

这张图解释了如何构建一个针对 o1 模型的提示（prompt），并将其分为几个部分。

通常情况下，当你使用像 Claude 3.5 Sonnet 或 4o 这样的聊天模型时，会先提出一个简单的问题并附带一些上下文。如果模型需要更多的上下文，它通常会向你询问。

你会与模型来回迭代，纠正它并扩展需求，直到达到期望的输出。聊天模型本质上是通过这种来回交互的方式从你这里获取上下文。在与模型交互过程中，我们可能会变得越来越懒，只要还能得到好的输出，输入的提示越来越敷衍。

但是，o1 会直接接受那些敷衍的问题，并不会试图从我们这里获取上下文。相反，你需要尽可能多地向 o1 提供上下文。

即使你只是询问一个简单的工程问题，你也需要：

• 详细说明所有你尝试过但没有奏效的方法；
• 添加所有数据库架构的完整 dump；
• 解释你公司的业务、规模（并定义公司特有的术语）。

简而言之，我们要把 o1 当作一个新入职的员工来对待。

把更多的时间用在开头提示上。图源：https://x.com/swyx/status/1839213190816870425

专注于目标：准确地描述你想要什么

一旦你向模型提供了尽可能多的上下文，就需要专注于解释你希望输出是什么。

在大多数模型中，我们会告诉模型我们希望它如何回答我们。例如：你是一位专家级软件工程师。你需要模型进行慢思考且思考的很仔细。

这与使用 o1 取得成功的方法完全相反。不要告诉它如何做 —— 只告诉它做什么。然后让 o1 接管，自行规划和解决问题的步骤。这就是自主推理的作用所在，实际上这比你作为人工环节手动审查和聊天要快得多。

知道 o1 擅长什么、不擅长什么

o1 擅长什么：

• 完美地一次性处理整个 / 多个文件：到目前为止，这是 o1 最令人印象深刻的能力。例如，复制 / 粘贴大量代码，大量关于正在构建内容的上下文，o1 会完全一次性地完成整个文件（或多个文件），通常没有错误，遵循现有模式代码库。
• 减少幻觉：例如，o1 确实擅长定制查询语言（如 ClickHouse 和 New Relic），而 Claude 经常混淆 Postgres 的语法。
• 医疗诊断：Hylak 的女朋友是一名皮肤科医生，当朋友或家人有皮肤问题时，他们通常会给 Hylak 的女朋友发一张照片。当 Hylak 拿照片询问 o1 时，o1 的回答通常与正确答案惊人地接近（约 60%）。对于医疗专业人员来说更有用 ——o1 几乎总能提供极其准确的鉴别诊断。
• 解释概念：Hylak 发现 o1 非常擅长通过示例解释非常困难的工程概念。
• 在制定困难的架构决策时，Hylak 经常会让 o1 生成多个计划，甚至比较这些计划，每个计划都有优缺点。
• 评估：Hylak 一直对使用 LLM 作为评估的判别器持非常怀疑的态度，但 o1 表现出巨大的希望 —— 它通常能够在很少的上下文下确定生成结果是否正确。

o1 做得还不够好的地方：

• 用特定的声音 / 风格写作：Hylak 发现 o1 不擅长写任何东西，尤其是在特定的声音或风格中。它遵循一种非常学术 / 企业的报告风格。

Hylak 尝试让 o1 写这篇博客的一个例子 — — 经过多次反复，它只会写一份平淡的报告。

• 构建整个应用程序：o1 非常擅长一次性构建整个文件，但 o1 不会构建整个 SaaS，至少不会进行大量迭代。不过，它几乎可以一次性完成整个功能，特别是前端功能或简单的后端功能。

延迟从根本上改变了我们对产品的体验。考虑一下电子邮件和短信之间的区别 —— 主要是延迟，语音消息与电话通话 —— 延迟，等等。

Hylak 将 o1 称为「报告生成器」，因为 o1 显然不是聊天模型 —— 它感觉更像电子邮件。

Hylak 认为 o1 将首次使某些产品成为可能 —— 例如，可以从高延迟、长时间运行的后台智能中受益的产品。

用户愿意等待 5 分钟来完成什么样的任务？一个小时？一天？3-5 个工作日？如果设计正确的话，有很多。

需要注意的是，o1-preview 和 o1-mini 支持流式传输，但不支持结构化生成或系统提示。o1 支持结构化生成和系统提示，但尚不支持流式传输。

当开发人员在 2025 年设计产品时，实际使用该模型做什么将会非常重要。