如何正确使用o1 - 给其足够的上下文，而不是足够的对话

发表于 2025-01-21 分类于 AI

本文改编自Ben Hylak的英文原文 - o1 isn’t a chat model (and that’s the point)，之所以要改编主要是原文的写作风格比较跳跃，感觉读起来不太友好。重新改编过的这个版本更符合我喜欢的阅读风格了。

文章揭示了一个容易被忽视但很重要的观点：不是所有的AI都应该用对话的方式来使用。如果你正在使用或计划使用新一代的AI模型（例如o1），这篇文章值得一读。不是因为它告诉你某段具体而神奇的提示词，而是因为它可能改变你对o1这种全新模型的本质理解。这种理解上的转变，比任何具体的使用技巧都重要。

如何正确使用o1 - 给其足够的上下文，而不是足够的对话？

最近我发现了一个有趣的现象：人们在使用o1时犯的最大错误，就是把它当作对话型AI。

就像早期的网页设计 - 当时的设计师们试图让网站看起来像纸质杂志，执着于固定的版面和精确的排版。但后来我们发现网页有着完全不同的交互逻辑和可能性。

我们现在对o1的态度也差不多。

当o1 pro发布时，我立即支付了每月200美元的订阅费。这个决定很简单：如果它能替代工程师一两个小时的工作，这笔钱就值了。但第一天的体验很糟糕。等待5分钟就为了收到一堆冗长的、自相矛盾的内容，这感觉像是在浪费时间。

我在Twitter上抱怨了这一点。有趣的是，一些我很尊重的工程师却持相反意见。他们说o1改变了他们的工作方式。这让我意识到可能是我用错了方法。

经过几周的实验，我明白了问题所在：我们习惯了与AI对话，但o1不是用来对话的。

把o1想象成一个报告生成器可能更准确。这就像你在大公司里要求一个专业团队给出分析报告。你不会期望他们立即回应，但你知道如果给他们足够的信息和时间，他们会给出深思熟虑的答案。

这种转变很重要。因为一旦你把o1当作报告生成器，你就会完全改变使用方式。你不会期待快速的来回对话，而是会在开始就提供尽可能多的上下文。

简单来说：不要写提示词（prompts），要写简报（briefs）。

我发现提供上下文的最好方法是使用语音备忘录。我会用1-2分钟完整描述问题，然后把转录文本粘贴进去。这种方式自然而全面，比打字更容易表达完整的思路。

一旦你向模型提供了尽可能多的上下文 - 专注于解释你想要什么样的输出。

大多数工程师会这样开始他们的提示：”你是一个专业的软件工程师，请仔细思考…” 但这种方法在o1上行不通，下图展示的模型本身的差异性决定了这一点。

关键在于投入 - 如果你期望获得百倍的输出质量，就得在提示词上投入百倍的精力。o1能力很强，但它仍然无法读心。

一个实用的方法是：把o1当作一个需要完整背景信息的新团队成员。不要期待它能通过简短的对话理解你的意图。相反，一次性提供所有必要信息：

认识到上面这两点后，我的工作流程完全改变了。现在当我需要o1来解决一个复杂问题时，我会：

结果令人惊讶。o1开始产出的内容质量大幅提升，有时甚至超出预期。它能一次性生成完整的、可用的代码文件，这在我使用其他AI模型时从未见过。

在某些领域，o1表现出色：

但o1也有明显的局限：

这种认知转变也带来了对AI产品设计的思考。目前大多数AI界面都是基于聊天模型设计的，这可能不是最好的方式。

想想电子邮件和即时通讯的区别。它们的本质区别是延迟。电子邮件允许更深入的思考和更完整的表达，而即时通讯追求的是快速反应。

o1的界面应该更像一个文档编辑器，而不是聊天窗口。它应该有更好的结构化显示，更容易管理长文本，更容易组织和查看提供的上下文。

现有的AI界面设计仍然停留在聊天模型的思维。类似早期的Web应用照搬桌面软件的交互方式一样，这种设计限制了o1的潜力。

一个更好的界面应该：

考虑用户愿意等待的时间。5分钟？一小时？一天？如果最终能得到深度的分析和可靠的结果，很多任务都值得等待。

2025年，我预计会看到一波基于”深度思考型AI”的创新浪潮。关键是要突破对即时性的执着，转而关注如何最大化这些工具的深度能力。

这不仅是一种使用方式的改变，而是一种新的软件设计哲学的开端。