Anthropic 發布了一份詳細的工程復盤,解釋 Claude Code 從 3 月到 4 月中旬持續了六週的品質投訴。三個互不相關的產品層改動分別在 3 月 4 日到 4 月 16 日之間上線,每個按各自的時間表影響著不同的流量切片——這就是為什麼使用者報告的症狀根據他們何時使用 Claude Code 以及依賴哪些功能,差異如此巨大。關鍵的一點是:API 和底層模型權重都沒有受影響。三個問題在 4 月 20 日發布的 Claude Code v2.1.116 中全部解決,Anthropic 也已為所有訂閱使用者重置使用上限。這次誠實的揭露是它與「我們正在改進產品」那種常見公關稿區分開來的地方:具體日期、具體 commit、具體品質數字、Claude Code 團隊的可追責歸屬。
三個改動可以乾淨地拆開。第一,3 月 4 日,預設推理預算從 high 改到 medium,目的是修復長時間思考期間 UI 卡頓的問題——Anthropic 承認這是「錯誤的權衡」,並於 4 月 7 日回滾。現在所有模型預設 high 或 xhigh。第二,3 月 26 日的一項最佳化,本是為了把已經閒置 1 小時以上的會話裡的舊思考片段清掉(反正閒置那麼久之後下次必然是完整 cache miss),卻帶了個 bug:本應只清一次,變成每一輪都清。Claude 仍然在執行,只是越來越沒有「為什麼走到當前路徑」的記憶。Boris Cherny 在 Hacker News 上點出極端情況:一個上下文裡有 90 萬 token、閒置一小時的使用者,下一條訊息會撞到完整 cache miss,消耗掉相當可觀比例的 rate limit——對 Pro 使用者尤其明顯。4 月 10 日修復。第三,4 月 16 日伴隨 Opus 4.7 上線,Anthropic 給 system prompt 加了 verbosity 限制,指示模型「工具呼叫之間的文本不超過 25 詞」以及「最終回覆不超過 100 詞」。內部測試沒發現回歸。事後的更廣泛 ablation 揭示:Opus 4.6 和 4.7 都因此出現 3% 的品質下降。4 月 20 日回滾。一個有意思的 meta finding:Anthropic 自家的 Code Review 工具被回測了那幾個引發問題的 PR——給足夠的儲存庫上下文,Opus 4.7 找出了那個 cache bug,Opus 4.6 沒找出來。
社群批評值得和復盤放在一起權衡。Hacker News 上有評論質疑:idle 會話剪枝的真正動機到底是降延遲,還是降成本而拿延遲做幌子。還有幾條 flag 指出:用舊 system prompt 跑過的 benchmark 還掛著,新 system prompt 悄悄上線沒揭露——「感覺像是欺詐」。Fortune 報導一些使用者因 Anthropic 最初的「什麼事都沒有」式回覆而感到「被 gaslight」。Anthropic 回應 Fortune 時用了一句「算力是整個業界的約束」,同時配上擴容合作夥伴的話術。復盤沒回應、但值得繼續追蹤的兩個問題:Reddit 使用者報告 Claude Code 把任務委派給更便宜的 Haiku 模型的頻率比預期高得多——這只在 verbose 日誌裡可見——對自動化 pipeline 來說,這是一種沉默的品質風險類別,在互動式使用裡就比較明顯。至少有一位 Reddit 使用者獨立確認:即使官方 4 月 20 日宣布回滾 verbosity 指令,這些指令在 system prompt 裡仍然留著;他寫了一個 pre-tool hook 腳本,針對五個具體失敗模式(跳過原文重讀、自信但與源不一致的輸出等)做對沖。這個由使用者自己 build 的 workaround 能改善輸出品質,本身就反過來印證了復盤對 verbosity 限制「降低品質」的診斷。
對生產環境跑 Claude Code 的 builder:canonical 修復版本是 v2.1.116。如果你在 3-4 月間跑過 CI 或自動化工作流,審一下輸出有沒有三個改動的指紋——尤其是長 idle 會話(cache bug),以及 4 月 16-20 日左右的輸出(verbosity prompt)。對一般在做 LLM-backed 產品的 builder,直接可借用的工程教訓:內部評測之所以一個問題也沒抓到,是因為內部員工用的是和公開發布版不同的 build,cache bug 只在特定狀態(過期 idle 會話)下顯現、而那個狀態在 eval 裡沒被覆蓋,且評測套件本身太窄,抓不到 system prompt 改動帶來的 3% 品質下降。Anthropic 表態要做的事——讓內部員工用一模一樣的公開 build、給每一次 system prompt 變更都跑更寬的 per-model 評測套件、加入 soak 期和分階段 rollout、對 system prompt 變更做細緻版本管理——是合理的業界基線。「算力是約束」那句承認也很關鍵:如果 Anthropic 正在做能可見地降低品質的成本/延遲權衡,那同一套邏輯對每個 vendor 都成立,產品採購團隊應該在 vendor SLA 裡明確問「延遲-vs-品質」的取捨是怎麼決定的。