把 Claude Opus 5.5 當成你日常主力模型 ☕ Buy me a coffee

🧑‍🏫 這支影片把 Anthropic 的新模型 Opus 5.5 和上一代 Opus 5 放在一起，用同一個專案實際跑給你看，比較速度、回報方式和耗掉的額度。講者也分享自己平常怎麼設定，讓 AI 該想深的時候想深，簡單的工作就交給便宜的模型。如果你每天都在用 Claude，看完就知道怎麼調設定，讓額度撐更久。

• 00:00 Opus 5.5 和 Opus 5 比起來更快，也更會說清楚自己做了什麼，每個 token 便宜 20%
  ↳ token 是模型計算文字量和費用的單位，你可以把它想成「字數」。Opus 5.5 比 Opus 5 快，回報做了什麼也比較清楚，而且每個 token 還便宜兩成。
• 00:00 用 Pro、Max 或 Team 訂閱的話，額度可以多用 25%
  ↳ Pro、Max、Team 是 Claude 的付費訂閱方案。有訂閱的人改用 5.5，同樣的額度可以多用 25%，能做的事更多。
• 00:00 因為得出結果需要的 token 比較少，所以同一個任務的成本便宜 40%
  ↳ 省錢來自兩個地方：每個 token 變便宜，完成同一件事用的 token 也變少。兩個加起來，同一個任務的總成本少了四成。
• 00:00 並排實測：同一個專案、同一個 prompt，兩邊都用 medium effort，左邊是 Opus 5，右邊是 5.5
  ↳ 這是公平的對照：同一個專案，同一段 prompt（你下給 AI 的指令），effort（決定模型動手前要想多深的設定）都設 medium，只換模型。
• 00:31 測試題目是一個四捨五入的 bug：用了折扣碼的訂單，退款金額會差幾分錢
  ↳ bug 就是程式錯誤。題目是用了折扣碼的訂單退款時，金額會差幾分錢。這是四捨五入造成的誤差，跟錢有關，再小都得修。
• 00:31 兩個模型都去讀退款程式碼、找到拆分折扣的地方、修好之後跑測試
  ↳ 兩個模型的做法一樣：先讀處理退款的程式，找出把折扣拆開計算的那一段，修好之後跑測試，也就是用事先寫好的檢查確認程式沒有改壞。
• 00:31 5.5 不到一分鐘就完成，整段回應在一個畫面內就放得下
  ↳ 5.5 不到一分鐘就修好，回報也很短，一個畫面就看得完，不用一直往下捲。
• 00:31 5.5 的回應只交代四件事：改了什麼、跑了哪些測試、遇到的一個狀況、還有一個要問使用者的問題
  ↳ 5.5 的回報只講四件事：改了哪裡、跑了哪些測試、中間碰到的一個狀況，還有一個要你決定的問題。沒有多餘的長篇說明。
• 00:31 Opus 5 還在讀 README、money helpers 和測試套件，先看過專案裡更多東西才回覆
  ↳ 這時 Opus 5 還在讀 README（專案說明文件）、money helpers（處理金額的共用小程式）和整套測試，想先摸清整個專案再回答。
• 01:01 Opus 5 的 tool call 比較多，回應也比較冗長；這次 5.5 比 Opus 5 快 30%
  ↳ tool call 是模型使用工具的動作，例如讀檔案、搜尋、執行指令。Opus 5 的動作比較多，話也比較多，這次 5.5 快了約三成。
• 01:01 在 Max 訂閱上，5.5 用掉 5 小時額度的約 4%，Opus 5 用掉 6%
  ↳ 5-hour limit 是訂閱方案每 5 小時能用的額度。在 Max 方案上跑這一題，5.5 用掉約 4%，Opus 5 用掉 6%。
• 01:01 講者說每個人跑出來會不一樣，但他跑了很多次，5.5 每次用掉的 5 小時額度都比 Opus 5 少
  ↳ 講者提醒這不是保證的數字，每個人跑出來會不一樣。但他試了很多次，5.5 每次用掉的額度都比 Opus 5 少。
• 01:01 Opus 5.5 預設是 medium effort；effort 大致是指模型在行動前，每一輪要花多少心思思考
  ↳ effort 大致是模型每一輪動手前要花多少心思思考。想得越多通常越周到，但也比較慢。5.5 沒有特別調的話，預設就是 medium。
• 01:34 講者平常大部分工作用 medium 就夠了，只有某些情況還是會切到 high
  ↳ 講者的經驗是，平常大部分工作用 medium 就夠了，只有某些特定情況，才值得切到想得更深的 high。
• 01:34 範例：要求在 orders handler 改一個欄位名稱，模型讀 handler、改名、測試通過，照指示完成
  ↳ 例子：請模型把 orders handler（處理訂單請求的程式）裡的一個欄位改名。它讀了程式、改了名字，測試也通過，看起來照指示做完了。
• 01:34 但 mobile app 也會送出這個欄位，在那邊叫 customer_ref（有底線），而且會經過 serializer
  ↳ 但手機 App 也會送出這個欄位，只是寫成有底線的 customer_ref。serializer 是負責轉換資料格式的程式，這個欄位也會經過它。
• 02:05 模型搜尋 customerRef 時搜不到那個檔案，所以沒改到；修正本身沒錯，只是不完整
  ↳ 模型用 customerRef 去搜尋，找不到寫法不同的那個檔案，所以那邊沒改到。已經改的部分沒錯，只是只改了一半。
• 02:05 修改會橫跨多個檔案或整個專案時，講者還是會用 high
  ↳ 所以講者的原則是：只要修改會牽動很多檔案，甚至動到整個專案，他就會用 high。
• 02:05 改用 high 並要求全部改完後，模型追查了是誰送出那個 payload，找到 mobile client 和 serializer 一起改名
  ↳ 換成 high 並明講要全部改完後，模型去追查這包資料（payload，就是傳出去的資料內容）是誰送的，找到手機端和 serializer，一起改名。
• 02:05 用 high 時還多加了一個小測試，避免以後再發生同樣的問題
  ↳ 用 high 時它還主動多寫了一個小測試。以後如果有人又改漏，測試就會報錯提醒。
• 02:05 只要是動到整個專案的修改都用 high，改完就切回 medium
  ↳ 做法很簡單：動到整個專案的大改用 high，改完馬上切回 medium，不要一直開著 high 白白多花時間和額度。
• 02:05 另一個輕鬆見效的做法：把 subagent 放在比較小的模型上跑
  ↳ subagent 是主模型分派出去做子任務的小幫手。讓它們改用比較小的模型來跑，是不費什麼力氣就能省資源的做法。
• 02:37 只負責探索程式碼的 subagent，不需要 Opus 等級的推理能力
  ↳ 像是只負責翻程式碼、找東西放在哪裡的 subagent，工作很單純，用不到 Opus 這種頂級的推理能力。
• 02:37 自訂 subagent 可以直接在 frontmatter 把 model 設成 Sonnet
  ↳ 如果你自己定義了 subagent，它的設定檔開頭有一段 frontmatter（放設定值的區塊），在裡面把 model 寫成 Sonnet（Claude 的中階模型）就好。
• 02:37 也可以在 settings.json 用 CLAUDE_CODE_SUBAGENT_MODEL 環境變數，一次設定所有 subagent 的預設模型
  ↳ settings.json 是 Claude Code 的設定檔。在裡面設定 CLAUDE_CODE_SUBAGENT_MODEL 這個環境變數（一種設定值），就能一次指定所有 subagent 預設用哪個模型。
• 02:37 講者的日常設定：Opus 5.5 用 medium；一次改很多檔案時才用 high；唯讀的 subagent 用 Sonnet，有時甚至用 Haiku
  ↳ 講者的日常組合：主力用 Opus 5.5 開 medium，一次要改很多檔案才切 high。只讀不改的 subagent 交給 Sonnet，有時甚至用更輕量的 Haiku。
• 02:37 介紹一個好用的指令：/claude-api prompt-audit
  ↳ 他推薦一個好用的指令叫 /claude-api prompt-audit，用途是幫你檢查現有的指示寫得適不適合新模型。
• 03:08 就算只用 Claude Code、沒有用 API，這個指令也會檢查你的 CLAUDE.md 和 skills，把裡面的指示調整成適合 Opus 5.5
  ↳ API 是讓程式直接串接 Claude 的管道。沒用 API 也能用這個指令，它會檢查 CLAUDE.md（寫給 Claude 的專案說明）和 skills（預先寫好的工作流程），調成適合 5.5。
• 03:08 總結：比 Opus 5 進步很多，速度更快、額度更耐用，講者也覺得用起來順手很多
  ↳ 講者總結：5.5 比 Opus 5 進步很多，速度更快，額度更耐用，他自己也覺得用起來順手很多。

影片中，講者在什麼情況下會把 Opus 5.5 從 medium 切到 high effort？