你的 Claude Code session 裡，每一次工具呼叫都用 Opus。讀一個 5 行的 config 檔？Opus。跑一個 ls 指令？Opus。改一個 typo？還是 Opus。

這就像叫一個年薪千萬的 CTO 去影印文件。他當然做得到，但你的預算會先陣亡。

Claude Code 其實內建了三種模型可以切換——Haiku、Sonnet、Opus。差異不只是「聰明程度」，是整個成本結構不同。Haiku 的 token 價格大概是 Opus 的十分之一，但處理日常任務的能力有 Sonnet 九成水準。

關鍵不是「哪個模型最好」，而是「哪個任務配哪個模型最划算」。

三種模型像三種員工

先用一個類比把基本概念打通。

想像你開了一間軟體公司，有三種角色可以指派任務：

Haiku 是剛畢業的工程師。 速度快、成本低、日常任務處理得不錯。寫個腳本、跑個指令、讀個檔案回報內容——這些事交給他完全沒問題。但你不會讓他做架構決策。

Sonnet 是資深工程師。 寫 code 品質穩定，能處理中等複雜度的 bug，理解上下文的能力強。大部分日常開發工作交給他就對了。

Opus 是技術長。 深度推理、跨檔案架構分析、處理模糊需求——這些是他的強項。但他的時間（token）最貴，不該花在影印文件上。

一間有效率的公司不會讓 CTO 做所有事。它會讓每個人做最適合自己的工作。模型混用的邏輯一模一樣。

Claude Code 怎麼切換模型

切換方式很直覺。在 Claude Code 裡有幾種做法：

互動式切換： 按 /model 叫出模型選擇器，或用快捷鍵切換。

設定預設模型： 在 ~/.claude/settings.json 裡設定 defaultModel。

Sub-agent 指定模型： 這是混用策略的核心。當你用 Agent tool 啟動子代理時，可以透過 model 參數指定該子代理要用哪個模型：

1
2
3
4
5
Agent({
  description: "讀取 config 檔案",
  prompt: "讀取 /app/config.json 並回報其中的 database host 設定",
  model: "haiku"
})

這行 model: "haiku" 就是關鍵。主 session 用 Opus 做決策，但把簡單的讀檔任務交給 Haiku 子代理去跑。一來一回省下的 token 是倍數級的。

Skill 裡指定模型： 寫 Skill 的時候也可以建議使用特定模型。例如一個負責格式化 log 的 Skill，完全可以用 Haiku 跑。

什麼任務配什麼模型

這張對照不用背，看一遍有個直覺就好。核心原則就一句話：任務越不需要推理，越該往便宜的模型丟。

Haiku 負責的事（成本最低，速度最快）

檔案讀取和內容回報。跑 shell 指令然後回傳結果。格式轉換（JSON 轉 YAML、Markdown 轉 HTML）。搜尋 codebase 裡的特定字串。簡單的正則表達式處理。

這些任務有個共同特徵：輸入明確、輸出格式固定、不需要判斷。

Sonnet 負責的事（性價比最高）

寫單一函式或模組。修復明確的 bug（有 error message 可以追）。Code review 單個檔案。寫測試案例。文件撰寫和更新。

這類任務需要理解上下文，但不需要跨多個系統思考。Sonnet 在這個區間的 CP 值最高。

Opus 才出場的事（深度推理）

跨多檔案的架構重構。模糊需求的拆解和規劃。複雜 debug（牽涉多個服務的交互作用）。安全性分析。需要權衡取捨的設計決策。

如果一個任務你自己想了十分鐘還沒結論，那它就值得用 Opus。

實際工作流長什麼樣

舉一個真實場景。你想重構一個 API 模組，需要：

  1. 先掃描所有用到這個模組的地方
  2. 理解目前的呼叫模式
  3. 設計新的介面
  4. 實作修改
  5. 跑測試確認沒壞

用單一模型跑，全程 Opus，token 用量大概 150K。

混用策略是這樣拆的：

Step 1（Haiku）： 掃描 codebase，列出所有 import 和呼叫點。這是純搜尋任務，不需要推理。

Step 2（Sonnet）： 分析呼叫模式，歸類出幾種使用方式。需要理解程式碼，但不需要做設計決策。

Step 3（Opus）： 根據 Step 2 的分析結果，設計新介面。這步需要權衡 breaking change 的影響、向後相容性、未來擴展性。

Step 4（Sonnet）： 按 Step 3 的設計實作程式碼。設計已經定了，剩下的是執行。

Step 5（Haiku）： 跑測試套件，回報結果。純執行，不需要判斷。

結果？Token 用量降到大約 60K，省了 60%。產出品質相同，因為需要深度推理的 Step 3 還是 Opus 在做。

三個容易踩的坑

第一，別讓 Haiku 做需要上下文的事。 Haiku 的 context window 較小，而且對微妙的程式碼語意掌握不如 Sonnet。如果一個任務需要「理解這段 code 在做什麼」而不只是「找到這段 code 在哪」，至少用 Sonnet。

第二，別在 Opus session 裡做太多瑣事。 每次你在 Opus session 裡跑 ls 或 cat，那些 token 都是按 Opus 的價格計算的。把瑣事委派給 Haiku 子代理，主 session 只負責決策。

第三，模型切換本身有 overhead。 每次啟動一個子代理都有 prompt 的固定成本。如果一個任務只需要 10 個 token 就能完成，拆出去反而更貴。經驗法則是：預期輸出超過 200 token 的任務才值得拆。

一個可以掛更多東西的框架

學完這篇，你手上有一個很簡單的決策框架：

看到一個任務，問自己：「這個需要推理嗎？」

不需要推理 → Haiku。需要理解上下文但不需要設計決策 → Sonnet。需要權衡取捨、做判斷 → Opus。

這個框架不只適用於 Claude Code。任何 multi-model 的 AI 系統——不管是 LangChain、CrewAI、還是自己寫的 agent pipeline——底層邏輯都一樣：把推理成本分配到真正需要推理的地方。

接下來可以研究的方向：Claude Code Sub-agents 教學 講的是怎麼把任務拆給子代理執行，跟這篇的模型混用策略剛好互補。

參考來源：Claude Code Docs - Models
參考來源：Claude Opus 4.7 新功能實戰