Claude變笨，Anthropic發報告認了：為優化3個Harness層bug，不小心改崩了

作者｜冬梅

“Claude 變笨了。”

1 Anthropic 正面回應模型“變笨”：三處優化導致的

過去一段時間，這個聲音在 Hacker News、Reddit 以及 X 上此起彼伏。尤其是在萬眾矚目的 Opus 4.7 發布后，不少老用戶反饋 Claude Code 變得健忘、重復且廢話連篇。

作為目前全球最強梯隊的編程模型，Claude 的口碑滑坡讓 Anthropic 壓力倍增。

所以今天一早，Claude Code 研發團隊打破沉默，發布了一篇看起來誠意十足的分析文章，名為《An update on recent Claude Code quality reports》，他們在文章中坦言，用戶反饋的“降智”并非錯覺，而是源于三處看似合理、實則導致連鎖反應的產品優化。

沒錯，Claude Code 真的“變笨”了。

研發團隊表示，目前 Anthropic 已修復全部漏洞，并宣布重置所有訂閱用戶的使用限額以示誠意。

截至 4 月 20 日（版本 v2.1.116），這三個問題均已修復。在這篇文章中，他們詳細闡述了發現了什么、修復了什么，以及今后將如何改進，避免類似問題再次發生。

2 三處優化細節詳述

事件的起因，源于產品團隊對“用戶體驗”的過度優化。經過調查，Claude Code 團隊找出了三個不同的問題：

第一個優化發生在 3 月 4 日。通常來說，模型思考時間越長，輸出效果越好。當時，不少用戶吐槽 Opus 模型思考時間太長，甚至導致 UI 卡死。為了縮短延遲、節省 Token，團隊私自將默認推理強度（Reasoning Effort）從“高”降到了“中”。

在產品層面，團隊再從中選一個點作為默認值，并通過 Messages API 的 effort 參數傳遞該值；同時，團隊還將其他可選強度通過 /effort 命令提供給用戶。

內部評估認為，“中”等強度能以極小的智能損失換取顯著的速度提升。然而，真實環境中的開發者并不買賬，上線后不久，就有用戶反映 Claude Code 感覺變笨了。對 AI 而言，“多思考一秒鐘”往往意味著從“生成垃圾代碼”到“產出優雅重構”的跨越。

在聽取更多客戶的反饋后，團隊做了多次設計迭代，讓當前的推理強度設置更清晰，以便提醒用戶可以更改默認值（例如啟動時彈出提示、增加內聯的強度選擇器、恢復“ultrathink”選項），但大多數用戶仍然保留了“中”等推理強度默認值。

4 月 7 日，團隊在意識到這種取舍邏輯的錯誤后，將默認強度重新調回了“高”，并在 Opus 4.7 上默認開啟了“極高”模式。此問題影響的模型是 Sonnet 4.6 和 Opus 4.6。

第二個優化發生在 3 月 26 日。當 Claude 執行一項任務并進行推理時，這些推理內容通常會被保留在對話歷史中。這樣，在后續的每一輪交互中，Claude 都能了解自己之前為何做出某些編輯和工具調用。

3 月 26 日，團隊針對這一功能上線了一項本意是提高效率的優化，有點類似于“自動清理歷史思考內容”的功能。他們利用提示緩存（prompt caching）來降低用戶連續 API 調用的成本并加快速度。Claude 在發起 API 請求時將輸入 token 寫入緩存；如果一段時間沒有活動，該提示就會被從緩存中逐出，為其他提示騰出空間。

原本的設計應該很簡單：如果會話空閑超過一小時，系統會剪除舊的推理信息以節省成本。為此，團隊使用了 clear_thinking_20251015 這個 API 頭部，并配合 keep:1 參數。

但代碼中隱藏的一個漏洞：它并沒有只清除一次思考歷史，而是在會話后續的每一輪中都進行清除。一旦跨過空閑閾值，后續每一輪對話都會觸發清理。這意味著 Claude 只能記住最近的一句對話，它徹底忘記了自己當初為什么要修改代碼。在用戶眼中，Claude 開始重復啰嗦、胡言亂語。這種“健忘”不僅損害了智能，還因為頻繁的緩存未命中（Cache Miss）導致用戶的使用額度被光速消耗。

據悉，該漏洞的發現過程較為曲折，由于 Anthropic 內部兩個互不相關的實驗干擾，導致漏洞難以復現——一個是僅用于服務端、涉及消息隊列的內部實驗，另一個是在思考內容展示方式上的正交改動，該改動在大多數 CLI 會話中掩蓋了漏洞，使得外部構建測試時未能發現問題。

此外，該漏洞處于 Claude Code 的上下文管理、Anthropic API 和擴展推理三個模塊的交匯點，相關變更已通過多輪人工和自動化代碼審查、單元測試、端到端測試、自動化驗證及內部試用，且僅在陳舊會話這一邊緣情況下出現，因此 Anthropic 花費超過一周時間才找到并確認其根本原因。

值得注意的是，在調查過程中，團隊使用 Opus 4.7 對有問題的拉取請求進行了反向的“代碼審查”測試。當提供了獲取完整上下文所必需的代碼倉庫后，Opus 4.7 發現了該漏洞，而 Opus 4.6 未能做到。

為防范此類問題再次發生，Anthropic 目前正增加對更多代碼倉庫作為代碼審查上下文的支持，該漏洞也已經在 4 月 10 日 v2.1.101 版本中修復好了。此問題影響的模型是 Sonnet 4.6 和 Opus 4.6。

第三個優化發生在 4 月 16 日。Anthropic 曾為降低 Claude Opus 4.7 版本的冗長程度，修改了系統提示語。據悉，Claude Opus 4.7 相較于前代，明顯更加“啰嗦”，雖能在困難問題上表現更出色，但會生成更多輸出 token。

在該版本發布前幾周，Anthropic 便開始對 Claude Code 進行調整，綜合運用模型訓練、提示語優化、思考體驗改進等多種方式降低冗長程度，其中新增的一條系統提示語——“長度限制：在工具調用之間的文本控制在 25 個單詞以內。最終回復控制在 100 個單詞以內，除非任務確實需要更多細節”，對 Claude Code 的智能產生了過大影響。

該提示語經過數周內部測試，在 Anthropic 運行的評估集上未出現性能退化，因此于 4 月 16 日隨 Opus 4.7 版本一同上線。

但在后續調查過程中，Anthropic 通過更廣泛的評估集開展更多消融測試（即從系統提示中逐行刪除以理解每行影響），發現 Opus 4.6 和 4.7 版本均出現 3% 的性能下降。

為此，Anthropic 在 4 月 20 日的發布中，立即撤銷了該條系統提示語。該優化受影響的模型包括 Sonnet 4.6、Opus 4.6 和 Opus 4.7。

3 未來如何改進？

為了避免再次出現這些問題，Claude Code 團隊表示將從下面三個方面進行改進：

首先，是內部全員強制使用公共構建版，確保開發者與用戶“同頻感同身受”。

Claude Code 團隊將推動內部使用版本的統一，確保更大比例的內部員工使用 Claude Code 的精確公共構建版本，而非用于測試新功能的內部版本，以此更貼近普通用戶的實際使用場景，提前發現潛在問題。同時，團隊將對內部使用的代碼審查工具進行改進，并計劃將優化后的代碼審查工具同步提供給客戶，助力客戶提升使用體驗。

其次，是引入更嚴苛的提示語審計工具，對系統提示語的每一行修改進行持續的消融測試。

在系統提示語管理方面，Claude Code 團隊將增加更嚴格的控制措施。對于每一次系統提示語的更改，團隊都會針對每個模型運行廣泛評估，持續開展消融測試以明確每一行提示語的具體影響；同時，已構建新的工具，讓提示語的修改更易于審查和審計。

第三，是增加“浸泡期”，對于任何可能犧牲智能換取性能的改動，采取逐步上線的流程。

團隊已在自身的 CLAUDE.md 文件中新增指導原則，確保針對特定模型的更改僅限定在該模型范圍內，避免跨模型影響。對于任何可能犧牲智能換取其他收益的改動，團隊將增加“浸泡期”，擴大評估集范圍，并采用逐步上線的流程，以便更早發現并規避問題。

在用戶溝通與反饋渠道方面，Claude Code 團隊近期已在 X（原 Twitter）平臺創建 @ClaudeDevs 賬號，用于深入解釋產品決策及其背后的原理，同時會在 GitHub 的集中討論帖中同步相關更新，提升產品決策的透明度。

4 分析報告沒有讓用戶滿意

當 Anthropic 試圖用一份詳盡的技術報告挽回 Claude 的口碑時，它可能低估了開發者積壓已久的怒火。

在官方承認由于“推理強度下調”、“緩存漏洞”和“提示語冗長控制”導致 Claude 性能大幅下滑后，社交媒體上的評論呈現出一邊倒的抨擊。

對于眾多支付高額訂閱費的專業開發者來說，這份遲到的“真相”不僅沒能平息焦慮，反而因補償方案的敷衍和官宣時機的微妙被質疑在“作秀”。

在 X 上，一位網友反饋稱，即使在重置后，流量消耗速度依然驚人：“我用了 5 個小時，x20 的套餐就燒掉了 64% 的流量，而我什么特別的事都沒做。情況正在變得越來越糟。”

還有 X 用戶憤怒地表示：“這簡直是胡說八道！過去兩周，我一直在反思是不是自己的提示詞或工作流程出了問題，甚至懷疑過自己都沒懷疑過 Claude，結果發現是你們的漏洞吞噬了我的歷史記錄。把重置當作道歉？這才是真正侮辱人的地方。”

該用戶還表示：“過去一年我為 Anthropic Max 支付了約 2400 美元，為 OpenAI 支付了 0 美元。過去 48 小時我切換到 OpenAI 的Codex感覺真的非常棒，我正嚴肅考慮徹底更換系統。失去最忠實用戶的方式，不是因為模型出 Bug，而是因為糟糕的道歉。”

另一位網友則精準補刀：“你們總是在每周限額到期前兩小時宣布‘重置’，這根本不叫重置，這叫敷衍。”

最令社區玩味的是本次公告發布的時間點——恰逢 OpenAI 發布GPT-5.5的當天。有部分 X 用戶認為，這樣的做法是在分散人們對于 GPT 5.5 發布的關注。

有 X 用戶質疑道：“幾個月來你們一直堅稱‘模型沒有退化’，現在卻在 GPT-5.5 發布的當天突然官宣漏洞分析，這很難不讓人懷疑是在轉移注意力。更諷刺的是，你們聲稱‘用 Claude 開發 Claude’，結果長達 15 天的嚴重漏洞竟然在內部完全沒被發現？”

這場風波正在引發連鎖反應：核心用戶的忠誠度降至冰點。也讓一部分人從 Anthropic 轉向了 OpenAI。

對于 Anthropic 而言，這次危機揭示了一個殘酷的現實：在大模型競爭進入白熱化的今天，技術領先只是入場券，透明度與對用戶時間的尊重才是留住開發者的護城河。

https://x.com/ClaudeDevs/status/2047371123185287223

https://www.anthropic.com/engineering/april-23-postmortem

聲明：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

世界模型的下一個突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？

AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態智能突破、Agent 架構與工程化實踐、Agent 安全與可信治理、企業級研發體系重構。14 個專題全面開放征稿。

誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。