o1不是聊天模型!前SpaceX工程师:这样用o1才能解决复杂问题

荒野冷风

---

  新智元报道


编辑：英智【新智元导读】Ben Hylak从最初对o1不满到逐渐掌握使用技巧，成功将其转化为解决重要问题的得力工具。本文探讨了如何正确使用o1，解锁其强大的报告生成和推理分析能力。

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

我学会了如何正确使用它。」

Ben Hylak曾是SpaceX软件工程师、苹果VisionOS人机交互设计师，后来离职创立了Dawn Analytics。

起初，Ben Hylak对o1满是质疑，如今却成为了o1的活跃用户。



o1不是一个聊天模型，这正是关键所在。

o1 pro刚宣布推出，Ben就果断订阅了。毕竟，只要它每月能顶替1-2个工程师的工作量，这每月200美元的订阅费就花得值。

然而，经过一整天认真的试用，Ben得出结论：这模型简直太糟糕了。

每次提出问题，Ben都得等上5分钟，结果等来的却是一堆前后矛盾的废话，还莫名其妙地附上架构图和优劣势分析列表。

Ben把吐槽放到了网上，不少人表示赞同，但也有一些人强烈反对。这些观点来自行业一线的专业人士，有人对o1 pro的表现大为惊叹。

Ben渐渐意识到自己完全弄错了，他一直把o1当成聊天模型来用，可o1压根就不是聊天模型。



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

它更像是一个「报告生成器」。

只要你能提供充足的上下文信息，并且清晰地阐明所需的输出内容，它通常能完美解决问题。



提供充足的背景信息

提供海量的上下文信息。无论你认为「海量」是多少，在此基础上乘以10倍。

当使用诸如Claude 3.5 Sonnet或4o这类聊天模型时，一般是从一个简单问题和一些上下文信息入手。如果模型还需要更多上下文，它往往会向你提问。

聊天模型正是通过互动的方式从你那里获取更多上下文。



o1只会按照你问题的字面意思作答，不会主动从你这里获取上下文信息。

所以，你得尽可能多地向o1提供上下文。

哪怕只是问一个简单的工程问题，也请做好以下这些：

详细说明你已经试过的所有方法，以及这些方法为何行不通。提供所有数据库架构的完整导出文件。阐述公司的业务内容、规模大小，同时对特有的术语进行定义。

简单来讲，就把o1当成新入职的员工来对待。

为o1提供上下文的简单技巧：用Mac或手机上的语音备忘录，直接通过语音对整个问题场景进行描述，时长在1-2分钟，把转录的文本粘贴进去。聚焦「要什么」而非「怎么做」给o1提供尽可能多的背景信息后，关键是讲清楚你期望的最终输出成果。我们习惯告诉模型怎么回答，如请以资深软件工程师的身份，仔细思考后作答。但o1的使用方法不一样。别告诉o1该怎么做，只说要什么，然后让o1自己来，它会规划并解决后续步骤。这能充分发挥o1的自主推理能力，实际运行效率或许比手动审核、对话沟通的方式更高。

你必须清楚具体需求，比如，是想让o1实现某个特定架构，还是创建一个最小化的测试应用。o1第一次就能生成正确答案的能力着实令人惊叹。除了成本和延迟，o1在几乎所有其他方面都更为出色。o1的优势与不足o1的优势一次性生成单个或多个文件：只需粘贴大量代码以及与正在构建内容相关的上下文信息，它就能一次性完成整个文件（甚至多个文件）的生成。生成的内容几乎没有错误，并且会严格遵循代码库中已有的模式。较少出现幻觉：总体而言，o1在理解问题时似乎很少产生混淆。医学诊断：对于医学专业人士而言，o1通常能给出与正确答案极为接近的诊断。解释概念：o1在阐释极为复杂的工程概念方面表现卓越。评估：o1展现出了作为评估工具的潜力，它经常能在上下文信息有限的情况下，判断生成结果是否正确。o1尚未实现特定语气/风格的写作：o1在写作方面的表现欠佳，特别是在模仿特定语气或风格时。它自带一种浓厚的学术/公司报告风格，而且始终如此。这可能是因为大量的推理token将语气导向了这个方向。构建完整的应用：o1一次性生成单个或多个文件的能力很强，但它无法直接构建完整的SaaS应用，至少需要大量反复调整。不过，它基本上能一次性生成完整的前端功能模块，或简单的后端功能模块。

网友评论：o1/pro是我用过的第一个可以很好地完成高级软件架构的模型！参考资料：https://www.latent.space/p/o1-skill-issuehttps://x.com/daniel_mac8/status/1878423666309902404