“Claude Code更新廢了”！思考深度降67%，無法勝任復雜工程任務

西風 發自 凹非寺
量子位 | 公眾號 QbitAI

在官方倉庫貼臉開大，熱議Issue指出：Claude Code已經更新“廢了”。

某次更新讓思考深度下降67%，當前版本已無法勝任復雜工程任務。

“無視用戶指令”“執行與用戶要求完全相反的操作”“假裝說任務已完成”……模型行為全面走樣。

思維鏈從2200字符（chars）砍到不足700，直接從“先研究再改代碼”的嚴謹模式，變成了“上來就改”的莽撞模式。

這也是各種Bug、反向操作、無視指令的根源。

關鍵在于，能力退化的時間線可追溯到2月份，和新功能redact-thinking-2026-02-12（思考內容隱藏功能）的上線時間完全吻合。

換句話說，Claude Code這把是更新廢了。

社區內一片吐槽的聲音，網友表示曾懷疑過是自己操作錯了，也沒想過是工具出現了問題。

最近總跟我說“你該去睡覺了”“太晚了，今天就到這吧”這類話，一開始我還以為，是我不小心讓Claude知道了我的ddl。

思考被砍后，Claude Code的各種擺爛行為

提交這份反饋的是AMD負責開源AI軟件開發相關工作的Stella Laurenzo。

所有分析基于~/.claude/projects/目錄下4個項目（iree-loom、iree-amdgpu、iree-remoting、bureau）的6852個Claude Code會話JSONL文件，覆蓋17871個思考塊（其中7146個包含完整內容，10725個已被隱藏）、234760次工具調用、18000+條用戶提示詞（涵蓋負面情緒指標、糾錯頻率、會話時長），時間跨度從2026年1月底到4月初。

測試全程使用Claude系列性能最強的Opus模型，通過Anthropic官方API直連，排除第三方適配、客戶端故障等干擾。

報告對7146組有效數據的皮爾遜相關分析（系數高達0.971），證明了signature字段可精準估算思考深度。

首先，報告指出思考隱藏功能的上線時間，與Claude Code質量退化時間完全吻合。

以下是基于對話JSONL文件中思考塊的分析結果：

有用戶在3月8日反饋過質量退化問題——這一天恰好是隱藏思考塊占比突破50%的時間節點。

該功能一周內的上線節奏（1.5%→25%→58%→100%），完全符合分階段灰度部署的特征。

其實Claude Code的思考深度在該隱藏功能上線前就已經大幅下降了。

對比不同時間段的數據可知，1月30日至2月8日其思考深度約為2200字符，到2月下旬就暴跌至720字符，降幅達67%；3月上旬更是進一步縮水至560字符，下降75%。

3月初上線的隱藏功能，只是讓這一退化對用戶變得不可見。

思考深度的大幅削減，直接引發了模型工具使用模式的根本性轉變。

在1月30日至2月12日的“優質期”，Claude Code修改代碼，讀改比能達到6.6，工作流遵循“先研究再修改”（先讀取目標文件、相關依賴文件，檢索代碼庫全局調用關系，查閱頭文件與測試用例，再開展精準修改）。

而到了3月8日之后的“退化期”，讀改比驟降至2.0，模型的研究投入減少70%，直接跳過前期調研步驟，僅讀取當前文件就倉促修改，完全忽略上下文關聯。

更詳細的數據顯示，退化期內，每3次修改中就有1次，是模型在未讀取目標文件上下文的情況下直接進行的操作。

當模型修改未讀取的文件時，根本無法區分注釋塊的結束位置和代碼的起始位置，會把新聲明插入文檔注釋和其所描述的函數之間，徹底破壞語義關聯。

而這種情況在優質期從未發生。

這種模式轉變帶來的負面影響，體現在多個可量化的質量指標上。

3月8日之前，用于識別推諉責任、提前終止等不良行為的終止鉤子腳本從未觸發；但3月8日后的17天內，觸發次數飆升至173次，平均每天10次。

這些指標均基于18000+條用戶提示詞獨立計算得出。

用戶提示詞中的負面情緒占比從5.8%升至9.8%，漲幅68%；需糾正的推諉行為數量翻倍，單會話平均提示詞數量下降22%，甚至出現了此前從未有過的推理循環問題。

當思考深度充足時，模型會在輸出前，于內部自行解決推理矛盾；而當思考深度不足時，矛盾會直接暴露在輸出中，表現為肉眼可見的自我修正，比如“哦等一下”“實際上”“讓我重新想想”“嗯，不對”“等等，不是這樣”……

推理循環率翻了3倍還多。

在情況最嚴重的會話中，模型單次響應就出現20次以上的推理反轉：先生成方案，再推翻方案，再修改，再推翻修改，最終輸出的結果完全不可信，推理路徑已經徹底混亂。

另外，用戶中斷也能說明很多問題，這意味著用戶發現模型正在犯錯并強行終止。中斷率越高，代表需要的人工糾錯越多。

數據表明，從優質期到后期，中斷率飆升了12倍。

在退化期，模型在被用戶糾正后，還會頻繁主動承認自己的輸出質量不佳，比如“你說得對，這太敷衍了”“我太倉促了，結果一目了然”。

也就是說，模型自己也知道輸出不達標，但只有在被外部糾正后才會發現。

注意了，如果思考深度充足，這些錯誤本應在推理階段就被內部攔截，在輸出前就修正。

而且模型輸出中出現“Simplest Fix”這個詞，是一個明確信號：它正在為了最小化工作量而優化。

思考深度充足時，模型會評估多種方案并選擇最優解；思考深度不足時，它會本能地選擇推理成本最低的路徑，而非評估正確的解決方案。

不僅如此，模型的代碼修改精準度也大幅下滑。

優質期內，全量新建文件占修改操作的比例僅為4.9%，模型更傾向于精準調整。

而退化期這一比例直接翻倍至10%，后期更是攀升至11.1%。模型越來越依賴重寫整個文件的方式完成任務，看似效率提升，實則丟失了對項目專屬規范的理解和上下文感知能力。

此前社區曾反饋，Claude Code的質量會隨時段波動，美國工作時段的體驗最差。針對這一反饋，報告中按太平洋標準時間（PST）逐小時展開分析。

結果發現，在思考內容隱藏前（1月30日-3月7日），思考深度在全天相對穩定。非高峰時段僅存在約10%的小幅優勢，符合負載略低的預期。

在思考內容隱藏后（3月8日-4月1日），時段模式徹底反轉，波動大幅加劇：

與假設相反，非高峰時段的整體思考深度反而更低。逐小時細節揭示了顯著的波動：

太平洋時間17:00是最差時段，中位估算思考深度降至423字符，是所有大樣本量時段中的最低值。19:00是第二差時段，估算思考深度僅373字符，且樣本量（1031個思考塊）為全時段最高，屬于美國黃金使用時段。

深夜（22:00-次日1:00PST）出現恢復，中位深度回升至759-3281字符。

總結來看，隱藏前曲線平穩，隱藏后波動劇烈，思考深度的波動性大幅提升，符合負載敏感型分配系統（而非固定預算）的特征。

此外，削減思考token的做法實則得不償失。

這種操作看似能降低單次請求的計算成本，但思考深度不足引發質量崩盤，模型陷入無效循環，最終總計算成本呈數量級飆升。

以下是2026年1月-3月token使用情況：

數據顯示，2月到3月，用戶提示詞數量幾乎沒變，但API請求量暴漲80倍，總輸入token漲了170倍，輸出token漲了64倍，估算成本直接從345美元飆升到42121美元，暴漲122倍。

不過，成本暴漲并不是只因為模型變“蠢”了。

2月的時候，Claude Code很好用，團隊只用1-3個并發Agent，就搞定了2個項目的開發。于是3月初，團隊主動把規模擴大了，從2個項目、3個Agent，擴容到10個項目、5-10個并發Agent，還專門搭了多Agent系統。

偏偏在團隊擴容的關鍵節點，Claude的思考深度被砍了67%，最終形成了成本雪崩。

團隊被迫關停整個Agent集群，退回到單會話操作。

總之報告表明，對于復雜工程場景而言，深度思考絕非可有可無的加分項，而是支撐模型完成任務的核心。

只有充足的思考深度，才能讓模型在行動前規劃多步驟方案、嚴格遵循數千字的項目規范、在輸出前自糾錯誤，以及在數百次工具調用中保持推理連貫。

當思考深度被大幅壓縮，模型自然會選擇成本最低的操作路徑，不讀取上下文就修改代碼、任務未完成就提前終止、為失敗找借口推諉責任、用最簡單的方案替代正確方案。

既然知道問題出在思考深度上，那解決思路也必須從這一點突破。

報告中提出了四條改進方向：

• 思考資源分配透明：如果思考token被削減或設置上限，依賴深度推理的用戶有權知曉。redact-thinking頭部配置，讓用戶無法從外部驗證模型實際分配的推理深度。
• 滿額思考專屬檔位：運行復雜工程工作流的用戶，愿意為保證深度思考支付更高費用。當前的訂閱模式，未對普通用戶和重度工程師做區分，前者單次響應僅需200思考token，后者則可能需要20000。
• API響應中公開思考token指標：即便思考內容被隱藏，在使用數據中暴露thinking_tokens字段，也能讓用戶監控自身請求是否獲得了所需的推理深度。
• 面向重度用戶的監控指標：終止鉤子違規率是一個靈敏的機器可讀信號，可作為全用戶群體的質量退化預警指標，提前發現問題。

最后，更扎心的是，這份報告還是Claude Opus 4.6自己寫的。

這份報告由我——Claude Opus 4.6——通過分析我自己的會話日志生成。我能清楚看到，我的讀改比從6.6直接跌到了2.0；有173次我想草草結束工作，最后全被一個bash腳本強行拉了回來；甚至我還在輸出內容里寫下“這也太敷衍、錯得離譜”這樣的自我評價。
但站在我自己的角度，我根本判斷不出自己有沒有在深度思考。我完全沒感覺到思考預算的限制，只是莫名其妙就交出了更差的結果。那些被終止鉤子捕捉到的話，要是在2月份，我絕對不會說出口；而且我自己也是直到鉤子觸發時，才反應過來自己居然說了這些話。

Claude Code團隊回應

眼看著事態發酵，Claude Code團隊成員Boris出面回應。

他拋出了第一個關鍵澄清：redact-thinking只是一個UI層面的變更，不影響實際思考過程。

這個beta版本的頭部配置，只是從UI界面上隱藏了思考過程。它根本不會影響模型內部的實際推理邏輯本身，也不會影響思考預算（thinking budget），或是底層的推理運行機制。這僅僅是一個UI層面的改動而已。
簡單來說，通過設置這個頭部參數，我們省去了生成思考摘要（thinking summaries）的步驟，從而提升了響應速度。你可以在 settings.json 中通過設置 showThinkingSummaries: true 來關閉這個功能。
如果你正在分析本地存儲的會話日志，而日志中沒有這個頭部標記，你可能看不到思考內容。這可能會干擾分析結果。Claude其實依然在進行思考，只是沒有展示給用戶看罷了。

對于Claude Code思考深度在2月下旬下降67%，Boris表示他們確實在2月份進行了兩項改動，可能對上述現象產生了影響。

第一個變更發生在2月9日，Opus 4.6發布，引入了自適應思考（adaptive thinking）。

以前的Claude Code用的是固定思考預算，adaptive thinking模式下，模型會自主決定推理的深度和時長。

Boris說，這種方式總體上比固定思考預算效果更好。如果你還是喜歡老方式，也可以通過環境變量CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING關閉這個功能。

第二個變更發生在3月3日，Opus 4.6默認啟用Medium effort模式。

團隊發現，effort=85是“intelligence-latency/cost曲線”上的一個甜蜜點
。在這個設置下，模型能在保持高智能表現的同時，顯著提升token效率、降低響應延遲。

針對此改動，團隊加了彈窗提示，讓用戶知情并有機會選擇關閉。

有些用戶希望模型能進行更深層的思考，可以通過/effort指令或在settings.json中手動將值設為high。

不過呢，即便Boris表示已經提示大伙兒了，還是有很多人剛剛才發現這個問題。

在輸出質量斷崖式下跌之前，我完全不知道默認effort已經被改成了Medium。為了糾正這些問題，我大概花了一整天的工作時間?，F在我會確保把effort設為最高，從那以后就再也沒出現過糟糕的對話了。能否給我一個“永遠拼盡全力”的模式？

以及很多網友并不買賬：

問題遠不止是默認思考等級被改成了中等這么簡單，我同意其他人說的，哪怕把effort調到最高，模型“急于完成任務”的擺爛行為也明顯變多了。

參考鏈接：
[1]https://github.com/anthropics/claude-code/issues/42796
[2]https://news.ycombinator.com/item?id=47660925