Claude Code 品質下降事件：真正該記住的是 agent observability 與產品層風險
這篇 Threads 轉述 Claude Code 2026 年 3–4 月品質下降事件：AMD AI 團隊資深總監 Stella Laurenzo 用大量 Claude Code session log 指出，Claude Code 在複雜工程任務上變得更淺、更急、更常不讀完整上下文就動手改。後來 Anthropic 在 4 月 23 日發布官方 postmortem，承認確實有三個產品層問題疊加，造成 Claude Code、Claude Agent SDK、Claude Cowork 的體驗下降；但官方也特別說明，Claude API / inference layer 沒有受影響。
這件事值得記錄，不只是因為「Claude Code 變笨」這個八卦，而是它暴露了 AI coding 工具的真正風險：模型本身可能沒變，但產品外圍的 reasoning effort、prompt、cache、context trimming、預設值，都足以讓同一個模型在實務工作中變成另一個人。
先拆事實。
Stella Laurenzo 在 GitHub issue #42796 裡提出的資料包含：
- 6,852 個 Claude Code session files
- 17,871 個 thinking blocks
- 234,760 次 tool calls
- 觀察到 2026 年 2–3 月後，Claude Code 在 complex engineering tasks 上明顯退化
- 讀碼行為從平均約 6.6 reads before edits，下降到約 2
- stop-hook violations、過早停止、逃避責任、未完整研究就修改等行為增加
- 估算 Bedrock equivalent cost 從 2 月約 345 美元，3 月暴增到約 42,121 美元；部分原因是團隊同時擴大 concurrent agent sessions，但品質下降讓反覆修正成本放大
Threads 用「思考字數從 2,200 掉到 720」、「6.6 個關聯檔案變 2 個」、「帳單燒到 40,000 美元」來轉述，方向大致符合 GitHub issue / The Register 報導中的核心數據，但要注意一點：Anthropic 官方 postmortem 並沒有逐項承認 Stella 所有推論，也沒有說 API 受影響。官方確認的是產品層三個問題。
Anthropic 4 月 23 日 postmortem 的三個原因：
- 預設 reasoning effort 從 high 改成 medium
Anthropic 說，Opus 4.6 在 Claude Code 裡推出時，預設 reasoning effort 是 high。但有些使用者覺得 high mode 會想太久、UI 看起來像凍住，也會消耗更多 token。於是 Anthropic 在 3 月 4 日把 Claude Code 預設 reasoning effort 從 high 改成 medium，希望降低延遲與 token 使用。
官方後來承認：這是錯誤 tradeoff。使用者寧願預設更聰明，再自己對簡單任務調低 effort。這個變更在 4 月 7 日 revert，影響 Sonnet 4.6 與 Opus 4.6。
這裡的教訓很直接：AI coding 工具的預設值就是產品承諾。把 high 改 medium，不只是「省一點 latency」，而是在改變工程師以為自己正在使用的 agent 能力邊界。
- thinking history cache / pruning bug 造成「健忘」
Anthropic 在 3 月 26 日做了一個效率優化：如果 session 閒置超過一小時，為了降低恢復 session 的成本，清掉舊 thinking sections。設計上應該只清一次，之後恢復正常送完整 reasoning history。
但實作有 bug：一旦 session 跨過 idle threshold，之後每一輪都會清 thinking history。結果 Claude 看不到自己前面為什麼做那些 tool calls / edits，就會變得 forgetful and repetitive。這在 4 月 10 日修復，影響 Sonnet 4.6 與 Opus 4.6。
這是整起事件最關鍵的工程點：agent 不是只靠模型智商工作，而是靠 history、tool traces、reasoning context、cache policy 共同構成工作記憶。清錯 context，就像把資深工程師的工作筆記每分鐘撕掉一次。
- 降低 verbose 的 system prompt 傷害 coding quality
Anthropic 在 4 月 16 日為了降低 Claude Code 太囉嗦的問題，在 system prompt 裡加入類似這樣的限制：
Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.
這個限制在一般對話可能合理，但在 coding agent 場景會傷害品質。因為工程工作需要把假設、風險、檔案脈絡、修改理由、測試結果講清楚。Anthropic 後來做 ablation，發現相關 prompt line 對 Opus 4.6 / 4.7 評測造成約 3% drop，並在 4 月 20 日 revert。這影響 Sonnet 4.6、Opus 4.6、Opus 4.7。
這裡的教訓是：短不等於好。對 coding agent 來說，過度壓縮輸出可能讓模型少寫中間推理、少暴露不確定性、少提醒風險，反而讓工程師更難 review。
這件事對 AI coding 的啟發：
- 「模型沒變」不代表「工具能力沒變」
Anthropic 說 API / inference layer 未受影響，這句很重要。因為 Claude Code 品質下降不是單純模型權重變差，而是產品層變更：reasoning effort、thinking history、system prompt。對使用者來說，結果一樣是工具變差。
所以未來評估 AI coding 工具，不能只看模型名稱。要看：
- 預設 reasoning effort 是什麼
- 是否能固定 effort / model / tool behavior
- session history 如何保留
- cache / pruning policy 是否透明
- system prompt 是否頻繁變更
- 是否有 changelog 與 rollback 機制
- 笨 agent 比聰明 agent 更貴
Threads 裡那句「笨的 AI，比聰明的 AI 昂貴得多」值得記。原因不是笨模型單次 token 貴，而是它會製造 retry cost、review cost、debug cost、錯誤 merge cost、信任崩壞成本。
Stella 的資料也指向這件事：當 agent 不完整讀碼、過早動手、反覆修錯，成本不是線性增加，而是會被工程師重試與多 agent 並行放大。
- Agent observability 會變成必要基礎設施
Stella 團隊能把問題講清楚，是因為他們有 session logs、thinking blocks、tool calls、read/edit ratio、stop-hook violations。這代表成熟團隊使用 AI coding agent 時，不能只看「最後有沒有成功」，還要記錄：
- 每次修改前讀了哪些檔案
- read/edit ratio 是否異常
- thinking depth / reasoning effort 是否下降
- 是否反覆修改同一個 bug
- 是否有 premature stop
- 是否跳過測試或謊稱完成
- 每個任務實際 token / API / retry cost
沒有 observability，就很容易把工具退化誤判成「我 prompt 下不好」。
- 不要把雞蛋放在單一 agent 籃子裡
留言有人說，不要被 PUA 最好的方法就是雞蛋不要放在同一個籃子。這句在 AI coding 上很實用。當單一 vendor 的 agent 發生退化，如果團隊沒有替代模型、替代 CLI、替代 workflow，整個開發節奏會被綁架。
對 BigIntTech / Hermes / Forge 的實務建議：
- 重要任務不要只靠單一模型或單一 agent；保留 Codex、Claude Code、Hermes subagent、人工 review 的切換能力。
- 對高風險修改，要求 agent 先列出 read plan，再讀完關聯檔案，不能直接 edit。
- 建立 read/edit ratio、測試執行、diff size、重試次數等指標，作為 agent quality telemetry。
- 每次模型或 CLI 版本升級後，跑固定 regression tasks，而不是直接相信新版。
- 對自動 merge 的流程加防線：測試、lint、migration check、security scan、人工或第二 agent review。
- 對長 session / 多 turn 工作，特別注意 context pruning 與 cache 行為，避免 agent 忘記先前決策。
我的判斷：
這起事件不是「Anthropic 壞掉一次」而已，而是 AI agent 產品化後必然會遇到的系統風險。當 agent 能力來自模型、prompt、工具、cache、context、UI 預設值共同組成，任何一層小改動都可能讓高階工程任務退化。
真正成熟的 AI coding 團隊，不會只問「哪個模型最強」，而會建立自己的 agent observability、回歸測試、fallback vendor、審查制度與成本監控。
這也呼應 Allen KB 之前整理過的 Claude Code 高風險工程文章：高風險場景裡，最可怕的不是 AI 不會，而是它沒讀完整、想得太淺，卻仍然很自信地動手改。
參考來源：
- Threads 原文：https://www.threads.com/@finlab.quant/post/DX1SBpFller
- Anthropic Engineering: An update on recent Claude Code quality reports, 2026-04-23
- GitHub issue: anthropics/claude-code #42796
- The Register: Claude Code has become dumber, lazier: AMD director; Anthropic admits it dumbed down Claude when trying to make it better