「我是如何从讨厌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是我用过的第一个可以很好地完成高级软件架构的模型！
