西風 發自 凹非寺
量子位 | 公众号 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:00 PST）出現恢復，中位深度回升至 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。為了糾正這些問題，我大概花了一整天的工作時間。現在我會確保把 effort 設為最高，從那以後就再也沒出現過糟糕的對話了。能否給我一個「永遠拼盡全力」的模式？
以及很多網友並不買帳：
問題遠不止是預設思考等級被改成了中等這麼簡單，我同意其他人說的，哪怕把 effort 調到最高，模型「急於完成任務」的擺爛行為也明顯變多了。
參考連結：[1]https://github.com/anthropics/claude-code/issues/42796[2]https://news.ycombinator.com/item?id=47660925
— 完 —