English

摘要 · 事件概述

工程事後報告 · 綜覽Anthropic Engineering Blog · 04-23

解決版本 v2.1.116 · API 本身未受影響

三項互不相關的變更，看起來像同一次品質下降

預設推理強度被調低、一個快取 Bug 持續清除推理歷史、系統提示詞加入輸出長度限制——三件事影響不同流量區段、時間也不同步，合起來卻呈現為廣泛而不一致的品質下降。這正是它們花了數週才被逐一定位的原因。受影響的是 Claude Code、Agent SDK 與 Cowork；API 本身未受影響。

  • 3獨立問題，全部於 4 月 20 日修復
  • 34 天問題一持續時間，最長的一項
  • −3%問題三造成的評測分數下降
  • v2.1.116三項問題全數解決的版本
問題期間內容
問題一03-04 – 04-07預設推理強度由 high 調降為 medium，用戶反映「感覺變笨了」
問題二03-26 – 04-10快取 Bug 持續清除推理歷史，閒置後每輪只保留最近一個 thinking block
問題三04-16 – 04-20系統提示詞限制輸出長度（≤25／100 words），評測分數下降約 3%

起 · 問題一與二 · 內容 1 / 3

問題一：預設推理強度被調低 持續 34 天 · Sonnet / Opus 4.6

起因：部分用戶反映 high 模式等待時間過長，UI 看起來像是凍結。內部評測顯示 medium 僅略降智能卻顯著降低延遲，因此在 3 月 4 日把預設值由 high 改為 medium。
後果：用戶立即反映「Claude Code 感覺變笨了」。Anthropic 多次調整 UI（啟動通知、inline effort 選擇器、重新引入 ultrathink），但大多數用戶仍維持 medium 預設值——這正是預設值的力量，也是這次變更真正的代價。

  • 4 月 7 日撤回預設值恢復至 high；Opus 4.7 更提升至 xhigh。
  • 手動調整用戶可透過 inline effort 選擇器自行變更推理強度。

問題二：快取優化 Bug 持續 15 天 · 修復於 v2.1.101

設計意圖：閒置超過一小時後，清除舊的 thinking blocks（clear_thinking_20251015 + keep:1），以減少恢復 session 的 token 成本。
Bug 內容：原本只應執行一次的清除動作，在之後每一輪對話中持續執行。一旦 session 曾閒置超過一小時，每輪新請求就只保留最近一個 thinking block，其餘全部丟棄。
現象：Claude 越來越不記得自己為何做出特定選擇——健忘、重複執行、奇怪的工具選擇。

問題二為何難以發現 掩蓋因素與發現契機

  • 兩個不相關的實驗（訊息佇列與 thinking 顯示修改）掩蓋了此 Bug，使它在大多數 CLI session 中無法重現。
  • Bug 牽涉 context management × Anthropic API × extended thinking 三層交叉，通過了人工審查、unit tests 與端對端測試仍未被發現。
  • 持續清除 thinking blocks 導致快取命中率下降，被誤認為是使用量消耗異常加快的原因。
  • 最終是以 Opus 4.7 對問題 PR 進行 Code Review 時找到的（Opus 4.6 未能找到）。
  • Anthropic 因此決定為 Code Review 工具加入更多 repository 作為上下文。

轉 · 問題三與根因 · 內容 2 / 3

問題三：系統提示詞限制輸出 上線 4 天 · 影響三個模型

起因：Opus 4.7 輸出較冗長，雖使困難問題表現更好，但消耗更多 tokens。為此在系統提示詞中加入：「Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.」
後果：多週內部測試未發現問題，但更廣泛的 ablation 分析顯示，此規則使 Opus 4.6 與 Opus 4.7 的評測分數下降約 3%，對程式碼品質有顯著負面影響。受影響的是 Sonnet 4.6、Opus 4.6、Opus 4.7 三個模型——而該提示詞只為 Opus 4.7 的特性而設計。

根因分析：為何難以定位 四個彼此無關的干擾

  • 三項變更影響的流量區段各不相同、時間也不同步，整體看起來像是廣泛且不一致的品質下降。
  • 初期難以與正常的用戶反饋波動區分；內部使用量與評測最初均未能重現問題。
  • 系統提示詞變更僅針對 Opus 4.7 特性設計，卻意外影響所有模型，且多週測試未發現 regression。
  • 快取 Bug 的觸發條件（閒置超過 1 小時）使其在大多數開發測試情境中無法重現。

合 · 改善措施與時間軸 · 內容 3 / 3

防止再犯的行動 五項後續措施

  • 確保更大比例的內部員工使用與公開版本完全相同的 Claude Code 建置，而非測試版。
  • 每次系統提示詞變更必須針對每個模型執行完整 eval suite，並持續進行 ablation 分析。
  • 建立新工具使提示詞變更更易於審查與稽核；在 CLAUDE.md 加入模型專屬修改指引。
  • 對任何可能影響智能的變更加入浸泡期（soak period）、更廣泛的 eval 套件及漸進式推出。
  • 創立 @ClaudeDevs（X）帳號與 GitHub 集中討論串，說明產品決策與背後邏輯。

事件時間軸 三條線交錯

  1. 02Opus 4.6 上線，預設 high 推理強度。
  2. 03-04預設推理強度改為 medium（問題一開始）。
  3. 03-26快取優化 Bug 上線（問題二開始）。
  4. 04-07問題一修復，預設恢復 high；Opus 4.7 為 xhigh。
  5. 04-10問題二修復（v2.1.101）。
  6. 04-16系統提示詞冗長限制上線（問題三開始）。
  7. 04-20問題三修復，三項問題全數解決（v2.1.116）。
  8. 04-23發布事後報告；重置所有訂閱用戶的使用量上限。

這份報告真正的教訓

三項變更各自都通過了自己的審查。失敗發生在它們之間——沒有任何一道流程負責看「同時在線的多項變更合起來會如何」。後續措施中最實質的一條，也正是把測試從單一變更擴展到每個模型的完整 eval 與浸泡期。