當 Claude 額度燒太快，我決定自己寫 Python

把 AI 當程式碼在跑

大概從今年初開始，我認真用 Claude Code 處理日常的工程雜事。掃描資料夾、整理 PDF、批次重新命名——這些事情以前要寫腳本，現在直接叫 Claude 做就好。

一開始體驗很好。你說「幫我把這個資料夾裡的 PDF 分類到對應的子目錄」，Claude 不只給你程式碼，它會問你要幾個分類、要不要 dry-run、邊緣情況怎麼處理。那種感覺很像有一個工程師坐在旁邊，你說需求，它動手。

1 月到 3 月，這套用法沒什麼問題。訂閱一週的額度用得很舒服，偶爾緊一點但不至於中斷。

然後某一天，額度瞬間燒光了。

2500 個檔案，10 分鐘燒光

事情發生在我讓 Claude 直接處理一批有密碼保護的 PDF 分類任務時候。資料夾裡有 2500 個檔案，我讓 Claude 一個一個分析、判斷類別、移動到對應目錄。

Claude 動得很快。快到不到 10 分鐘，整週的 token 額度就清零了。

然後系統給我一個禁閉期：5 小時內無法使用。

等了 5 小時，就像終於等到一盤牛排上桌——結果一口還沒吃完，盤子就又空了。

那 5 小時我就坐在那裡想：我剛剛燒掉的，幾乎全是「Claude 自己呼叫工具」的開銷，真正的判斷邏輯其實很簡單。每個 PDF 的操作步驟完全一樣，Claude 卻要逐一重新組裝 context、呼叫工具、產出結果，每一輪都是幾萬 token 在走。

這件事讓我意識到：我在用最貴的方式做最無腦的事。

禁閉期結束之後，我換了做法。讓 Claude 把整個判斷邏輯寫成一支 Python 腳本，Claude 只負責設計邏輯和寫 unit test。之後的執行跟 Claude 完全無關——同樣 2500 個檔案，Python 跑了不到 3 分鐘，Sonnet 算力消耗大概只有寫腳本那一次，約占整批任務的 10%。

為什麼現在特別痛：token 通膨

這件事讓我開始回頭看 1 月到 3 月為什麼沒有感覺。

答案很簡單：那時候 Claude 的用戶還沒這麼多，算力相對充裕，額度的體感比較寬鬆。

我把近幾個月發生的事叫做「token 通膨」。你的訂閱費沒有變，但能買到的算力實質上在縮減。

這不是我的主觀感受——Anthropic 在 2026 年 3 月底公開承認，「用戶消耗 Claude Code 額度的速度遠超預期」，這是當時的最高優先事項。$200/月 Max 方案的訂閱者，有人不到 20 分鐘就見底。

背後的結構性原因更不樂觀：

• GPU 租金暴漲：Nvidia Blackwell 晶片的租用價格在 2026 年初的兩個月內上漲了 48%，達到每小時 $4.08
• 交期拉長：資料中心 GPU 目前交期長達 36–52 週，訂了也要等
• 新增算力遙遙無期：Anthropic 預估，現在投入的資本要到 2026 年底或 2027 年才能轉換成實際可用算力

這是供需基本面問題，不是 Anthropic 想不想解決的問題。在那之前，同樣的訂閱費能做的事情會持續縮水。

從「讓 Claude 執行」到「把工具搶回來自己用」

理解了 token 通膨的結構，解法就變得很清楚。

舊流程（高耗損）：

我 → prompt → Claude → 臨時產生工具 → Claude 自己使用 → 噴 token

每次任務，Claude 都要重新理解情境、產生工具、執行、回報結果。token 在這個過程裡的每一步都在燒。一個「掃描 2500 個 PDF」的任務，若讓 Claude 逐一處理，context 組裝＋工具呼叫的開銷是真正邏輯的幾十倍。

新流程（低耗損）：

我 → prompt → Claude → 萃取工具邏輯 → 寫好 unit test → 我自己執行

Claude 只做一件事：把判斷邏輯設計清楚、寫好測試、交給我。之後的執行完全繞開 AI，直接跑 Python。

以這次的 PDF 密碼偵測工具為例，邏輯其實很簡單：用一個故意錯誤的密碼去嘗試開 PDF，系統報錯就代表有密碼保護。這個判斷做一次就夠了，之後掃 2500 個檔案，每一個都執行同樣的邏輯，完全不需要 AI 介入。

中間也踩到一個細節：有一個 PDF 被標記為「有密碼」，手動確認卻完全可以直接開。原來是這類 PDF 設了 owner password（限制列印、複製等權限），但沒有真正的開檔密碼。邏輯上需要多一次確認才能正確排除。這種邊緣情況，讓 Claude 幫忙想是值得的；但想清楚之後，就寫進程式碼，固定下來，不用每次重新思考。

兩種流程的算力對比

這個策略本質上是把 AI 的邊際成本降到零。Claude 是高固定成本、高彈性的資源——適合做一次性的思考、設計、邊緣情況判斷。Python 腳本一旦寫好，邊際成本幾乎是零，跑一次和跑一萬次成本一樣。

做的事情其實是經典的「知識萃取」：把 Claude 腦子裡的判斷邏輯，固化成可重複執行的程式碼。這在企業裡叫做知識管理，在這裡叫做省 token，但本質是一樣的。

更有趣的是，這個流程比「直接讓 Claude 跑」更可靠。工具收斂、邊界清楚、有測試覆蓋，對它的行為有完整掌握。讓 Claude 每次臨時產生工具再自己用，其實是在用最貴的方式做最不穩定的事。

所以這不只是省 token 的技巧，更像是一種正確使用 AI 的思維模型：AI 負責思考，程式碼負責記憶，執行交給機器。

一個不那麼顯然的觀察

AI 讓我更需要會寫程式，不是更不需要。

以前我可能會說「這個工具太小，不值得花時間從頭寫」，然後每次手動操作。現在有了 Claude，設計和實作的成本降低了，反而讓我更願意把重複的任務包成工具。

但工具本身，最終還是要靠我理解它在做什麼、知道什麼時候該信任它。

Claude 幫我把想法變成程式碼的速度快了十倍。但那個「想法」，還是得自己有。

這是短期現象，但值得經歷

回頭看，這整件事的根源不是 Claude 不夠好，而是算力供不應求。用戶激增，基礎設施還在追趕，token 的實質購買力在縮水。省著用，某種程度上也算是一種資源意識——用更少的算力做同樣的事，不是壞事。

但我相信這是暫時的。

技術的歷史一直在重演這個劇本。54kbps 數據機的年代，每一個 byte 都得精打細算；現在光纖寬頻讓人忘了「頻寬」這件事的存在。2G 手機的年代，WAP 傳輸；現在 5G 讓影片串流變成理所當然。遊戲也是——pixel art 時代美術師要在 16x16 的格子裡擠出表情，現在 8K 材質、光線追蹤，沒有人在算貼圖記憶體了。

AI 算力也會走同樣的路。現在我們在想「這個任務值不值得用 token」，就像當年在想「這封 email 值不值得撥接上網」。幾年後回頭看，這個問題本身會顯得很古老。

prompt 即 app 的時代終究會到來。 你說需求，AI 直接執行，不需要在中間插一層程式碼當緩衝。算力夠便宜的時候，這個分工就會自然消失。

但現在還沒到。所以這套「Claude 設計、Python 執行」的方法，是這個過渡期裡最務實的選擇。

結語

2500 個檔案、10 分鐘燒光額度、5 小時禁閉、token 通膨——這些不舒服的經驗，讓我找到了當下這個階段的正確分工。

Claude 負責思考和設計，Python 負責執行和重複。整批任務的 Sonnet 算力消耗從 100% 降到約 10%，工具反而更可靠。

等算力跟上來的那一天，這篇文章大概會變成一個時代的註腳：「原來那時候的人還在為 token 斤斤計較。」

在那之前，先把 Python 寫好。