title: Claude Code 變笨了？Anthropic 官方事後檢討：三起事故造成品質下滑
date: 2026-04-25
如果你的 Claude Code 在過去一個月裡突然變得健忘、重複，或是回答品質明顯下滑——你不孤單。你不是第一個這麼想的人。
上週，一位德國開發者在 HackerNews 上發表了一篇標題為「我取消了 Claude」的長文，抱怨 token 用量突然飆到 100%、程式碼品質下降、支援回應令人失望。留言區湧入數百條相似感受的討論：「我以為是我的提示詞寫法變了」「我切回 GPT 才找回生產力」。這不是少數人的錯覺。從開源社群的討論到專業開發者的論壇，「Claude 變笨了」成了過去一個月最熱的 AI 開發工具話題之一。
而 Anthropic 終於在 4 月 23 日發布了完整的事後檢討。
不是一個問題，是三個問題
Anthropic 工程團隊在官方部落格的檢討文章中坦言，這場品質風暴不是單一原因造成的，而是三個獨立的事故在時間上交錯發生。它們各自影響不同的使用者群、出現在不同的時間點，導致整體看起來像是一個模糊且不一致的退化——有些使用者覺得 Model A 變差了，有些覺得 Model B 變笨了，還有人認為是 token 用量被偷偷增加了。
讓我們照時間順序梳理這三起事故。
3月4日：推理程度從高調到中，代價是智慧
這是最早、影響範圍也最廣的改變。
今年 2 月，Anthropic 在 Claude Code 中發布了 Opus 4.6，預設的 reasoning effort（推理程度）設為「高」。這是合理的選擇——推理程度越高，模型在給出答案之前花的思考時間越長，產出品質通常也越好。Claude Code 的 effort 機制讓使用者可以根據任務類型調整這個權衡：想要更快、token 消耗更少的回應，就把 effort 調低；需要深度分析和複雜邏輯，就調高。
然而上線後，團隊很快收到大量回饋，指出 Opus 4.6 在高 effort 模式下有時思考時間過長，導致介面看起來像當掉了一樣，對使用體驗影響很大。有位開發者在社群中抱怨：「我等了 40 秒它才開始打字，我以為程式崩潰了。」
Anthropic 的內部評估顯示，中 effort 模式下，模型在大多數任務中的品質只略低於高模式，但延遲顯著改善，也能幫助使用者更有效地運用使用限制。於是 3 月 4 日，團隊做出了把預設推理程度從高調整為中的決定，並透過應用程式內的提示來說明這項改變。
問題很快就浮現了。使用者開始回報 Claude Code「變笨了」。雖然團隊後續推出了一系列設計改進來讓 effort 等級的設定更明顯（啟動提示、行內 effort 選擇器、重新加入 ultra think 模式），多數使用者仍然維持在預設的中等模式——大部分人根本不會注意到界面上多了一個選項。
到了 4 月 7 日，在收到大量付費用戶的抗議後，團隊終於決定完全回退這項變更。現在 Opus 4.7 預設為 xhigh effort，其他模型則預設為 high。
3月26日：一個快取優化的 bug，讓 Claude 變成金魚
第二起事故的技術含量更高，影響也更深層。
Claude Code 有一個重要的機制：當模型進行推理時，它會把思考過程保存在對話歷史中。這樣在後續的每一次互動中，Claude 都能看到自己之前為什麼做了那些編輯和工具呼叫。這個機制對維持連貫的長對話至關重要。
3 月 26 日，Anthropic 團隊推出了一個效能最佳化。為了降低成本，他們用了 prompt caching 技術——把對話中的思考區塊暫存在快取中，短時間內再次送出請求時可以直接讀取快取而不用重新計算。但思考區塊佔據大量 token，如果對話長時間閒置，這些思考區塊會佔用快取空間卻沒有被使用。
設計很直觀：如果一個對話 session 已經閒置超過一小時，清除舊的思考區塊可以降低使用者重新啟動對話的成本。反正請求本來就會因為快取未命中而重新計算，不如順便清理一些不必要的 token。團隊使用了 clear_thinking_20251015 這個 API header 來實作，搭配 keep:1 參數保留最近一次的思考。
bug 就藏在這裡。
實作中有一個邏輯錯誤：清除思考歷史本來應該只執行一次，但實際上它在同一個 session 的每一次後續互動中都被重複觸發。一旦一個 session 跨越了閒置閾值，之後的每一個請求都只保留最近一段思考，之前的全部丟棄。
這意味著什麼？意味著如果你在 Claude 正在執行工具呼叫時發送了一條追踨訊息，這個 bug 會讓新的互動也啟動了錯誤的清除標記——連當前這個 turn 的思考也被丟掉了。Claude 可以繼續執行，但越來越不清楚自己為什麼要做這些事情。使用者看到的現象：Claude 變得健忘、重複、做出奇怪的工具選擇。
更糟的是，由於思考區塊在每個請求中都被清除，這些請求也無法命中快取——每次都需要重新計算。這反過來解釋了另一個普遍的抱怨：為什麼使用限制消耗得比預期快那麼多。根據一位 Reddit 使用者的記錄，他在一次普通的 code review 工作中，原本五小時的 token 許可額在兩小時內就用完了。
這個 bug 處於 Claude Code 的上下文管理、Anthropic API 和延伸思考功能三者的交界處，通過了多次人類和自動程式碼審查、單元測試、端到端測試、自動驗證和內部試用。加上它只在邊緣情境（閒置 session 重啟）中才會觸發，團隊花了一週多的時間才找到並確認根本原因。
最終修復在 4 月 10 日上線。
4月16日：一個減少冗長的系統提示，不小心砍了品質
第三起事故最晚發生，但也最快被修復。
4 月 16 日，團隊在系統提示中加了一條指令，目的是減少 Claude 回應的冗長程度。Anthropic 的官方說法是「減少不必要的說明文字，讓輸出更精簡」。聽起來沒問題——不少使用者確實抱怨過 Claude 的回應太囉嗦。
但問題是，這條新指令與既有的 prompt 組合在一起後，意外地影響了程式碼品質。Claude 開始在不需要的地方過度簡化，跳過了原本應該保留的邊界檢查和錯誤處理。一位受影響的開發者描述：「它開始給我『只改必要部分』的程式碼，而不是『正確的』程式碼。」
這項變更影響了 Sonnet 4.6、Opus 4.6 和 Opus 4.7。團隊在 4 月 20 日回退了這條 prompt 指令，此時距離使用者開始抱怨大約間隔了四天。
為什麼花了這麼久才發現？
如果你讀到這裡，可能會想：一個 AI 公司，為什麼花了將近一個半月才搞清楚自己的產品出了什麼問題？
Anthropic 的解釋很誠實。這三起事故各自影響了不同比例的使用者流量、發生在不同時間，疊加在一起之後，整體效果看起來就像是一個廣泛但不一致的退化。更關鍵的是，早期的使用者回饋與正常的變異範圍很難區分——每次模型更新後都有人說「變差了」，多數時候只是心理作用或小樣本偏差。
團隊說，他們在 3 月初就開始調查這些回報，但內部測試和評估最初都無法重現使用者看到的問題。這是因為 bug 2（快取 bug）在大多數內部測試環境中不會觸發——它需要閒置一小時以上的 session 才會出現，而內部測試通常是連續進行的。
團隊也提到，兩個不相關的實驗增加了問題的複雜性：一個僅限內部的訊息佇列實驗，和一個正交的 thinking 顯示方式改變。後者反而在大多數 CLI session 中隱藏了 bug 2 的症狀——因為 thinking 顯示方式的改變讓使用者看不到思考區塊被清除的痕跡，所以連內部測試人員也沒有發現異狀。
修復後的補償與展望
截至 4 月 20 日，三起事故都已經完全修復。Claude Code 的最新版本 v2.1.116 已經包含了全部修復。
作為補償，Anthropic 在 4 月 23 日為所有付費訂閱者重置了使用限制——如果你過去一個月因為快取 bug 而提早消耗完 token，現在你的配額已經恢復了。
Anthropic 在文章中強調，他們正在檢討變更流程，確保未來的產品變更在推出前能更全面地評估其連鎖效應，尤其是在不同功能模組之間的交界處（這也是 bug 2 能夠通過層層審查的根本原因）。
對於正在猶豫是否要繼續使用 Claude Code 的開發者來說，官方這次的透明度和坦承程度本身就是一個正面訊號——至少他們沒有像某些 AI 公司那樣，把品質問題歸咎於「使用者期望太高」。
但這也提出了一個更深層的問題：當 AI 產品的行為可以因為一個簡單的系統提示調整而出現顯著變化時，「品質保證」這個在傳統軟體中已經成熟的領域，在 AI 時代該如何重新定義？
對台灣開發者的意義
Claude Code 在繁體中文開發社群中的使用率正在快速成長。我過去幾個月觀察到，越來越多的台灣工程師開始把 Claude Code 整合到日常工作流程中——有人用它做 code review，有人用它寫測試，有人甚至完全依賴它來處理重構。
這場品質風暴對台灣開發者的直接影響不僅是生產力的波動，還暴露了一個更大的問題：依賴 AI 編碼助手意味著你可能不自覺地接受了品質的隱性變化。
「我最困擾的不是它變笨了，而是我不知道它變笨了。」一位台北的後端工程師在社群中這樣說。這句話精準地捕捉了問題的核心——當你依賴一個模型來幫你做 code review 時，你如何判斷這個模型今天的「狀態」跟昨天一樣好？傳統工具的行為是可預測的：同一個版本、同一組設定，今天和明天行為一致。但 AI 產品不同，後端的系統提示、推理設定、快取策略，任何一個變動都可能改變你收到的結果。
對團隊而言，比較務實的因應方式是建立自己的驗證流程：不要盲目相信 AI 助手給出的任何建議。如果 Claude Code 突然改變了它過去一貫的程式碼風格，那不是你的錯覺——可能是後台又切了什麼開關。
你該怎麼做？
如果你也是 Claude Code 的使用者，以下幾件事可以幫助你降低類似風險：
第一，關注官方變更日誌。過去一個多月的事故都在 Anthropic 的開發者論壇和官方部落格上有公告。如果你用的是團隊方案，可以指定一個人負責追蹤 Claude Code 的版本更新和官方公告，任何版本更新後的 24-48 小時內特別留意輸出品質。
第二，建立自己的基準測試。在你的專案中保留一組固定的任務（例如一段特定的重構、一個 test suite 的撰寫），每次 Claude Code 更新後先跑一次基準測試，確認輸出品質沒有顯著變化。這和跑 regression test 是一樣的概念。
第三，不要鎖死在預設值。Claude Code 的 /effort 指令讓你可以手動調整推理程度。如果你的任務需要深度分析，確認 effort 設定在 high 或以上。新版中 Opus 4.7 已經預設為 xhigh，但如果你使用其他模型，可能需要手動檢查設定。
第四，學會觀察症狀。如果 Claude Code 突然變得特別健忘、一直在問你已經回答過的問題、或是做出奇怪的工具選擇——這不是你的提示詞有問題，可能是後端的問題。這時候可以暫停使用並向官方回報，而不是花時間調整 prompt。
說到底，一個月的混亂對 Anthropic 來說是一次昂貴的學習經驗，對使用者來說則是一個提醒：AI 編碼助手很好用，但它不是可靠的基礎設施。至少，還不是。這讓我想起那句經典的開發者笑話——「在我的機器上可以跑。」現在可能要改成「在今天的 Claude 上可以跑。」 這個行業還有很多路要走。