Opus 4.6 還是 Sonnet 4.6？我的選擇邏輯不是看跑分

我每天都在 Opus 和 Sonnet 之間切換。不是因為哪個「比較好」，是因為它們適合不同的事。

這篇的核心觀點

• 模型選擇不是「誰比較聰明」，是「這件事需要什麼」
• Sonnet 處理 80% 的日常任務綽綽有餘
• Opus 的價值在「多步驟推理」和「複雜架構決策」
• 先用 Sonnet，卡住了再切 Opus，是最實際的策略

我的試錯過程

一開始我什麼都用 Opus。畢竟它是最強的模型，用最強的肯定沒錯吧？

然後我發現兩件事：

第一，Opus 吃 token 的速度是 Sonnet 的好幾倍。同樣的任務，Opus 的成本明顯更高。如果是簡單的文件編輯或日常寫程式，這個差距就是浪費。

第二，對於明確的任務，Sonnet 的結果跟 Opus 幾乎看不出差別。「幫我加一個輸入驗證」、「重構這個函數」、「寫一封 email」——這些 Sonnet 都做得很好。

我現在的切換邏輯

用 Sonnet 的時候：

• 日常寫程式（單一檔案修改、加功能、修 bug）
• 文字工作（寫文章、編輯、翻譯）
• 快速問答
• 任何「照指令執行」的任務

切換到 Opus 的時候：

• 多檔案重構（需要理解整個 codebase 的關聯）
• 架構決策（「我應該用 X 還是 Y」的深度分析）
• Agent Teams 多代理任務
• 寫到一半發現 Sonnet 的結果不夠好，需要更深的推理

一個判斷標準

問自己：這個任務需要 Claude 「想」許多步，還是「照做」就好？

如果是「照做」——Sonnet。如果是「想」——Opus。

大多數日常工作是「照做」。這就是為什麼 Sonnet 處理 80% 的任務。

Sonnet 4.6 真正的優勢

Sonnet 4.6 不只是「便宜版 Opus」。它有自己的優勢：

💡 頁序搜尋能力比前代強了不少，用更少的 token 就能找到需要的資訊。

💡 搭配 web search 或 web fetch 使用時，code execution 是免費的。

💡 支援 1M token 上下文窗口（beta），對於需要處理大量資料的任務很實用。

結論

別只看跑分選模型。看你手上的任務需要什麼，然後選對的工具。