Claude 降智風波的真相

過去一個多月，社群一直有聲音說 Claude Code「變笨了」。我自己也感覺得到：對話中段開始失憶、重複問同樣的問題，usage limit 也掉得比以前快。

4/23 Anthropic 發出 postmortem，承認確實有問題，而且不是單一事件，是三個獨立 bug 在 3 月到 4 月中疊加發生。

結論：核心 API 與模型推論層沒事，問題全部發生在 Claude Code 這個 harness 層。這件事對所有在做 AI 產品的人都有參考價值，因為它展示了一個殘酷的事實：模型本身沒退步，但使用者體感有可能因為不容易注意到的 bug 而退步。

三個 bug，三種失效模式

3/4 那天團隊為了解決「UI 看起來卡住」的抱怨，把 Claude Code 的預設 reasoning effort 從 high 降到 medium，換取更低的 latency。影響 Sonnet 4.6 + Opus 4.6。

使用者的反應是：「感覺變笨了。」
後來客戶回饋很明確：寧願預設聰明、讓使用者主動降檔，也不要預設快速。
4/7 revert。

這是三個裡面技術最細節、也最有趣的一個。

背景：為了減少「閒置一小時後恢復 session」的 latency，團隊加了一個優化：閒置一段時間後清掉舊的思考過程的歷史，讓 prompt cache 可以命中。實作上用了 clear_thinking_20251015 這個 API header。

但是出了一個失誤：header 被錯用，變成「每一輪對話」都清一次 thinking，而不是只在長時間閒置後清一次。

結果導致：

這個 bug 沒被 code review 和測試揪出來，因為它只有在 session 閒置過久時才會遇到。內部測試通常跑的是乾淨的新對話，所以並沒有發現，最後追了超過一週才找到根源，4/10 在 v2.1.101 修掉。

為了降低 Opus 4.7 天生的多話的特性，team 在 system prompt 加了一條指令：

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

內部測試看起來都沒問題。但事件調查時把這條指令拔掉重測，發現這條 prompt 讓 Opus 4.6 和 4.7 的表現能力足足掉了 3%。
4/20 revert。

這個是最值得所有設計 system prompt 的人引以為戒的案例。我們都知道 LLM 對 system prompt 敏感，但「叫模型講話精簡」聽起來是多麼無害的一條指令，它應該只影響輸出風格，不應該影響推理品質？

但它就是會。限制輸出長度在語意上等同於限制模型「思考的表面積」，每次工具呼叫之間的輸出，本來就兼著推理的功能。壓縮它等於壓縮思考。

三個 bug 影響的是不同群體、不同時間段，所以外部看起來是「大範圍、不一致的降智」，內部指標又抓不到。典型的 Swiss cheese 模型：每個洞單獨看都不致命，疊起來就變成會掉下去的大坑。

Caching bug 尤其刁鑽，因為它和後端同期跑的幾個實驗互相干擾，加上 CLI 剛好有個顯示更新把症狀掩蓋住了。這是複雜系統的常態：問題不出在某一層，而是藏在幾層互相影響的交互作用裡。

Anthropic 在這次事件後也把 Code Review 工具升級列為重點，有趣的細節是：用 Opus 4.7 對著 caching bug 的 PR 跑 review，它抓得到；Opus 4.6 抓不到。這本身就是一個很強的論點：模型能力的提升，應該優先餵回到自己的開發流程裡。

我自己從這份 postmortem 裡提煉幾個實用原則：

預設值一旦偏離「效果最好」，使用者的信任損耗會遠遠超過 latency 省下來的好處。 這個天秤 Anthropic 押錯了邊。對 agentic workload 來說，多等 10 秒換一個對的答案，幾乎永遠划得來。
prompt caching 失效時，往往難以察覺。 快取沒命中不會報錯，只會讓帳單變貴、體感變差。有在用 caching 的，都該追 cache hit rate 的走勢，不能只靠有沒有 crash 來判斷系統正不正常。
system prompt 只要有改動，都要分模型測過，不能只靠內部看起來沒問題就帶過。 Anthropic 自己在事後檢討裡也把這件事列為首要改善項目，包括設立觀察期、分模型跑評估、追蹤對照測試結果。