「我是如何從討厭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是我用過的第一個可以很好地完成高級軟件架構的模型！