用 AI Coding Assistant 寫程式已經是日常了，但你有沒有算過每個月在上面燒多少 premium quota？我最近重新整理了一下自己的模型使用策略，發現其實不需要每個任務都上最強的模型。
問題：Premium Quota 不夠用
如果你跟我一樣重度使用 Cursor 這類 AI 編程助手，應該對「premium request 用完了」這個提示不陌生。
高階模型（像 Claude Opus 或 GPT-4 系列）確實強，但每次呼叫都會消耗 premium quota。如果什麼任務都丟給最強的模型，quota 大概撐不過半個月。
但反過來，全部用免費或低階模型又會影響效率——簡單的 bug 可能修半天，架構建議可能牛頭不對馬嘴。
所以核心問題是：怎麼在品質和成本之間找到平衡？
三層模型策略
經過幾個月的摸索，我整理出一套分層策略。核心概念很簡單：讓每個層級的模型做它最擅長的事。
第一層：頂級模型 — 負責「想」
用途：規劃、架構設計、Code Review、複雜 bug 分析
頂級模型（比如 Claude Opus）的優勢在於推理能力和上下文理解。它能看懂整個 codebase 的架構，理解模組之間的依賴關係，給出有深度的建議。
適合的場景：
- Plan 模式：讓它分析需求，拆解成具體的實作步驟
- Plan Review：執行完一輪修改後，讓它審視整體方向是否正確
- 複雜架構決策：「這個功能應該放在哪一層？」「這兩個模組要怎麼解耦？」
- 詭異 bug 分析：那種改了 A 壞了 B、log 看起來正常但行為就是不對的情況
這類任務通常不會太頻繁（一天可能就幾次），但每次都很關鍵。用頂級模型來處理，值得。
第二層：中階模型 — 負責「做」
用途：實際寫 code、修 bug、重構、Build error 處理
中階模型（比如 Claude Sonnet）的 coding 能力其實已經很強了，差別主要在深度推理。對於「規劃好了，照著做」這類任務，中階模型綽綽有餘。
適合的場景：
- Execute 模式：根據 Plan 的結果，逐步實作
- Build error 修復：編譯錯誤、型別不匹配這些，通常不需要太深的推理
- 重構：把一段程式碼改成另一種寫法，模式明確
- 測試撰寫：根據既有程式碼寫單元測試
這類任務佔了日常開發的大部分時間。用中階模型能省下大量 premium quota，而且品質差異幾乎感覺不到。
第三層：Auto / 免費模型 — 負責「雜事」
用途：commit message、格式化、快速問答、lint 修復
很多 AI 編程助手有「Auto」模式，會自動選擇最經濟的模型。這些小任務根本不需要動用到高階模型。
適合的場景：
- 產生 commit message：看 diff 寫摘要，任何模型都做得到
- 程式碼格式化：排版、import 排序
- 快速問答：「這個 API 的參數是什麼？」「這個 error code 是什麼意思？」
- Lint 修復：eslint、prettier 報的問題，通常有明確的修法
- 簡單的 code snippet：「幫我寫一個 debounce function」
這類任務一天可能有幾十次，如果每次都用 premium 模型，quota 根本不夠燒。用 Auto 模式讓它自己選，完全沒問題。
實際效果
用了這個策略大概兩週，我的觀察：
Premium 用量降了大約 60%。 之前什麼都丟給最強模型，現在只有真正需要深度思考的任務才用。剩下的 quota 可以用在刀口上。
開發效率沒有明顯下降。 中階模型執行 Plan 已經拆好的任務，其實跟頂級模型差不多快。因為難的部分（怎麼做）已經想好了，剩下的只是（照著做）。
反而更有結構。 被迫在每個任務前先想「這是哪個層級的工作」，間接讓開發流程更有組織。不會再出現「啊我直接叫 AI 幫我整個改掉」然後改到一半不知道在幹嘛的情況。
怎麼判斷一個任務該用哪層模型？
一個簡單的決策流程：
- 需要理解跨多個檔案的上下文嗎？ → 第一層
- 需要做架構決策或分析複雜問題嗎？ → 第一層
- 有明確的實作步驟，只需要執行嗎？ → 第二層
- 是機械性的、有固定模式的任務嗎？ → 第三層
如果不確定？先用第二層試試。如果結果不理想，再升到第一層。這比每次都用第一層然後月底 quota 見底好多了。
進階技巧：模型之間的接力
最有效的用法不是孤立地用每一層，而是讓它們接力。
一個典型的開發流程：
- 第一層：分析需求，產出 Plan（包含架構決策、步驟拆解、注意事項）
- 第二層：根據 Plan 逐步執行，每完成一個步驟就驗證
- 第二層：遇到 Build error，直接讓同層模型修
- 第一層：全部完成後，做一次 Plan Review，確認沒有偏離方向
- 第三層：產生 commit message，收工
這個流程的關鍵在於：第一層產出的 Plan 是結構化的，第二層可以直接照著做。這比每次都讓頂級模型從頭理解整個 context 高效得多。
不同工具的設定方式
不同的 AI 編程助手有不同的切換方式：
- Cursor：在 Settings 裡可以設定不同場景的預設模型，也可以在每次對話時手動切換
- 其他工具：大多支持在對話開始時指定模型，或者用 config file 設定預設值
重點不在工具本身怎麼設定，而是你腦中有這個分層的概念。知道什麼時候該用什麼層級，比會設定工具更重要。
成本意識是開發者的基本素養
這個策略其實反映了一個更大的觀點：AI 工具的使用也需要成本意識。
就像我們不會用 AWS 的 p4d.24xlarge 去跑一個 Hello World，也不應該用頂級 AI 模型去產生 commit message。資源永遠是有限的，聰明地分配才是正解。
特別是在團隊裡，如果每個人都無腦使用最強模型，公司的 AI 工具預算很快就會爆掉。制定一個團隊級的模型使用指南，不只省錢，也能讓大家更有意識地思考「我現在需要 AI 幫我什麼」。
結語
AI Coding Assistant 已經不是「要不要用」的問題，而是「怎麼用得聰明」的問題。三層模型策略不是什麼革命性的概念，但它讓我在品質和成本之間找到了一個實用的平衡點。
如果你也覺得 premium quota 總是不夠用，不妨試試這個方法。把最強的火力留給最難的問題，剩下的交給夠好的模型就行了。
畢竟，工程的本質就是在限制條件下做出最好的選擇——這點在 AI 工具的使用上也一樣。