Claude Code越更越廢？！大廠AI主管公開怒噴思考深度暴跌，官方回應更被懟爆 ：菜成AI“玩具”

整理 | 華衛

“Claude Code 在 2 月份更新后無法用于復雜的工程任務�！苯眨粭l這樣的帖子在熱門開發者論壇上引發熱議，甚至讓 Anthropic 的 Claude Code 負責人 Boris Cherny 親自“出現”來做回應。

溯源之后我們發現，這一言論最早是在一位開發者在 Claude Code 的 Github 主頁上提交的 issue，且附上的分析報告基于挖掘了三個月的 Claude 會話日志數據得出，包含的角度及內容都十分詳盡。

而根據這位開發者在 Github 主頁上的名字 Stella Laurenzo 及相關的 Linedln 帖子，該開發者還是 AMD 的 AI 團隊主管。

思考深度下降 67%，

算力消耗增加幾個數量級

先來看看 Laurenzo 發布的分析報告。該報告由 Claude Opus 4.6 基于其 2026 年 1 月 30 日至 4 月 1 日的會話日志數據生成，對 6852 份 Claude Code 會話文件中的 17871 個思考模塊與 234760 次工具調用進行量化了分析后給出結論：redact-thinking-2026-02-12 的上線，與復雜、長會話工程工作流中可觀測到的質量下降呈現精準關聯。

并且，數據表明，擴展思考 token 并非 “錦上添花” 的功能，而是模型完成多步驟研究、遵循規范、審慎修改代碼所必需的結構性要素。當思考深度被削減時，模型的工具使用模式會出現可測量的轉變，從 “優先研究” 轉向 “優先編輯”，進而引發用戶反饋的各類質量問題。

在展開分析前，報告中表示，“分析通過數據幫助 Anthropic 明確受影響最顯著的工作流及其成因，旨在為高權限用戶的思考 token 分配決策提供依據�！�

一是思考內容屏蔽時間線與質量下降高度吻合，這基于會話 JSONL 文件中的思考模塊分析。此次質量下降問題于 3 月 8 日被獨立上報，而這一天恰好是 redacted thinking 占比突破 50% 的日期，其上線節奏（一周內從 1.5% 逐步升至 25%→58%→100%）與分階段灰度發布的特征完全吻合。

二是思考深度在 redacted thinking 前已呈下降趨勢，思考模塊中的特征字段與思考內容長度的皮爾遜相關系數達 0.971（基于 7146 組同時包含二者的配對樣本測算）。即便在 redacted thinking 后，仍可據此估算思考深度。截至 2 月下旬，在 redacted thinking 啟動之前，思考深度就已下降約 67%。3 月初上線的 redacted thinking 處理，讓這一變化對用戶變得不可見。

三是行為影響，這些可量化的質量指標均在開展思考分析之前，基于 18000+ 條用戶提示詞獨立計算得出。其專門編寫了攔截腳本（stop-phrase-guard.sh），用于自動檢測模型回避責任、過早終止任務、反復請求授權確認等行為。該腳本在 3 月 8 日之后的 17 天內觸發了 173 次，而在此之前觸發次數為零。

四是工具使用模式轉變：優先查閱 → 優先編輯，對 234760 次工具調用的分析顯示，模型不再先閱讀代碼再進行修改。模型從每次編輯對應 6.6 次查閱降至 2.0 次，修改前的調研行為減少了 70%。在表現良好的階段，模型工作流為：讀取目標文件 → 查閱相關文件 → 在代碼庫中檢索調用關系 → 閱讀頭文件與測試代碼 → 再進行精準修改。而在性能退化階段，模型僅讀取當前文件便直接編輯，常常不檢查上下文環境。

報告稱，研究力度的下滑始于 2 月中旬，與估算思考深度下降 67% 的時間段完全吻合。同時，整文件寫入的使用量翻倍，模型越來越傾向于重寫整個文件，而非進行精準的局部修改；這種方式速度更快，但會喪失精確性與上下文感知能力。

并且，“減少思考次數看似能節省每次請求的算力。但一旦思考不足導致輸出質量下降時，模型就會崩潰：生成錯誤結果、被中斷、不斷重試，并在后續修正中消耗大量 token。而這些修正原本在第一次就正確思考的情況下是不需要的，最終結果卻是，整體算力消耗增加了幾個數量級�！�

據悉，受影響的工作流包含多個場景：50 余個并發智能體會話，從事系統編程（C、MLIR、GPU 驅動）；30 分鐘以上自主運行，執行復雜的多文件修改；大量項目專屬規范（長達 5000 余詞的 CLAUDE.md）；代碼評審、需求 / 工單管理與迭代調試；表現良好階段，曾在一個周末內通過兩個合并請求合入 19.1 萬行代碼。

Laurenzo 強調，“擴展思考是高級工程師工作流程的支柱”。她表示，擴展思考是模型實現以下能力的核心機制：行動前規劃多步方案（讀取哪些文件、按什么順序）、從 CLAUDE.md 中調取并應用項目規范、在輸出前自行發現錯誤、判斷繼續執行還是終止（會話管理）、在數百次工具調用中保持連貫推理。

“當思考深度不足時，模型會傾向于選擇成本最低的行為：不閱讀就編輯、未完成就終止、為失敗推諉責任、采用最簡單而非正確的修復方案。這些正是實際觀測到的問題表現。”這是該開發者最終給出的判斷。

為此，她提出以下四點改進建議。

• 思考資源分配透明化：若思考 token 被削減或設限，依賴深度推理的用戶應知情。當前的思考內容脫敏頭部導致外部無法驗證。

• “最大思考量” 付費檔位：運行復雜工程工作流的用戶愿意支付更高費用，以獲得穩定的深度思考能力�，F有訂閱模式未區分單次需 200 思考 token 與需 20,000 思考 token 的用戶。

• 在 API 響應中返回思考 token 指標：即便思考內容被脫敏，在用量響應中暴露 thinking_tokens 字段，可讓用戶監控請求是否獲得所需推理深度。

• 來自重度用戶的預警指標：攔截腳本觸發率（從 0 升至日均 10 次）可作為機器可讀信號，在全用戶群中監測，作為質量下降的先行指標。

開發者罵瘋了：

退化為一個 AI“玩具”

對于這份分析報告，不少開發者表示了強烈的認同�！胺治龅锰袅�。作為用戶，我過去幾周也遇到了這個問題，但一直找不到原因。”“完全證實了我們一直以來所說的！”“這與我使用 Claude 的經歷非常吻合，尤其是在過去的幾個月里�！薄霸瓉聿恢刮乙粋�人這樣�！�

甚至有幾位個人開發者認為，Claude Code 的水平已經下降到一年以前�！斑^去一個月我對 Claude Code 越來越失望，它經常胡說八道，還信誓旦旦地解釋一些我知道是錯的原理。感覺就像在用去年的 Claude Code 一樣�！薄拔沂褂� Claude Code 已經 8 個月了，但現在模型質量的下降程度讓我非常驚訝。不僅 token 使用量激增，而且最新 Opus 和 Sonnet 模型生成的代碼質量也遠低于我去年 12 月的水平�！�

還有開發者稱，“不止復雜工程任務，Claude 已經退化到無法信任其執行任何工程任務的地步了。它從來不會第一次就把事情做對，代碼中充滿了錯誤和重復代碼，必須時刻監視它，否則它就會搞砸一切。Claude 已經淪為又一個人工智能‘玩具’了，真可惜。”

值得關注的是，某位采用 Claude 的企業技術團隊負責人，就此給出了更為尖銳的評價。

我對此并無異議，而且我其實還有更復雜的內部分析。但我也在盡量謹慎發言，只談論我本人能夠證實的事情。我曾多次告訴我的團隊，“挫折在所難免，供應商發布糟糕版本也不是第一次了”。然而，這次的退步非常嚴重，我想我們都在觀察 Anthropic 會如何處理。歸根結底，我需要一個值得信賴的工程工具合作伙伴，這一點對智能體本身和智能體的開發者同樣適用。如果他們能從現在的狀況中把產品拉回正軌，我會密切關注，并在看到他們的實際行動之前保留意見。

我受多項保密協議約束，只能透露我能說的有限信息。我只想再補充一點：六個月前，Claude 在推理質量和執行能力上還是獨一檔的存在但其他競品現在也需要被密切關注和仔細評估。在 Opus 此前所處的能力梯隊中，Anthropic 早已不再是唯一的玩家。

Claude Code 負責人回應被駁，

反給 Codex“送人”？

事態不斷發酵，加入這場討論的開發者越來越多，Claude Code 負責人 Boris Cherny 也注意到了，并于幾個小時前親自在 Github 和論壇都發帖回應了情況。

您好，感謝這份詳盡的分析。在繼續溝通之前，我想先表達對其中展現的深度思考與嚴謹態度的認可。這份報告內容豐富，我將嘗試逐一拆解說明。核心問題主要集中在兩點：

關于 redact-thinking-2026-02-12

該測試版頭部配置僅在界面中隱藏思考過程，因為絕大多數用戶并不會查看這部分內容。它不會影響模型實際的思考行為，也不會改變思考配額或底層擴展推理機制，屬于純界面層面的改動。

在底層實現中，啟用該頭部可以省去生成思考摘要的步驟，從而降低延遲。你可以在 settings.json 中設置 showThinkingSummaries: true 退出該模式（詳見文檔）。

如果你分析的是本地存儲的會話記錄，在該頭部啟用的情況下將不會保存原始思考內容，這很可能對分析結果產生了影響。Claude 在本次分析中觀察到會話記錄缺少思考內容，可能并未意識到思考過程實際仍在進行，只是未對用戶展示而已。

關于 “截至 2 月下旬思考深度已下降約 67%”

我們在 2 月份確實落地了兩項可能對此產生影響的改動，且均經過審慎評估：

2 月 9 日：Opus 4.6 版本發布 → 默認啟用自適應思考機制 Opus 4.6 支持自適應思考，這與此前采用的固定思考配額機制不同。在該模式下，由模型自主決定思考時長，整體效果普遍優于固定配額方案�？赏ㄟ^ CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING 退出該機制。

3 月 3 日：Opus 4.6 默認思考強度設為中等（85）我們發現，強度值 85 在智能水平、延遲與成本之間達到了對大多數用戶而言的最優平衡點，能夠在提升 token 效率的同時降低延遲。我們的產品原則之一是避免擅自更改用戶設置，理想情況下本應從一開始就將默認值設為 85。由于我們認為這是一項關鍵調整，因此采取了以下方案：

1. 上線時伴隨彈窗提示，讓用戶知曉變更并可選擇退出

2. 在用戶首次打開 Claude Code 時顯示當前強度值，避免產生困惑

部分用戶希望模型進行更長時間的思考，即便這意味著更高的耗時與 token 消耗。若想進一步提升智能表現，可通過 /effort 指令或在 settings.json 中將強度設為 high。該設置會在會話間保留，也可在團隊內共享。你也可以使用 ULTRATHINK 關鍵字為單輪對話啟用高強度思考，或設置 /effort max 讓本輪對話后續內容使用更高思考強度。

后續我們將測試為團隊版與企業版用戶默認啟用高思考強度，使其直接受益于擴展思考能力，即便會帶來額外 token 消耗與延遲。該默認設置同樣可通過 /effort 指令與 settings.json 進行調整。

但大部分開發者似乎并不“買賬”他的解釋，還紛紛反駁了其論述的幾個方面。

首先是 Laurenzo，她對此回復道，“需要明確的是，針對這一問題，我們已經嘗試了思考強度與自適應思考的所有參數組合，并通�；谶B續數天的日志進行驗證。最終我們得出結論：Claude 的質量退化已經嚴重到無法再作為可靠協作伙伴正常使用。我們擁有足夠多思考過程未被屏蔽的日志數據，可以證明：在思考過程被隱藏之前，模型性能就已經出現劣化。無論如何，你們可以按照自己的方式處理問題生命周期，但我們目前沒有看到任何證據表明該問題已被修復，或可通過現有參數設置進行有效控制。”

一部分開發者表態稱，“關于此事，如果 Anthropic 官方回應稱一切運行正常、并無問題，那我們最終大概率將遷移至 Codex�！�

也有開發者表示，“直到輸出質量急劇下滑，我才意識到默認思考強度已被改為中等。為此我耗費了將近一天時間來修正問題�，F在我都會把思考強度設為最高，之后就再沒出現過糟糕的會話情況。懇請加入一個‘始終全力思考’的模式可以嗎？”

對此，有幾位開發者持有不同的看法。一位開發者說道，“我感覺最高思考強度模式反倒有點像是用力過猛，結果變得急功近利、敷衍了事，甚至出現反向效果，反而和低強度模式或劣質提示詞的表現差不多了�！边�有開發者指出，“問題遠不止是默認思考強度被設為中等這么簡單，我也認同其他人的說法，即便調至高強度模式，模型急于草草收尾的傾向也明顯大幅加劇�！�

Cherny 專門回復了這個問題，態度也很誠懇。他表示，“感謝反饋。為方便我們實際定位問題，麻煩您下次遇到此類情況時執行 `/bug` 指令，并在此處提交反饋編號。這樣我們就能進行調試，判斷是出現了異常問題，還是仍在正常波動范圍內�！�

就這一情況，Laurenzo 在回復 Cherny 的評論中發表了最新觀點及其之后的計劃。“這次引發的反響遠超我的預期，之后我已刪除了部分被斷章取義的表述，這些內容偏離了我撰寫報告時只想呈現‘客觀觀測結果’的初衷。正如該討論主題開頭所說，Claude 在過去數月里一直表現出色，我們也希望評估如何繼續從它身上獲得我們早已習慣的高質量輸出。在我們此前的測試中，并未發現調整任何思考強度參數能夠改變模型觸發攔截規則、傾向走最簡路徑的問題。”

她表示，“由于這類評估必須基于真實開發場景，我們會在相關工作推進時重新試用這些設置，并提交 `/bug` 反饋記錄（我們同時保留了完整會話日志，可私下共享；本次分析僅基于開源代碼庫上的工作內容）�！�

https://news.ycombinator.com/item?id=47660925

https://github.com/anthropics/claude-code/issues/42796#issuecomment-4194703741

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

會議推薦

QCon 全球軟件開發大會·2026 北京站將于 4 月 16 日 -18 日正式舉辦。本屆大會以“Agentic AI 時代的軟件工程重塑”為主題，聚焦 100+ 重磅議題，匯聚來自阿里、騰訊、字節跳動、小米、百度等一線科技企業與創新團隊的技術專家，圍繞 AI 工程化、系統架構與研發模式演進展開深入探討。更多詳情可掃碼或聯系票務經理 18514549229 進行咨詢。

今日薦文

你也「在看」嗎？