Claude連續翻車45天，Anthropic坦白三個致命優化的真相！

ClaudeCode的'降智'風波揭示了AI產品優化的隱形陷阱。Anthropic的三項'善意'優化——降低推理強度、錯誤緩存清理、過度約束提示語——如何疊加出45天的性能災難？本文深度拆解技術細節與產品邏輯，揭示大模型時代'微調'與'崩潰'的臨界點。

如果你是一名外科醫生，手術進行到一半，突然發現手里的手術刀變鈍了——不是一下子變鈍，而是每天鈍一點點，直到某天你劃不開皮膚了。

你回頭去問刀具供應商，對方告訴你：”哦，我們覺得刀太鋒利會劃傷醫生的手，所以偷偷磨圓了一點。然后我們又覺得刀柄太重影響手感，就換了個輕的。最后我們發現刀身太長不好收納，就截短了兩厘米。每一步都是為你好。”

這就是過去45天里，Anthropic對ClaudeCode做的事。

“Claude變笨了”——這次不是錯覺

過去一段時間，”Claude變笨了”這五個字幾乎刷遍了所有開發者社區。

HackerNews上有人發帖吐槽，Reddit的編程板塊天天有人罵，X上更是怨聲載道。最開始大家還以為是自己的問題——是不是提示詞寫得不好？是不是工作流搞復雜了？甚至有人開始懷疑自己的編程水平退步了。

說實話，作為一個每天用ClaudeCode寫代碼的00后從業者，我自己也經歷過這種自我懷疑。今年3月中旬開始，我明顯感覺ClaudeCode的表現大不如前：以前一輪對話就能搞定的重構任務，現在要來回扯三四輪；以前寫出來的代碼干凈利落，現在動不動就給你生成一堆廢話注釋；更離譜的是，有時候前面剛討論過的上下文，下一輪它就完全忘了，像個得了健忘癥的實習生。

我一度以為是自己的使用方式出了問題，還專門花了一個周末重新學習了Anthropic的提示詞工程指南。

結果呢？4月23號，Anthropic的ClaudeCode研發團隊終于打破沉默，發了一篇名為《AnupdateonrecentClaudeCodequalityreports》的事后分析報告。

翻譯成大白話就是：用戶反饋的”降智”不是錯覺，是我們搞砸了。

具體來說，是三處看起來”為用戶好”的產品優化，引發了連鎖反應，讓全球最強編程模型之一在長達45天的時間里持續性能劣化。三個獨立的改動，分別從不同維度削弱了Claude的能力，最終疊加出了災難性的效果。

接下來，我會把這三個優化一個個拆開，告訴你它們各自是怎么回事、為什么會出問題、以及這件事對我們做AI產品的人意味著什么。

第一刀：砍掉”思考時間”換速度——用戶要的是快，但不是蠢

時間線：3月4日上線

先說第一個改動，也是最早的一個。

大模型有個特點：想得越久，答得越好。這不是玄學，而是推理類模型的基本原理。你給模型更多的”思考預算”（也就是允許它在內部進行更多輪的推理），它就能產出更高質量的結果。就像你考試的時候，給你3個小時和給你30分鐘，答題質量肯定不一樣。

ClaudeCode里有一個叫”推理強度”的參數，簡單理解就是控制模型”想多久”的旋鈕。這個旋鈕有幾個檔位：低、中、高、極高。之前默認是”高”。

然后問題來了。不少用戶吐槽說，Opus模型（Claude最強的版本）思考時間太長了，有時候UI都卡住不動。這個反饋確實是真的——我自己也遇到過，等模型思考的時候干看著屏幕轉圈，確實煩人。

團隊的應對方案是：把默認推理強度從”高”悄悄調到了”中”。

注意這個”悄悄”。他們沒有在更新日志里專門說明這個改動，也沒有彈窗告知用戶。在內部評估中，”中”等強度的表現看起來還行——速度明顯快了，智能損失”看起來不大”。

但實際使用中完全是另一回事。

這里要說一個我個人的深刻感受：大模型的”差一點點”和傳統軟件的”差一點點”，是兩個完全不同的概念。

傳統軟件，比如一個按鈕的響應時間從100毫秒變成150毫秒，用戶可能壓根感知不到。但大模型不一樣。模型從”高”降到”中”，表面上可能只是某個基準測試得分掉了兩三個百分點，但在真實的開發場景里，這兩三個百分點可能就是”寫出能用的代碼”和”寫出一坨需要你花20分鐘手動修的垃圾”之間的差距。

打個不太恰當的比方：一個棋手的等級分從2800掉到2750，對普通人來說都是”超級厲害”，但對跟他對弈的其他頂級棋手來說，差距是肉眼可見的。ClaudeCode的用戶恰恰就是這群”頂級棋手”——他們是專業開發者，對模型輸出質量的感知極其敏感。

上線之后，用戶的負面反饋開始涌入。團隊也做了一些補救措施，比如在啟動時彈提示讓用戶知道可以手動調高推理強度，增加了內聯的強度選擇器，甚至恢復了一個叫”ultrathink”的極高強度選項。

但問題是——大多數用戶根本不會去改默認設置。

這是產品設計的基本常識，我們做移動互聯網的人應該都懂：默認值就是產品經理替用戶做的決策，80%以上的用戶會直接接受默認值。你把默認值從”高”調到”中”，就等于替80%的用戶做了一個”犧牲智能換速度”的決定，而他們根本不知道發生了什么。

直到4月7日，團隊才把默認值改回”高”，并在新發布的Opus4.7上默認開啟”極高”模式。

這一刀，砍了34天。

第二刀：省成本的緩存清理變成了”記憶黑洞”——最隱蔽、傷害最大的一刀

時間線：3月26日上線

如果說第一刀是”讓Claude變笨了一點”，第二刀就是”讓Claude徹底失憶了”。

這個Bug的技術細節稍微復雜一些，但我盡量用大白話講清楚。

當你用ClaudeCode寫代碼的時候，每一輪對話，模型不僅會給你輸出結果，還會在后臺進行大量的”內部推理”——比如”用戶讓我重構這個函數，我之前看到這個函數調用了A模塊，A模塊有個已知的兼容性問題，所以我重構的時候要注意處理這個邊界情況”。

這些內部推理（也叫思維鏈）會被保留在對話歷史里。這樣，在后續的對話中，模型就能”記住”自己之前為什么做了某個決定。這是保持上下文連貫性的關鍵機制。

3月26日，團隊上線了一個優化：當會話空閑超過一小時，自動清除舊的內部推理內容，以節省Token成本并加快響應速度。

設計初衷聽起來很合理。你中午去吃了個飯，回來繼續工作，之前積累的大量內部推理確實會占用上下文窗口，清理掉一些能讓模型跑得更快更省錢。

但代碼寫出了一個致命Bug。

本來應該是”空閑超過一小時后，清理一次舊的推理內容”。結果實際上變成了”空閑超過一小時后，在后續的每一輪對話中都進行清理”。

你感受一下這個差別：

正確的行為：你離開了一小時，回來后，系統清理一次舊記錄，然后正常工作。

實際的行為：你離開了一小時，回來后，系統在你說的每一句話之后都把之前的記憶刪掉。

這意味著什么？意味著一旦觸發了這個Bug，ClaudeCode就只能記住最近一輪對話的內容。它徹底忘了自己之前為什么要修改代碼、之前看到了什么文件、之前做了什么決策。

在用戶看來，Claude突然開始重復同樣的話、給出前后矛盾的建議、反復問已經回答過的問題。就像一個每隔五分鐘就失憶一次的同事，你每次都得從頭跟他解釋一遍項目背景。

更坑的是，這個Bug還有一個”隱藏傷害”：由于每輪都在清理緩存，導致大量的緩存未命中。正常情況下，相似的對話上下文可以復用之前的緩存，省時省錢。但現在每輪都是”全新”的，相當于每句話都要重新從頭算起。

結果就是：用戶的使用額度被瘋狂消耗，明明沒干什么特別的事，流量卻像開了閘一樣往外涌。

這個Bug為什么拖了這么久才發現？Anthropic在報告里給出了解釋，讀起來讓人哭笑不得——

當時內部恰好有兩個互不相關的實驗在同時運行。一個是服務端的消息隊列實驗，另一個是思維鏈展示方式的改動。這兩個實驗的存在，恰好掩蓋了這個緩存清理Bug的癥狀。就像一個病人同時吃了三種藥，其中兩種藥的副作用恰好掩蓋了第三種藥的過敏反應，直到過敏嚴重到蓋不住了，醫生才發現問題。

最后，團隊用了超過一周的時間才定位到根本原因，并在4月10日修復。

這里還有一個挺有意思的細節：在調查過程中，團隊用最新的Opus4.7模型去審查出問題的那段代碼，Opus4.7成功發現了Bug。而之前的Opus4.6沒能發現。某種意義上，Anthropic是”用新版Claude修好了舊版Claude搞出來的爛攤子”。

這一刀，砍了15天。

第三刀：治啰嗦治出了”呆”——一句提示語砍掉3%的智能

時間線：4月16日上線

第三個問題出在系統提示語上。

Opus4.7這個版本比前代”話更多”——雖然在難題上表現更好，但輸出內容明顯更冗長。做過大模型產品的人應該都懂，啰嗦是大模型的通病，用戶對此的容忍度很低。

為了治這個毛病，團隊在系統提示語里加了一句約束：

“在工具調用之間的文本控制在25個詞以內。最終回復控制在100個詞以內，除非任務確實需要更多細節。”

這句話在內部測試了好幾周，在Anthropic自己跑的評測集上沒有發現性能下降，所以4月16日就跟著Opus4.7一起上線了。

但后來團隊做了更大規模的消融測試——簡單說就是一行行刪掉系統提示語，觀察每刪一行對模型表現的影響——發現這句約束導致了所有模型版本大約3%的性能下降。

3%聽起來不多，對吧？

但結合前面已經存在的兩個問題——推理強度降級導致的智能損失，加上緩存清理Bug導致的上下文丟失——這3%就成了壓垮駱駝的最后一根稻草。三個問題疊加在一起，用戶感受到的不是”3%+幾個百分點”的算術加法，而是一種系統性的、全方位的”這玩意兒不行了”的體感。

4月20日，團隊緊急撤銷了這條提示語。

這一刀，砍了4天。

但要注意，這4天恰好是Opus4.7剛發布、全球開發者蜂擁而至嘗鮮的窗口期。新用戶的第一印象就是”這個萬眾期待的最強模型，怎么這么拉胯？”

45天里發生了什么：三刀疊加的災難時間線

把三個問題放在一起看，時間線是這樣的：

3月4日到4月7日（34天），推理強度被偷偷降級，Claude全面變笨。

3月26日到4月10日（15天），緩存清理Bug讓Claude失憶，同時瘋狂消耗用戶額度。

4月16日到4月20日（4天），過度約束的提示語進一步壓縮了模型的表達和推理空間。

從3月4日到4月20日，這三把刀前后交叉，中間有12天（3月26日到4月7日）是兩把刀同時生效，還有4天（4月16日到4月20日）是跟最后一把刀疊加。

整個過程中，沒有任何一個改動是”惡意”的。每一個優化都有合理的出發點：加快速度、節省成本、減少啰嗦。

但最終的結果是：用戶感受到了一個持續45天的、不可逆轉的智能退化。

這讓我想起一個老笑話：一個人去理發，跟理發師說”幫我修一下就好”。理發師先修了一下左邊，覺得不對稱；又修了一下右邊，還是不對稱；再修左邊……最后理成了光頭。

每一步都是”微調”，每一步都有道理，但最終的累積效果是毀滅性的。

用戶不買賬：遲到的真相比Bug更傷人

Anthropic在4月23日發布了這篇事后分析報告，同時宣布重置所有訂閱用戶的使用限額作為補償。

按理說，主動承認問題、公開技術細節、給出補償措施，這在行業里已經算是比較有誠意的做法了。但開發者社區的反應是——罵得更兇了。

為什么？因為有三個讓人咽不下去的點：

第一，”重置限額”的補償太敷衍。

有用戶在X上貼出截圖：自己每月付幾百美元的高級訂閱，過去幾周因為緩存Bug導致額度被瘋狂消耗，而Anthropic的補償就是重置當期限額。更諷刺的是，有人發現重置時間總是卡在限額快到期前幾小時，相當于你的月卡還剩最后一天的時候，人家大方地說”給你續一天”。

有人算了一筆賬：過去一年為Anthropic付了大約2400美元的訂閱費，結果因為官方自己的Bug導致體驗崩塌，補償就是一個不痛不癢的限額重置。這種”補償”的誠意，說實話很難讓人感受到。

第二，發布時間太”巧”了。

這篇事后分析報告發布的當天，恰好是OpenAI發布GPT-5.5的日子。在AI圈，這種”撞車”操作很難不引發聯想。有人直接質疑：你們是在趁大家都關注GPT-5.5的時候偷偷放出壞消息，分散注意力吧？

當然，也有可能真的是巧合。但在信任已經搖搖欲墜的時候，任何”巧合”都會被解讀為”算計”。

第三，事前的溝通姿態讓人心寒。

在正式承認問題之前的這45天里，社區一直在反饋”Claude變笨了”。Anthropic的官方口徑始終是”模型沒有退化”。

你想想這種感受：你花大價錢買了一個工具，用著用著發現不好使了，去找廠商反饋，廠商說”你搞錯了，我們沒問題”。你懷疑了一個半月，最后廠商告訴你”哦，確實是我們的問題”。

有用戶在X上的發言讓我印象很深，大意是：你讓我懷疑了自己整整兩周，我以為是自己的提示詞寫得爛、工作流設計得差，甚至開始懷疑自己的能力。結果問題出在你們身上？然后一個限額重置就想打發我？

最扎心的是，已經有用戶開始用腳投票了。有人表示切換到OpenAI的Codex之后體驗非常好，正在考慮徹底更換工具鏈。要知道，讓一個重度用戶放棄已經深度集成的工具是非常難的，一旦他們真的走了，再拉回來的成本是初次獲取的5到10倍。

為什么內部沒人發現？——每個做AI產品的人都該反思的問題

這件事最讓我震驚的不是Bug本身——哪個軟件沒Bug呢？讓我震驚的是：這些Bug在內部居然都沒被發現。

Anthropic在報告里給出了一些解釋：

緩存Bug因為兩個內部實驗的干擾而難以復現

推理強度的降級在內部評測集上”看起來影響不大”

提示語約束在自家評測集上沒有觸發性能下降

但抽絲剝繭來看，根本原因只有一個：內部開發者用的不是公開發行版。

Anthropic的內部員工用的是帶有各種實驗特性的內部版本，而不是普通用戶安裝的公開版本。這意味著他們感受到的產品和用戶感受到的產品，從一開始就不是同一個東西。

這個問題在軟件行業有一個經典的名字，叫”dogfooding”——吃自己的狗糧。意思是你自己團隊得用自己的產品，才能真正理解用戶的痛點。

Anthropic在報告里也承認了這個問題，表示未來會推動更多內部員工使用公開發行版。但說實話，這種承諾在行業里聽得太多了。

作為一個做了幾年AI產品的人，我想分享一個自己的切身經驗：我們團隊之前做一個基于大模型的文檔處理工具，內部Demo效果非常好，大家都覺得沒問題。結果上線第一天就被用戶罵慘了——因為我們測試的文檔都是格式規范的PDF，而真實用戶丟進來的是歪歪扭扭的手機拍照截圖、掃描件、甚至還有人把PPT截圖拼成了一個Word文檔。

評測集和真實世界之間的鴻溝，永遠比你想象的大。

Anthropic的改進方案：方向對了，但夠不夠？

在報告的最后，Anthropic列出了三項改進措施。我逐一說說我的看法：

改進一：強制內部員工使用公開發行版。

方向完全正確。但執行難度比說起來大得多。內部員工需要測試新功能，不可能百分百用公開版。關鍵是要在”內部測試版”和”公開版”之間建立一個制度化的輪換機制——比如每個月至少有一周必須只用公開版，而且要求寫使用報告。

光有意愿不夠，得有流程保障。

改進二：對系統提示語的每一行修改進行消融測試。

這是這次事件里最有價值的技術教訓。消融測試就是逐行刪除提示語，觀察每刪一行對模型輸出的影響。聽起來簡單，但實際工作量巨大——一個復雜的系統提示可能有幾十上百行，每一行都要跑一輪完整的評測。

但這個投入是值得的。因為這次事件證明了：對大模型來說，系統提示語里的每一個字都可能產生蝴蝶效應。你以為無關緊要的一句約束，可能在某些場景下引發嚴重的性能退化。

改進三：對任何可能犧牲智能的改動，增加”浸泡期”和漸進式上線。

也是對的方向。傳統軟件的灰度發布大家都熟——先放1%的用戶，觀察數據，沒問題再逐步擴大。大模型產品更需要這種機制，因為評測集永遠覆蓋不了真實使用場景的復雜度。

但浸泡期多長合適？灰度比例怎么定？這些細節Anthropic沒有在報告里說清楚，我覺得后續需要更具體的方案。

此外，Anthropic還在X上開了一個@ClaudeDevs的官方賬號，用來跟開發者社區溝通產品決策。這一步走得不錯，但能不能堅持做下去、做到什么程度，還需要時間驗證。

對我們做AI產品的人意味著什么？——五條實操方法論

作為一個親身經歷了這場風波的從業者，我覺得這件事的教訓遠不止”Anthropic犯了錯”這么簡單。這里面有很多通用的方法論，適用于每一個做大模型產品的團隊。

我總結了五條：

第一條：永遠不要偷偷改默認值。

這是最基本、也是最容易被忽視的產品原則。用戶選擇你的產品，是基于他當前感知到的體驗。你在后臺偷偷把推理強度從”高”改成”中”，就相當于咖啡店偷偷把美式的濃縮從兩份減到了一份半——你覺得差別不大，但天天喝的老客戶一口就能喝出來。

如果你必須改默認值，至少做到兩件事：一是在更新日志里明確說明，二是給用戶提供一鍵恢復舊默認值的選項。

第二條：大模型產品的”性能-成本-體驗”三角，不能用傳統軟件的思路來平衡。

傳統軟件的性能優化通常是帕累托改進——你優化了數據庫查詢速度，用戶體驗變好，服務器成本也降低，皆大歡喜。

但大模型不一樣。在大模型里，速度、成本和智能之間往往是零和博弈。你想讓模型更快，就得犧牲思考深度；你想省Token，就可能損失上下文連貫性；你想讓輸出更簡潔，就可能壓縮掉關鍵的推理過程。

所以，在做任何涉及這三個維度的優化時，必須回答一個靈魂拷問：如果這個優化只能讓10%的用戶高興，卻讓50%的用戶體驗變差，你還做不做？

答案通常是不做——或者至少做成可選項，而不是改默認值。

第三條：評測集永遠不夠用，真實用戶測試不可替代。

Anthropic的三個優化在內部評測集上都”看起來沒問題”。但真實環境中，它們都出了問題。

這給我們的教訓是：不要迷信評測集。再全面的評測集也只是真實使用場景的一個子集，而且是一個被精心策劃過的子集。真實用戶會做的事情遠比你想象的多樣、混亂和不可預測。

我的建議是：對于任何可能影響模型核心能力的改動，除了跑評測集，必須做”真實場景壓力測試”——找10到20個重度用戶，讓他們在真實工作中使用改動后的版本至少一周，收集定性反饋。這比跑一萬條評測用例都管用。

第四條：緩存和上下文管理是大模型產品的”命門”，改動需要最高等級的代碼審查。

ClaudeCode的緩存清理Bug，本質上是一個”看起來簡單、實際上極其復雜”的上下文管理問題。這類問題在所有大模型產品中都是高發區域。

我見過太多大模型產品在上下文管理上踩坑：對話歷史莫名其妙被截斷、長文檔處理到一半”忘了”前半部分、多輪對話中前后矛盾……

如果你在做大模型產品，我的建議是把所有跟”上下文””記憶””緩存”相關的代碼模塊標記為”核心紅區”——任何改動都需要至少兩個高級工程師交叉審查，而且必須在各種邊緣場景下測試（比如會話空閑1小時、5小時、24小時后恢復的情況）。

另外你也可以關注一下LangGraph和MemGPT這類專門做大模型記憶管理的開源框架，它們在上下文持久化和分層記憶方面已經有了不少成熟的解決方案，值得參考借鑒。

第五條：出了問題，第一時間跟用戶坦誠溝通，不要等到”最佳時機”。

Anthropic這次最大的公關失誤，不是Bug本身，而是在社區反饋了45天之后才公開承認問題。而且偏偏選在競爭對手發布新產品的當天發布報告，更是給自己的誠意打了折扣。

在AI行業，用戶對模型的信任極其脆弱。這些用戶不是普通消費者，他們是把你的模型深度集成到自己工作流里的開發者，他們的生產力和收入直接依賴你的產品穩定性。

當你知道產品出了問題時，最好的溝通時機永遠是”現在”——哪怕你還沒完全查清原因。你可以說”我們注意到了問題，正在調查，初步排查方向是什么什么，預計什么時候給更新”。這比沉默45天后突然扔出一份”完美報告”強一百倍。

寫在最后：技術領先只是入場券

有一個問題我一直在想：如果Claude不是”全球最強編程模型之一”，這件事還會引發這么大的風波嗎？

答案大概率是不會。

正是因為ClaudeCode代表了編程輔助工具的天花板，用戶對它的期望也被拉到了最高。當這個天花板突然塌了一塊下來，砸到的恰好是最忠誠、付費最多、依賴最深的核心用戶——他們的反應當然最激烈。

這件事揭示了一個我覺得很多AI從業者還沒有意識到的殘酷現實：在大模型競爭進入白熱化的今天，技術能力的領先周期越來越短。今天你是最強的，三個月后別人就可能追上來。

真正的護城河不是跑分第一，而是你能不能在產品出問題的時候不丟掉用戶的信任。

OpenAI有過類似的教訓（還記得GPT-4的”變懶”事件嗎），Google的Gemini也踩過坑。行業里沒有任何一家公司能保證模型永遠穩定。

但用戶能接受的是”你告訴我出了什么問題、怎么修的、以后怎么避免”。用戶不能接受的是”你偷偷改了東西、否認有問題、然后在我快要放棄你的時候才承認”。

對于我們這些做AI產品的人來說，這件事給的最大教訓其實只有一句話：

你可以犯技術的錯，但不能犯溝通的錯。Bug可以修，信任修不了。