如何使用 Opus 5.5 與 Sonnet 5.5 ☕ Buy me a coffee

🧑‍🏫 Opus 5.5 和 Sonnet 5.5 推出後，講者發現自己有三個舊習慣，讓新模型沒辦法完全發揮。這支影片教你改掉這三個習慣，也說明兩個模型怎麼分工搭配。習慣改對了，同樣的工具做出來的結果會更好、更省。

• 00:02 Opus 5.5 與 Sonnet 5.5 推出後，講者發現自己有三個使用 Claude 的舊習慣在限制這些模型的發揮。
  ↳ 新模型推出後，講者發現卡住的不是模型，是自己的用法。他有三個從舊模型時代留下來的習慣，反而讓新模型綁手綁腳，沒發揮出應有的能力。
• 00:02 習慣一：新模型能承擔比以往大得多的任務，不必把指令拆得又細又死。
  ↳ 以前怕模型做不好，會把任務切得很碎，每一步都寫死（rigid prompts，就是直接規定做法的指令）。新模型扛得起整件大事，告訴它要什麼，讓它自己想辦法就好。
• 00:02 例子：應用程式的顧客被意外重複扣款。以前寫死板指令「有人點購買後，停用付款按鈕」；現在改寫目標「每筆訂單使用者只能被扣款一次」。
  ↳ 「點購買後停用按鈕」只擋住一種重複扣款的情況。改說「每筆訂單只能扣一次」，模型會自己去找各種可能出錯的地方，解法通常更完整。
• 00:02 寫出目標之後，再給 Claude Code 一條「終點線」，描述你認為「完成」應該長什麼樣子。
  ↳ 寫好目標後，再講清楚「做完應該長怎樣」，這就是 finish line（完成標準）。Claude Code 是讓 Claude 直接幫你寫程式的工具，有了標準，它才知道做到哪裡算完成。
• 00:02 習慣二：不要再加錦上添花式的護欄，例如「不要犯任何錯，並再次檢查你的工作」。
  ↳ guardrails 原意是護欄，這裡指「不要犯錯、記得再檢查」這類附加叮嚀。這種話聽起來比較保險，但沒有給模型任何新資訊，是可以省掉的多餘字。
• 00:32 這些較新的模型預設就會做到上述的事，例如再次檢查自己的工作。
  ↳ 這些事新模型本來就會做，例如自己回頭檢查成果。所以這類叮嚀等於白講，篇幅不如留給真正的目標和完成標準。
• 00:32 習慣三：講者以前什麼都用 Opus 5.5，其實應該把 Opus 5.5 和 Sonnet 5.5 搭配使用。
  ↳ 講者以前覺得最強的就該一直用，所以什麼都丟給 Opus 5.5。後來發現兩個模型各有長處，分工搭配比全押在同一個上更好。
• 00:32 Sonnet 剛獲得 Claude Code 模型至今最大的改進之一。Sonnet 5.5 的 agentic coding benchmark 分數接近 Sonnet 5 的七倍。
  ↳ benchmark 是比較模型表現的評分；agentic coding 大致是指讓 AI 自己規劃、一步步完成寫程式的工作。Sonnet 5.5 這項分數接近 Sonnet 5 的七倍，進步非常大。
• 00:32 Opus 5.5 仍是需要判斷力的開放式複雜工作的合適模型，例如交付 production code、系統設計，甚至財務或法律分析。
  ↳ 需要拿主意、沒有標準答案的事交給 Opus 5.5，例如寫要正式上線給使用者用的程式（production code）、規劃系統架構，或做財務、法律分析。
• 01:02 Sonnet 5.5 產出結果較快、成本較低，適合範圍明確的任務，例如修 bug、開發功能，或製作文件、簡報、試算表。
  ↳ 範圍清楚（clear scope）、本來就知道要做什麼的任務，用 Sonnet 5.5 就夠了，例如修 bug、做一個功能、產出文件、簡報或試算表。它比較快，也比較省錢。
• 01:02 講者目前的工作流程：用 Opus 5.5 做批判性思考與規劃，用 Sonnet 5.5 做實際執行的工作。他說這讓工作流程大幅改善。
  ↳ 講者現在先讓 Opus 5.5 把事情想清楚、擬好計畫，再交給 Sonnet 5.5 動手做。需要思考的部分用強的模型，執行的部分用快又便宜的，他說整個流程順很多。

根據影片，Sonnet 5.5 的 agentic coding benchmark 分數和 Sonnet 5 相比如何？