0:00 0:00
Powered by NotebookLM. You may check facts.

如果你最近逛過 Reddit 的 r/ClaudeAI 或相關論壇，一定看過這類抱怨：

"Claude Code 完全不能用了"
"連最簡單的 bug 都修不好"
"明顯被 nerf 了，一定是為了省成本"

但實際情況是什麼？作為一個高度依賴 AI 協作開發的人，我想從技術角度分析這個問題。

確實發生過的問題

首先要誠實說明：Anthropic 在 2025 年確實出過兩類問題。

問題一：品質問題（8-9月，已修復）

Anthropic 在 9 月發布了詳細的技術 postmortem，揭露三個基礎設施 bug：

1. 路由錯誤（8/5 - 9/4）

短上下文請求被錯誤路由到為 1M token 上下文設計的伺服器。

影響:

  • 初期影響 0.8% 的 Sonnet 4 請求
  • 8/29 的負載平衡變更放大了問題
  • 最嚴重時（8/31）影響 16% 的請求
  • 約 30% 的 Claude Code 使用者至少有一則訊息被路由錯誤

關鍵問題: 一旦被路由到錯誤的伺服器，後續請求會「黏」在同一個錯誤的伺服器上，讓使用者感覺問題持續存在。

2. 輸出損壞（8/25 - 9/2）

TPU 伺服器配置錯誤，導致 token 生成時出錯。

影響:

  • 在英文 prompt 中生成泰文和中文字元
  • 影響 Opus 4.1 和 Opus 4（8/25-8/28）
  • 影響 Sonnet 4（8/25-9/2）

3. XLA 編譯器 bug（8/25 - 9/12）

改進 token 選擇的程式碼無意中觸發了 XLA 編譯器的潛在 bug。

影響:

  • Claude 在生成文字時會排除最可能的 token
  • 確認影響 Haiku 3.5
  • 可能也影響部分 Sonnet 4 和 Opus 3

Anthropic 強調:

"我們從不會因為需求、時段或伺服器負載而降低模型品質。使用者回報的問題完全是基礎設施 bug 造成的。"

問題已經修復

修復時間表:

  • 9/2: 發現並回滾 TPU 配置問題
  • 9/4: 修復路由邏輯、回滾 Haiku 3.5 的 XLA 問題
  • 9/12: 回滾 Opus 3 的 XLA 問題
  • 9/16: 在 Vertex AI 完成部署

現在是 10 月中旬，這些問題已經解決超過一個月了。

為什麼還是有人持續抱怨？

如果品質問題已經修復，為什麼網路上還是充斥著「Claude 被 nerf」的討論？

原因可能是：

1. 用量限制確實影響工作流程

這是真實的問題。即使你的使用方式正確，專案密集時還是可能撞限。

但關鍵是：這不是「能力下降」，這是「配額管理」。

2. 使用方式問題被放大

最近在 Reddit 上看到一篇很中肯的評論，分析了「agentic coding demo」的誤導性：

"所有 demo 都一樣：空專案開始，『嘿 Claude，幫我做個東西！』20 分鐘後就有個差不多能動的東西，帶著漂亮的 Tailwind 樣式。『哇，我已經完成 70% 了！』"

"但這不是軟體工程！這是 template，而且是最簡單的部分。真正的複雜度在最後 30%。"

評論作者指出關鍵問題:

"如果你連系統的核心抽象、介面、資料模型、不變量都說不清楚，那 Claude 不是問題所在。"

3. 工具跳槽的無限循環

更有趣的是，我注意到有些人開始說：

  • "Claude 不行了，我改用 Codex"
  • "Codex 也不行，換 Cursor"
  • "Cursor 也開始爛了，試試 Windsurf"

如果是因為用量限制，換工具是合理的。

但如果是因為「AI 修不好 bug」「程式碼越改越亂」，那他們會一直換下去。

因為問題不在工具，在使用方式。當你不理解系統架構、期待 AI 一鍵搞定所有問題時，換任何工具都會遇到同樣的挫折。

就像不會開車的人抱怨方向盤不好用，換一台車也不會突然學會開車。

使用方式的差異

從我自己的經驗來看，使用 AI 的方式決定了體驗。

有效的工作流程:

1. 先想清楚架構
   例：「BLE 接收器應該偵測 CH5 characteristic，不是字串比對」

2. 給明確的情境和限制
   例：「ESP32-S3, 用 USB HID, 要支援這些報告格式...」

3. 主動偵錯 AI 的輸出
   例：「這個邏輯不對，應該改成...」

4. 迭代改進而非推翻重來
   例：「CH5 偵測加上去，其他保持不變」

無效的工作流程:

1. 「幫我做個 XXX 系統」（需求不清楚）

2. AI 生成一堆程式碼（看不懂）

3. 跑不起來（不會偵錯）

4. 「AI 怎麼這麼爛，連這都做不好」

Reddit 評論作者總結得很好：

"如果你只是不斷要求加功能，AI 會寫程式碼、寫程式碼、寫程式碼，直到你的專案變成打地鼠式的 bug 混亂，連 Claude 都理不清。你需要少用 Claude 來加有趣的新東西，多用它來維護日益增長的程式碼庫。"

這種差異會直接反映在「用量消耗」上：

  • 有效使用：迭代清晰、token 用得精準
  • 無效使用：來回修改、token 消耗快速

所以撞到用量限制的原因可能有兩種：

  1. 專案密度高、迭代頻繁（合理的高用量）
  2. 使用方式不對、來回修改（無效的高用量）

前者撞限是正常的，後者撞限是可以避免的。

客觀結論

關於「被 nerf」的討論，需要區分兩件事：

1. 品質問題（8-9月）

  • ✅ 確實發生過
  • ✅ Anthropic 公開承認
  • ✅ 最嚴重時影響 16% 請求
  • ✅ 已在 9 月修復

2. 用量限制（7月至今）

  • ✅ 確實存在且持續
  • ✅ 7 月悄悄收緊，引發爭議
  • ✅ 8 月正式宣布每週限制
  • ✅ 10 月 Claude 4.5 後消耗更快
  • ⚠️ 這是配額管理問題，不是能力下降

3. 使用方式的影響

即使在用量限制內，不同的使用方式會有截然不同的體驗：

有效的使用方式:

  • 理解系統架構
  • 給明確的需求和限制
  • 能看懂和偵錯程式碼
  • 迭代改進而非推翻重來

無效的使用方式:

  • 需求不清楚就讓 AI 做
  • 看不懂 AI 生成的程式碼
  • 出問題就丟回去修
  • 不斷加功能直到變成 bug 打地鼠

關鍵區別：

  • 前者用量限制是唯一問題（撞限就得等）
  • 後者即使沒限制也會覺得「AI 變差了」（因為方法不對）

現在還在抱怨的人

  • 合理的抱怨: 用量限制確實影響工作流程
  • 可能誤判的: 把使用方式問題當成工具問題
  • 會繼續換工具的: 不解決根本問題，換什麼都一樣

工具只是工具。

就像抱怨鋸子不好用的人，換成電鋸、鏈鋸、雷射切割機，還是不會砍樹。因為問題不在工具的鋒利度，在於不知道怎麼砍。

我的實際體驗

作為一個只能用單指打字、高度依賴 AI 協作的開發者，我在 10 月完成了：

  • ✅ Unified Remote Evo 完整重寫（Kotlin + Compose）
  • ✅ TouchBridge 技術設計（ESP32-S3 BLE→USB HID）
  • ✅ EmulStick 協議逆向（BLE GATT 架構分析）
  • ✅ 多篇技術部落格文章
  • ✅ 生產環境系統的維護與最佳化

但上週我也撞到了每週用量上限。

24 小時沒有 Claude，只能用 Codex。工作還是完成了，但確實感受到限制的影響。

所以我的結論是：

  1. 能力沒有被 nerf - 品質問題已修復，協作體驗依然很好
  2. 用量確實被限制 - 這是真實的配額管理問題
  3. 使用方式很重要 - 理解架構的人受限制影響較小

Reddit 評論作者說得對:

"我從沒遇到使用限制（5X 方案，但 Sonnet 就夠了）。我很少看到它遇到無法解決的 bug。當遇到時，我就 esc-esc 倒回去，重新給予更好的上下文，總是能得到很好的結果。"

"我發現我的成果遠超過同樣時間內獨自能做到的，因此 CC 物超所值。"

但他說的「從沒遇到使用限制」，可能只是他的專案密度還沒那麼高。

如果你的專案夠密集、迭代夠頻繁，用量限制確實會是問題。

AI 協作開發需要兩個條件：

  1. 足夠的配額（這是 Anthropic 要解決的）
  2. 正確的使用方式（這是使用者要學習的）

缺一不可。

延伸閱讀

想更深入了解「理解能力」vs「執行能力」的討論，以及 AI 時代的開發哲學，可以參考：

理解與執行的分離：從 Vibe Coding 談起

本文基於 Anthropic 官方 postmortem、社群討論和個人開發經驗。如果你對 AI 協作開發、技術哲學有興趣，歡迎交流。