隨著 AI 輔助開發工具的普及，最近越來越多人開始接觸 Claude Code。筆者使用這套工具進行開發已接近半年，深刻體會到它強大的能力，但也觀察到許多新手剛入門時最常碰壁的痛點。
這個痛點不是程式寫不出來，而是 Rate Limit（使用頻率限制）。不少新加入的朋友抱怨，才剛開始工作 1-2 小時就觸發每小時限制（Hourly Limit）；更慘的是，明明專案才進行到一半，用了 3-4 天就撞到了每週限制（Weekly Limit），導致工作被迫停擺。
如果你目前訂閱的是 Claude Code Pro 方案，想要在有限的配額下完成專案，你需要更有策略地使用算力。以下是我總結出的實戰心法。
重點文章
A：策略性分配模型
Opus 4.5 的確強大，邏輯推理能力驚人，但它的「價格」（Token 消耗權重）極高。若你全程使用 Opus 4.5，很快就會耗盡配額。我強烈建議大家「謹慎」且「混合」使用這兩個模型：
1. Planning 階段：投資 Opus 4.5
在專案剛開始，或是要開發一個全新複雜功能時，請毫不猶豫地使用 Opus 4.5。
- 原因： Opus 擅長長程規劃與架構設計。
- 做法： 讓 Opus 幫你擬定完整的開發計畫（Step-by-step Plan）、定義資料結構、設計 API 介面。
- 效益： 一個好的架構可以避免後續無數次的重寫。這階段的 Token 投資回報率最高。
2. Execution 階段：切換回 Sonnet 4.5
一旦計畫確定，進入實際寫 Code (Coding) 的環節，請切換回 Sonnet 4.5。
- 原因： Sonnet 4.5 的寫碼能力已經非常優秀，速度快且消耗較低。
- 做法： 拿著 Opus 擬定的計畫，讓 Sonnet 逐一執行。大多數的 CRUD 操作、切版、邏輯實作，Sonnet 都能勝任。
B：Debug 時的「兩次機會」
開發過程中難免遇到 Bug。這是最容易浪費 Token 的黑洞。新手常犯的錯誤是：在同一個錯誤上不斷與 Sonnet 糾纏，來回對話十幾次卻無法解決，白白燒掉配額。
我的建議是設立「止損點」：
- 如果透過 Sonnet 4.5 進行 Debug，嘗試 2 次修正後仍然無法解決問題，請立刻切換到 Opus 4.5。
- 通常 Sonnet 解不掉的 Bug 往往涉及深層邏輯或罕見的邊緣情況，這時候需要 Opus 更強的推理能力來「一擊必殺」。解決後，記得再切換回 Sonnet 繼續工作。
C： 架構先決：拆細！拆細！拆細！
這點非常重要，所以我必須強調。隨著專案進展，程式碼行數會越來越多。許多新手習慣將所有邏輯寫在少數幾個檔案裡（例如幾千行的 main.py 或 App.js）。這在傳統開發中或許只是維護性差，但在 AI 開發時代，這會直接導致你要進行一個小修改也花上很多 token 來處理。
為什麼？因為 Context Window（上下文視窗）。當你要求 Claude 修改某個功能時，它必須「讀取」相關的程式碼檔案。如果你的檔案非常巨大，每次對話 Claude 都要重新閱讀這幾千行程式碼，這會消耗驚人的 Token 量。
解決方案：模組化（Modularization）
- 讓架構便於「被 AI 維護」： 將功能拆分成獨立的小檔案、小的函式庫。
- 精準上下文： 當你需要修改 A 功能時，Claude 只需要讀取
feature_a.ts，而不需要載入整個專案。 - 效益： 這不僅能大幅節省 Token，延後觸發 Rate Limit 的時間，也能讓 AI 的輸出更準確，因為干擾資訊變少了。
D：升級 Claude Max
上述方法都是在有限資源下的最佳化策略。但如果你是全職開發者，每天需要長時間依賴 AI 進行高強度工作，且預算允許，升級到 Claude Max 是最直接的解決方案。
Claude Max 的配額足以支撐你在工作時間內長時間使用 Opus 4.5，這能帶來質的飛躍，讓你不再因為擔心配額而綁手綁腳，專注於創造價值。
E：用 Codex 作次選
如果預預有限，筆者建議可同時訂閱 ChatGPT Plus，當中可使用 Codex，現在 GPT-5.2 codex-high 的能力非常強，只是速度較慢。當你觸建 Rate Limit 時，換 Codex 來代勞也是可行的選擇。如果不想花錢，用 Gemini CLI 的免費額，也可暫時幫你。
總結：先規劃後執行
善用 Opus 進行規劃與困難除錯，將日常執行交給 Sonnet，並且絕對要執行嚴格的程式碼模組化。掌握這些原則，你就能在 Claude Code 的世界裡游刃有餘。
