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