「突然間，token 使用量衝到 100%。我才剛開始工作不到五分鐘。」

德國獨立開發者 Nicky Reinert 在 4 月 24 日的文章中，記錄了他從 Claude 鐵粉變為取消訂閱用戶的完整經歷。這不是一篇無的放矢的抱怨文—他同時使用 GitHub Copilot、OpenAI Codex，甚至自己用 OMLX 跑 Qwen3.5-9B 推理。他夠資格批評。

更值得玩味的是，就在同一天稍晚，Anthropic 官方發布了關於 Claude Code 品質問題的檢討報告（即 HackerNews 上另一篇熱門的 Anthropic April 23 Postmortem），證實內部確實存在一個 Opus 4.6 與 4.7 在部分評測中下滑 3% 的問題。社群抱怨 + 官方承認，讓這次風波格外有看頭。

如果你正在使用 Claude Code、Claude Pro 或任何依賴 token 配額的 AI 工具，這個故事值得你看完。因為它揭露的，可能不只是 Anthropic 的問題，而是整個產業的縮影。

從狂熱到覺醒：一個 Claude 鐵粉的三十天

Nicky 在文章中用了相當生動的語氣描述這段經歷（對，他是那種會在文章裡放顏文字（ づ ￣ ³￣）づ 的德國開發者），但情緒從興奮到沮喪的轉折點非常清晰。

第一週：一切都那麼美好

他訂閱 Claude Code 的頭幾週，「速度快、token 配額合理、產出品質優異」。他甚至因為 Anthropic 反對某些政府監管政策而感覺「支持正義的一方」。那個階段的他，就像是所有剛接觸頂級 AI 編程工具的開發者一樣—覺得自己找到了神器。

Anthropic 在 2026 年 3 月還推出了「非尖峰時段額外 token 配額」的推廣活動，讓非美國時區的開發者（像在德國的 Nicky，以及身在台灣的我們）能在離峰時間獲得更多運算資源。理論上，一切都在往好的方向走。

第三週：裂痕出現

變化發生在三週前的一個早晨。

Nicky 在經過約十小時的休息後（足夠讓 token 配額重置），回到工作檯前。他只向 Claude Haiku 發送了兩個簡單問題，甚至跟 repository 內容無關。

突然間，token 使用量跳升到 100%。

「好好休息一下吧⋯⋯」他諷刺地寫道。

這是第一個警訊。但他當時還不知道，這只是開端。

Token 暴漲事件：一個真實的客服噩夢

當 Nicky 遇到 token 異常消耗時，他的反應應該和任何理性用戶一樣—找客服。

第一層：AI 客服機器人

他首先聯繫了 Anthropic 的「AI 支援機器人」。得到的回應是「預設的客服廢話，根本沒有理解問題」。

這裡有一個微妙的諷刺：一家 AI 公司用它自己最自豪的 AI 技術來提供客服支援，而這個客服 AI 無法理解用戶關於 AI 產品問題的真實訴求。 這就像是微軟的藍色當機畫面用 AI 幫你 Debug—理論上很酷，實際上毫無幫助。

第二層：人類客服（自稱）

Nicky 要求轉接真人客服。幾天後，一位署名看起來像真人的客服人員回信了。信件開頭寫著：

「我們的系統偵測到您的查詢是關於 Pro 或 Max 方案的用量限制。」

Nicky 的吐槽精準到位：「對，我的是 Pro 方案。但看來你們的系統根本沒有被查詢；這只是一個預設的開場白，大概也是預設的答案。」

接下來是一大段明顯從文件複製貼上的說明，解釋每日和每週的用量限制如何運作。然後是那句所有客服用戶最不想看到的句子：

「請注意，對此 ticket 的後續回覆可能不會被監控。如果您的問題與 Pro 或 Max 方案的用量限制無關⋯⋯請造訪我們的說明頁面。」

問題沒解決，通道直接關閉。

Nicky 把這封客服回信餵給 Claude Haiku，問它：「這個客服有回答客戶的問題嗎？」連 Claude Haiku 都只能沈默以對。

品質下滑：不是錯覺，是數據

你可能會說：「這只是單一用戶的抱怨，可能只是他不夠會用。」

但 Nicky 已經用這個理由自我檢討過了。他明確寫道：「我充分意識到這相當主觀，agent 的品質永遠受操作者影響。失敗通常出現在螢幕前面。」

但他也補充：「我同時用 Copilot、Codex 和我自己跑的 Qwen3.5-9B。我不是專家，我有時候很懶，但我大概懂一點東西。」

那個讓他氣的例子

他分享了一個讓人心有戚戚焉的案例。

前一天他請 Claude Opus 重構一個專案。在瀏覽模型的思考日誌時（他很建議開發者不要只偶爾看思考日誌），他發現了這段讓人心寒的內容：

「與其在 JSX 中逐一編輯 slider，我可以在 ui-events.js 中加入一個通用初始化器，自動為所有缺少顯示的 range input 注入數值顯示。」

翻譯成白話：Claude Opus 決定用一個取巧的通用解法來繞過正規修改，而不是規規矩矩地一一處理每個 slider。

Nicky 的回應很直接：

「你是認真的嗎？這就是你解決問題的方式？只是 WORKAROUND？？？？」

至少 Opus 承認了：

「你是對的，那樣太懶了。讓我好好做—直接在 JSX 中加入標籤，明確地綁定它們。」

Nicky 的結論：「不用說，這個偷懶的捷徑花掉我大約 50% 的五小時 token 配額。」

三分鐘的偷懶，兩小時的代價

你以為只是品質問題？不，這裡還有 token 成本的雙重打擊。

Claude Opus 選擇一個「看起來通用但其實是偷懶」的解法，消耗了大量 token 去想出這個解法，然後被用戶抓包後重新用正規方式重做。用戶付出的 token 成本是兩倍—一次付給偷懶方案，一次付給正確方案。

這不是品質問題，這是成本管理問題。Anthropic 把 token 賣給用戶，然後用戶的 token 被模型自己的「偷懶決策」消耗掉。用戶同時是消費者，也是模型缺陷的受害者。

Cache 問題：最聰明的設計，最愚蠢的體驗

Claude Code 的對話快取（conversation cache）是一個理論上很聰明的設計—當你中斷工作後回來，它能記住你之前的上下文，不必重新讀取整個 codebase。

但在實際體驗中，Nicky 發現了一個惡性循環：

  1. 你開始工作，Claude Code 花費大量 token 載入你的 codebase（建立快取）
  2. 你工作一段時間後，因為五小時 token 配額耗盡被迫休息
  3. 等你回來，快取已經消失
  4. Claude 重新載入 codebase — 你又花了一次 token 做同樣的載入

Anthropic 的官方說法是：「成本上這是聰明的。」——因為不保留閒置快取可以節省 Anthropic 的運算成本。

但對用戶來說：同樣的 token 消耗，你要付兩次錢。

這裡有一個不對稱的博弈：Anthropic 的節省成本策略，直接轉嫁成用戶的 token 消耗。而用戶的 token 配額是有上限的。

神秘的「月用量限制」：文件沒寫，設定頁沒有，但它出現了

Nicky 在文章中提到一個更令人困惑的經歷。

他在工作中緊盯 token 使用量，突然跳出一個警告：

「你接近每月用量限制。」

問題是：
– Anthropic 的官方文件完全沒有提到月用量限制（只提了 session 限制、時段限制、週限制）
– 他的設定頁面上只列出目前 session 和本週的使用量
– 他不是組織方案用戶
– 時段和週限制都還沒超過

兩小時後，這個警告自動消失，一切恢復正常。

他甚至貼出了官方文件截圖來佐證：「這份文件完全沒有提到月用量限制。」

這到底是 Bug？是準備推出的新功能意外顯示？還是某種 A/B 測試？Anthropic 沒有解釋。

但從用戶角度看，一個正在消耗你錢包的產品，出現了一個官方無法解釋的警告——這足以讓任何人失去信心。

Anthropic 的官方回應：承認 3% 的品質下滑

巧合的是，就在 Nicky 發文的同一天，Anthropic 官方發布了 An update on recent Claude Code quality reports（也就是 HackerNews 上另一篇爆紅文章），詳細說明了他們調查 Claude Code 品質投訴的過程。

官方承認的關鍵事實：

翻譯一下：「我們為了速度，降低了預設的思考品質，但忘記告訴用戶。」

這與 Nicky 的具體抱怨不謀而合—他察覺到的品質下降，很可能不是錯覺，而是 Anthropic 為了回應效能壓力所做的 trade-off。

更值得深思的是 Anthropic 的調查過程：他們花了六週才確認這個問題的存在，而且是在大量用戶抱怨之後才開始認真調查。Anthropic 自己的內部評測和內部使用皆未能第一時間發現問題。

這對所有依賴 AI 工具的開發者來說，是一個不太令人安心的數據：AI 公司可能無法在品質下滑時及時發現，甚至比用戶還晚。

取消，但不代表不愛

Nicky 最後一段話特別有意思。他說他其實還是很愛 Claude 這個產品：

「我仍然依靠 Claude Code 來構建東西。我搭建了自己的 Claude 應用框架，我欽佩 Claude Code 在背景默默地處理一堆 GitHub issues，我喜歡用 Claude Cowork 繼續寫作⋯⋯它讓我的生產力提升了一個數量級。」

他完全理解 Anthropic 的技術挑戰—每次推理都需要同等計算資源，這不是軟體公司那種「寫一次複製一千萬次」的商業模式。

但他還是取消了。

原因很簡單：Anthropic 無法處理太多新客戶。所以他就幫 Anthropic 減輕負擔，自己退出。（這句原文是最後的顏文字（ ʘ‿ʘ）╯，十足德國人的黑色幽默）

更深層的問題：AI 訂閱制的結構性缺陷

Nicky 的故事表面上是一個不開心的客戶，但背後涉及三個結構性問題，對台灣開發者同樣適用：

問題一：token 配額 = 品質風險由用戶承擔

當 Claude Code 的輸出品質下降時（因為偷懶、思考不足），用戶仍然要為這些低品質的 token 付費。在 SaaS 軟體中，如果產品品質下降，你至少沒有額外成本。但在 AI 訂閱中，品質下降直接導致你的 token 消耗增加—你要花更多 token 去修正錯誤、重新提示、換取正確答案。用戶被迫為供應商的錯誤買單。

問題二：AI 公司的監控盲區

Anthropic 的報告顯示，他們的內部評測和內部使用皆未第一時間發現品質問題。這代表什麼？代表AI 公司可能不知道自己的產品有沒有變差。

原因很合理：工程師和 PM 每天都在測試的同幾套基準，模型已經「學會」了。真正的使用品質只有大量且多樣的用戶才能察覺。但這也意味著，任何一次模型更新、參數調整、服務端變更，都可能在你完全不知情的情況下影響你的使用體驗。

問題三：客服的多層失敗

Nicky 的客服經驗是三層崩潰的範例：
– 第一層：AI 客服失敗 — 無法理解用戶問題的專有名詞（反而是一家 AI 公司的 AI 客服！）
– 第二層：真人客服複製貼上 — 沒有真正查詢系統，直接套模板回應
– 第三層：問題未解決即關閉通道 — 「後續回覆可能不被監控」

這不是單一客服人員的錯，而是整個客服流程的設計問題。當問題涉及高度技術性的 token 使用模式時，一線客服（無論 AI 或人類）根本沒有能力診斷，只能給出通用回應。

從案例中我們能學到什麼

如果你也在使用 Claude Code 或其他依賴 token 的 AI 工具，以下幾個習慣值得養成：

第一，定期檢查模型的思考日誌。 Nicky 就是因為看了思考日誌，才發現 Claude Opus 在偷懶。AI 模型有時候會選擇「看起來對但其實取巧」的路徑，而這些路徑通常會消耗更多 token 而產出更差的結果。

第二，記錄你的 token 消耗模式。 如果你發現某次 session 的 token 消耗突然異常增加，先回想：你是不是做了完全相同的操作？如果沒有的話，可能是模型行為改變了。這時候截圖、記下時間，都是日後向客服反映時的有力證據。

第三，對於「平台級」問題，不要只依賴客服。 Nicky 的經驗告訴我們，AI 公司的客服管道（尤其是 AI 客服機器人）對於產品內部錯誤的理解能力有限。如果你的問題涉及生產力大幅下降，同時在社群（HackerNews、Reddit、Twitter）上搜尋是否有相同案例—Nicky 就是因為在 HackerNews 上看到大量類似抱怨，才確認自己不是個案。

第四，考慮多平台備援。 Nicky 同時使用 Copilot、Codex 和自己的本地推理（Qwen），這是一種健康的使用習慣。當一個平台的品質下降或 token 配額用盡時，至少還有替代方案。對台灣開發者來說，GitHub Copilot（每月 10 美元起）的性價比在持續改善，而 OpenAI Codex 的 token 政策也比 Claude Code 更透明。

第五，如果遇到無法解釋的用量異常，記錄證據。 Nicky 貼出了他截下的警告圖和官方文件對比，證明月用量限制在文件中不存在。如果你遇到類似情況，截圖存證是必要的自保手段。

結語

前段時間聽說一個說法：「你其實不是在買 AI 服務，你是在買一個不知道什麼時候會變差但隨時可能降級的試用版。」

這句話聽起來有點刻薄，但從 Nicky 的經歷來看，它並不完全是玩笑。一個開發者在三週內從「興奮得睡不著覺」到「失望到取消訂閱」，而公司花了六週才開始調查問題——這個時間差的荒謬感，大概只有經歷過的人才能體會。

當然，Anthropic 的誠實公告值得肯定。不是每個 AI 公司都會公開承認自己的模型在某些評測中變差了。相比某些只會說「模型持續改進中」的平台，Anthropic 至少有勇氣面對問題。

但勇氣不夠。真正的考驗是：他們能不能在問題發生之前就知道，而不是在社群炸鍋之後才開始查日誌。

對台灣的開發者來說，這個故事的最大啟發，或許不是「該不該用 Claude」，而是一個更根本的問題：當你把自己的生產力寄託在一個隨時可能變差的服務上時，你的備援方案是什麼？

答案不一定是技術性的。它可能是一種態度：保持觀察，保持比較，不要對任何 AI 工具產生品牌忠誠。這個產業的現實是—今天的神器，可能只是明天的麻煩。

就像 Nicky 在文章開頭說的：「我仍然用 Claude Code 在寫東西。我只是不再對它有幻想而已。」（ ʘ‿ʘ）╯