前言：一個月燒掉 $100 的真實故事
如果你正在考慮升級 Claude Code 的訂閱方案，或者已經升級了卻發現 token 還是不夠用，那你來對地方了。
這不是一篇推銷文，而是一個真實的使用心得。
我從 Pro Plan（$20/月） 開始使用 Claude Code，很快就發現 token 不夠用。心想：「升級到 Max Plan（$100/月）應該就沒問題了吧？」
結果呢？
Max Plan 的 token 也不夠用。
更尷尬的是，我花了大把的 token 去處理一些看似簡單的 bug，像是：
- 體脂率的小數點精度問題
- 排便次數顯示 null 和 0 的差異
這些問題聽起來簡單，實際上卻各花了大量 token 去「探索」程式碼。
直到我發現問題的根源不是 token 不夠 (Pro plan是真的不夠！)，而是我沒有找到對的 Skill 來處理這類問題。
問題分析：Token 都燒去哪了？
讓我用一張圖來說明沒有使用正確 Skill 時的除錯流程：
看到問題了嗎？
這就是「漫無目的的探索」——AI 不知道該往哪裡找，所以它嘗試讀取所有可能相關的檔案，每次讀取都在消耗 token。
Token 消耗的真相
| 操作類型 | Token 消耗 | 實際價值 |
|---|---|---|
| 讀取不相關的檔案 | 高 | 零 |
| 廣泛搜尋 grep/glob | 中 | 低（通常需要多次） |
| 隨機嘗試修復 | 高 | 可能為負（引入新 bug） |
| 來回確認「這樣對嗎？」 | 中 | 低 |
我的真實案例：為了修一個體脂率顯示的小數點問題，AI 讀取了：
- Model 檔案（2個）
- ViewModel 檔案（3個）
- View 檔案（2個）
- Repository 檔案（2個）
- GraphQL 查詢檔案（1個）
- 還有各種「可能相關」的 utils
總共讀了 10+ 個檔案，才找到問題其實只在 2 個檔案裡。
解決方案：使用正確的 Skill
我安裝了不少 Skill，也自己寫過幾個。但坦白說，在除錯時我一直沒想到要用 systematic-debugging 這個 Skill。
直到這次踩坑，我才意識到它正是為這種場景設計的。
什麼是 Systematic Debugging？
它是一種假設驅動的除錯方法，核心理念是：
先思考，再行動。先建立假設，再驗證假設。
使用方式
當你遇到 bug 時，在開始之前先輸入：
/systematic-debugging
這會啟動一個結構化的除錯流程，AI 會：
- 先釐清問題：「你看到了什麼症狀？預期行為是什麼？」
- 建立假設：「可能的原因有 A、B、C」
- 設計驗證：「只需要讀這 1-2 個檔案就能驗證假設 A」
- 精準定位：避免讀取不相關的檔案
實戰對比：有 Skill vs 沒 Skill
案例：體脂率小數點精度問題
問題描述：體脂率應該顯示 4 位小數，但只顯示了 2 位。
沒有使用 Skill 的流程
我：體脂率只顯示 2 位小數，應該要 4 位
AI：讓我搜尋相關程式碼...
[讀取 body_fat_model.dart]
[讀取 diary_view_model.dart]
[讀取 diary_page.dart]
[讀取 body_composition_repository.dart]
[讀取 graphql_queries.dart]
[讀取 number_formatter.dart]
[讀取 diary_card_widget.dart]
...
找到了！問題在 number_formatter 的 toStringAsFixed(2)
消耗：讀取 8+ 個檔案，大量 token
使用 Skill 的流程
我：/systematic-debugging
體脂率只顯示 2 位小數，應該要 4 位
AI：讓我先釐清問題範圍。
症狀：顯示精度不足
預期：4 位小數
實際：2 位小數
假設優先順序：
1. View 層格式化問題（最常見）
2. ViewModel 層轉換問題
3. Model 層資料問題（較少見）
驗證假設 1：請告訴我顯示體脂率的是哪個頁面？
我：diary 頁面的 body fat card
AI：[只讀取 diary_body_fat_card.dart]
找到了！這裡使用 toStringAsFixed(2)，改成 4 即可。
消耗：讀取 1 個檔案，精準定位
Token 節省效果
| 指標 | 無 Skill | 有 Skill | 節省 |
|---|---|---|---|
| 讀取檔案數 | 8+ | 1-2 | 75-85% |
| 搜尋次數 | 5+ | 1-2 | 60-80% |
| 總 Token 消耗 | 高 | 低 | 70%+ |
| 解決時間 | 長 | 短 | 50%+ |
為什麼會忽略正確的 Skill？
明明裝了很多 Skill，為什麼遇到 bug 時沒想到用？
我反思了一下，大概有這些原因：
| 情況 | 心態 |
|---|---|
| Bug 看起來簡單 | 「這應該很快就能修好，不用特地叫 Skill」 |
| 習慣讓 AI 自己處理 | 「讓它搜就好，反正它會找到」 |
| Skill 太多，不確定用哪個 | 「systematic-debugging 是做什麼的來著…」 |
| 趕時間 | 「先讓它跑，我邊看邊引導」 |
回頭看，這些「省時間」的想法反而花了更多時間和 token。
如何避免重蹈覆轍
方法 1：在 CLAUDE.md 中加入鐵則
把 Skill 使用規則寫進專案的 CLAUDE.md，讓 Claude Code 每次開啟專案時都會看到：
## Debugging Rules - IRON LAW
- **ALWAYS use `/systematic-debugging` skill BEFORE proposing any fix**
- **NEVER explore codebase randomly** - this wastes tokens and time
- Follow hypothesis-driven debugging:
1. Define symptoms clearly
2. Form hypotheses about possible causes
3. Design minimal verification steps
4. Eliminate causes systematically with targeted reads
方法 2：記住關鍵場景對應的 Skill
# 遇到 bug 時
/systematic-debugging
# 需要規劃實作時
/brainstorming
# 完成功能要 review 時
/requesting-code-review
# 需要寫實作計畫時
/write-plan
方法 3：善用 Explore Agent
當你需要了解程式碼結構時，使用 Task tool 的 Explore agent，而不是讓 AI 自己 grep 來 grep 去：
「使用 Explore agent 幫我找出處理 user authentication 的相關檔案」
進階技巧：其他節省 Token 的方法
1. 提供精確的上下文
❌ 不好的問法：
「幫我修這個 bug」
✅ 好的問法：
「diary 頁面的 body_fat_card.dart 中，
體脂率顯示只有 2 位小數，應該要 4 位。
問題可能在格式化的部分。」
2. 善用 CLAUDE.md
把專案架構、命名規則、常見檔案位置寫在 CLAUDE.md 中，AI 就不用每次都從頭探索。
3. 追蹤資料流
對於顯示問題，先確認資料流：
API → Model → ViewModel → View
問 AI 從哪一層開始檢查，而不是讓它全部都看一遍。
結論：找對工具比升級方案重要
經過這次經驗，我的心得是：
1. Skill 是設計來解決特定問題的
每個 Skill 都有它的適用場景。systematic-debugging 就是為了除錯設計的，早點用就能少走彎路。
2. 寫進 CLAUDE.md 比記在腦子裡可靠
人會忘記，但 CLAUDE.md 每次都會被讀取。把重要的工作流程寫進去，形成「鐵則」。
3. 升級方案不是解決效率問題的答案
從 $20 升到 $100，如果使用方式不變，很快又會不夠用。
改變使用方式，找到對的 Skill，才是根本解法。
希望這篇文章能幫你少走一些彎路。
如果你也有類似的經驗或其他節省 token 的技巧，歡迎交流。
延伸閱讀：
寫作時間： 2025-12-20