如果你最近在用 Claude Code 寫程式，你可能注意到了：它好像變笨了。

不是那種「喔這個問題我不會」的誠實笨法，而是一種更令人沮喪的狀況——它會忘記剛剛為什麼要改某行程式碼、會重複說同樣的建議、會在一些你覺得很簡單的任務上繞圈子。你會忍不住想：「是我 cue 的方式不對嗎？還是 Claude 真的退步了？」

你不是唯一這麼想的人。過去一個月，這個問題在開發者社群中引發了大量討論，有人懷疑 Anthropic 偷偷 downgrade 了模型，有人懷疑是系統 prompting 出了問題，還有人直接貼出了截圖——同一個 prompt，上週得到的答案和這週完全不一樣。HackerNews 上相關討論獲得了超過 500 個 upvote、近 400 則留言，話題熱度僅次於當週的 GPT-5.5 發表。

四月二十三日，Anthropic 終於發布了完整的事後檢討報告。這篇文章不是一紙官腔的聲明，而是一份相當誠實的技術自白——裡面詳細說明了三個各自獨立、卻剛好同時發生的問題，以及他們從中學到的教訓。

作為每天依賴 AI 輔助工具的開發者，這份報告的價值不僅在於「Anthropic 修了什麼 bug」，更在於它呈現了一個真實的縮影：當 AI 產品在「更快」和「更聰明」之間做取捨時，那些看不見的螺絲是如何一顆一顆鬆掉的。

不是模型的問題：API 層始終穩定

先說一個重要的結論：API 層沒有受到影響。

如果你不是用 Claude Code 這個產品，而是直接透過 API 呼叫 Claude（無論是 Sonnet、Opus），你的體驗從頭到尾都沒有改變。Anthropic 在報告中特別強調了這一點——他們從一開始就能確認推理層和 API 基礎架構是正常的。

換句話說，問題出在 Claude Code 這個產品層，而不是 Claude 模型本身。

這是一個有意義的區別。它解釋了為什麼有些人覺得「Claude 變笨了」，而另一些人（特別是 API 使用者）完全無感。同時它也暗示了一個更深層的事實：當一個 AI 產品從 API 到底層 prompting 再到使用者介面之間疊加了太多層時，任何一層的「微小調整」都可能在下游被放大成明顯的感覺差異。

Anthropic 花了將近一個月的時間，把這三層問題逐一拆解開來。

問題一：推理能力的預設值調錯了（影響最大，也最根本）

背景：為什麼要把預設值調成 medium？

今年二月，Anthropic 在 Claude Code 中發布了 Opus 4.6，預設的推理強度設為 high。

這聽起來是好事。推理強度越高，模型越能深思熟慮地解決問題。但問題很快浮現：Opus 4.6 在 high 模式下，有時候會思考太久——久到 UI 看起來像當機了。而且 high 模式的 token 消耗相當可觀，對那些用量接近上限的使用者來說，這變成了一個日常痛點。

三月四日，Anthropic 做了一個決定：把預設推理強度從 high 降為 medium。

內部的評估顯示，medium 模式在大多數任務上「智能表現略低一些，但延遲顯著降低」。而且 medium 模式不會出現 high 模式下那種偶發的超長延遲 tail latency（某些請求的思考時間會異常地長）。從產品體驗的角度來看，這個權衡聽起來很合理——大多數使用者會寧可快一點、省一點，而不是每次都想得很深。

但他們錯估了一件事：使用者對「變笨」的敏感度遠高於對「變快」的感知。

使用者的反應：不是每個人都會去改設定

Anthropic 事後做了不少努力來補救這個決策：他們在啟動時增加了提示通知、在介面中加了推理強度選擇器、甚至把「ultrathink」功能帶了回來。使用者可以透過 /effort 指令隨時切換模式。

但數據不會說謊：大多數人從來沒有改過預設值。

這是一個產品設計上很經典的教訓——你給使用者一個選擇，但使用者不一定會去選。預設值就是產品的承諾，當承諾從「聰明但稍慢」變成「普通且快」時，使用者的第一反應不是去翻設定，而是直接得出結論：「Claude 變笨了。」

轉折：四月七日的 revert

在持續聽到使用者的抱怨後，Anthropic 在四月七日做出了 reversal。現在，Opus 4.7 的預設推理強度改為 xhigh，其他模型的預設值則恢復為 high。

這個決定等於承認了最初的判斷是錯誤的。Anthropic 在報告中說得很直白：「This was the wrong tradeoff.（這是錯誤的權衡。）」

對開發者來說，這件事的啟示很直接：當你使用 Claude Code 時，建議檢查一下目前的推理強度設定。 如果你用的是 medium，而且最近感覺 Claude 的輸出品質下降了，試著調回 high 或 xhigh，很可能問題就解決了。

問題二：一個快取優化 bug 讓 Claude 失憶了

如果說第一個問題是「產品策略失誤」，那麼第二個問題就是典型的工程事故——一個看似合理的最佳化，因為一個實作上的 bug，造成了意想不到的連鎖效應。

原本的設計：清理閒置 session 的舊推理記錄

Claude Code 在處理任務時，會把模型的推理過程記錄在對話歷史中。這樣在後續的每一個回合，Claude 都能看到自己「為什麼做這些修改、為什麼呼叫這些工具」。這是 Claude Code 能夠連續執行複雜任務的關鍵——它依賴於上下文記憶。

為了減少 API 呼叫的成本，Anthropic 使用了 prompt caching。當一個 session 有一段時間沒有活動時，該 session 的快取會被清除，釋放空間給其他請求。

三月二十六日，他們推出了一個看似很聰明的效率改善：如果一個 session 已閒置超過一小時，與其讓使用者在下一次恢復時負擔完整的重新載入成本，不如清掉舊的推理記錄，只保留最近一次的思考結果。因為在閒置一小時後，這個請求無論如何都會觸發快取 miss，所以清除舊記錄可以減少傳送給 API 的 uncached token 數量。

設計很合理，但實作上出了一個 bug。

Bug 的具體行為：不是清一次，是每次都清

原本的邏輯應該是：當 session 恢復後，清掉一次舊的 thinking，然後恢復正常，繼續保留完整的推理歷史。

但 bug 導致了完全不同的行為：一旦 session 跨過閒置門檻，後續的每一個請求都會觸發一次清理。 除了最近一個 thinking block 之外，所有更早的推理記錄全部被丟棄。

更糟的是，如果你在 Claude 還在進行工具呼叫（tool use）的過程中發送了後續訊息，這個 bug 會導致連當前回合的推理記錄也被清掉。Claude 會繼續執行任務，但它越來越不記得自己為什麼要這樣做。

結果就是使用者報告的那些症狀：健忘、重複、奇怪的工具選擇。

為什麼這個 bug 這麼難抓？

Anthropic 的團隊花了一個多星期的時間才找到並確認 root cause。原因有幾個：

  1. 這個 bug 只會影響閒置 session 的恢復行為：如果你一直在同一個 session 中連續工作，永遠不會碰到這個問題。它是 corner case 中的 corner case。

  2. 兩個不相關的實驗干擾了重現：一個是伺服器端關於訊息佇列的內部實驗，另一個是 thinking 顯示方式的改變——後者意外地在大多數 CLI session 中壓制了這個 bug 的表現，導致團隊用自己的內部版本測試時完全沒發現問題。

  3. 傳統的測試方法不夠：這個 bug 位於 Claude Code 的上下文管理、Anthropic API 和 extended thinking 三個系統的交界處。它通過了多人程式碼審查、自動化測試、端到端測試——團隊事後用 Opus 4.7 的 Code Review 功能重新檢查當時的 PR，才發現 Opus 4.7 能找到這個 bug，而 Opus 4.6 沒辦法。

修復與教訓

Anthropic 在四月十日推出了修復（v2.1.101）。同時，他們也學到了一個重要的經驗：對於這種涉及多層系統交互的變更，不要只依賴傳統的測試手段。他們正在把更多程式庫加入 Code Review 的上下文，讓模型可以在審查程式碼時獲得更完整的視角。

對一般開發者來說，這個案例也提醒了一件事：如果你的 AI 輔助工具突然表現出「失憶」或「重複」的行為，很多時候不是模型的問題，而是快取或上下文管理出了狀況。重開一個新 session 往往是最快的解決方案。

問題三：系統 prompt 的一句話，讓模型變啞了

第三個問題是最小、卻最直接的——只因為系統 prompt 裡的一句話。

為了降低冗長，加了一句長度限制

Anthropic 最新的模型 Opus 4.7 有一個明顯的特徵：它很啰嗦。官方在發布時就提過這個問題——這讓它在處理困難問題時更聰明，但也會產生更多的輸出 token。

在 Opus 4.7 發布前幾週，團隊開始調整 Claude Code 以適應這個新模型。他們使用了多種方法來控制冗長度：模型訓練調整、prompt engineering、改善 thinking UX。但其中一個系統 prompt 的改動，在編碼品質上造成了不成比例的負面影響。

這句 prompt 的內容是：

「Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.」

翻譯成白話就是：工具呼叫之間的文字限制在 25 字以內，最終回應限制在 100 字以內——除非任務需要更多細節。

團隊在內部測試了數週，跑了一系列評估，都沒有發現回歸問題。他們對這個改動有信心，於是在四月十六日隨著 Opus 4.7 一起上線。

真正的損失：3% 的智能下降

但在後續的調查中，Anthropic 用更廣泛的評估集進行了 ablation 測試——一次去掉一行 prompt，觀察每一行對結果的影響。結果發現：這句長度限制導致 Opus 4.6 和 Opus 4.7 都下降了約 3%。

3% 聽起來不大，但對於一個經過大量優化的模型來說，這是一個顯著的衰退。團隊在四月二十日立即 revert 了這個變更。

這個案例說明了 prompt engineering 的一個殘酷現實：你以為你在最佳化效率，結果你在破壞智能。 一個人類看起來很合理的「簡潔指引」，對模型來說可能是對思考深度的壓抑。而且，標準的評估測試可能捕捉不到這種微妙的衰退——你需要更全面的評估、更細緻的 ablation 分析，才能看到這些隱藏的代價。

三個問題的疊加效應：為什麼看起來像全面退化

這是整個事件中最值得注意的結構性問題。

Anthropic 的調查顯示：這三個問題各自影響了不同的流量、發生在不同的時間點，但疊加在一起之後，使用者感受到的是一個「全面、不一致的退化」。

如果只有一個問題發生，使用者可能只會覺得「今天 Claude 有點怪怪的」。但三個問題同時存在，使用者會得到一個連貫的結論：「Claude 真的變笨了——而且變笨很多次。」

Anthropic 坦承，他們在三月上旬就開始收到回報，但一開始很難區分這些回報與正常的 feedback variation 之間的差異。內部使用者也因為使用了不同版本的 Claude Code 而沒有立即重現這些問題。

這說明了大型 AI 產品的一個維運挑戰：當你的使用者和你的開發團隊跑的不是同一個 build 時，你很難即時感受到使用者的痛點。 為了解決這個問題，Anthropic 說他們會確保更大比例的內部員工使用與一般使用者完全相同的公開 build，而不是開發中的測試版本。

Anthropic 的改善計畫：不僅是修復，更是流程的重建

除了修復這三個問題之外，Anthropic 還推出了一系列制度性的改善措施：

系統 prompt 變更的管控強化

逐步上線與觀察期

更好的人工審查機制

補償措施

對開發者的啟示：AI 工具的信任何以維繫？

回頭看整件事，我認為最有價值的不是 Anthropic 修了哪些 bug，而是它展示了當一個 AI 產品從「令人驚艷」走向「穩定可靠」的過程中，必然會碰到的那些角力。

每個產品團隊都會在「更快」和「更聰明」之間取捨。Claude Code 的推理強度調整就是一個典型的例子——Medium 在內部測試中「足夠好」，但對使用者來說，「足夠好」並不夠。因為人們之所以選擇慢一點的模型，就是為了那個偶爾出現的 brilliant insight。當你把 brilliance 的發生機率從「偶爾」降為「幾乎不會」時，你已經破壞了產品最有價值的部分。

快取問題則說明了另一個現實：在複雜的系統中，一個「合理的最佳化」可能在 99% 的情況下沒有問題，但剩下的 1% 會以使用者無法理解的方式表現出來。AI 產品尤其如此——因為你無法透過「輸出錯誤訊息」來診斷問題，模型只會安靜地變笨，而你只會覺得它不可靠。

至於系統 prompt 的那句話——它是最容易被忽視的。因為它太合理了。誰會覺得「讓 AI 說重點」是一件壞事？但問題在於，對 AI 來說，「說重點」和「停止思考」之間的界線，比人類想像中模糊得多。

Anthropic 在這份報告中展現的透明度值得肯定。不是每一家公司都願意公開承認自己的三個錯誤，並且逐一解釋每個錯誤是怎麼發生的。但對於一個正在建立開發者信任的產品來說，這份誠實可能比修復本身更值錢——因為它讓你知道，他們知道問題在哪，而且他們正在建立一個系統來確保同樣的事情不會再發生。

如果你正在使用 Claude Code，現在就可以做兩件事：檢查你的推理強度設定，確保它在 high 或以上；然後確認你的版本已經更新到 v2.1.116 以上。如果你最近因為品質問題而冷落了它，或許可以再給它一次機會——在今天的使用者身上，那些看不見的螺絲，Anthropic 已經鎖緊了。