整理 | 蘇宓

出品 | CSDN（ID：CSDNnews）

“Claude 無法勝任復(fù)雜的工程任務(wù)?！?/p>

近日，曾被視為最強 AI 編碼工具之一的 Claude Code，遭遇了前所未有的信任危機。帶頭提出質(zhì)疑的，是 AMD 人工智能部門的負(fù)責(zé)人——她直言吐槽 Claude Code 越更新越差，不僅“變蠢”，還學(xué)會了偷懶擺爛。

不僅如此，她更拿出了數(shù)萬條實際使用數(shù)據(jù)進(jìn)行深度分析，實錘了這一說法。

一則 GitHub issue，引全網(wǎng)熱議

這場爭議的導(dǎo)火索，源于 4 月 2 日一名昵稱為 stellaraccident 的用戶，在 Claude Code 的 GitHub 項目頁面上提交的一個問題反饋（Issue）。

她沒繞任何彎子，直接在 issue 標(biāo)題中就帶著不滿：“2 月份的更新導(dǎo)致 Claude Code 無法用于復(fù)雜的工程任務(wù)”。

根據(jù)該用戶的 GitHub 個人資料和相關(guān) Linkedln 帖子顯示，這位發(fā)帖人正是芯片制造商 AMD 人工智能部門主管 Stella Laurenzo。

她明確列出了更新后 Claude Code 的四大問題，堪稱“四宗罪”：

1. 無視指令

2. 聲稱“最簡單的修復(fù)方案”，但其實是錯誤的

3. 執(zhí)行與要求相反的操作

4. 在未按要求完成的情況下聲稱已完成

為了證明自己并非隨口吐槽，Stella Laurenzo 還拿出了團隊幾個月的使用日志，里面詳細(xì)記錄了 6852 次會話，這些會話包含了 234760 次工具調(diào)用和 17871 個思維塊。

所有數(shù)據(jù)都指向一個結(jié)論：2月份之后的 Claude Code，就是在擺爛，稍微復(fù)雜一點的工程活，根本信不過。

Claude Code 到底擺爛成什么樣？

通過對會話文件的量化分析，Stella Laurenzo 指出：思考內(nèi)容脫敏功能（redact-thinking-2026-02-12）的上線，與復(fù)雜長會話工程工作流的質(zhì)量退化，有著精準(zhǔn)的對應(yīng)關(guān)系。

數(shù)據(jù)顯示，擴展思考 token 并非“錦上添花”，而是模型執(zhí)行多步驟研究、遵守規(guī)范、精細(xì)修改代碼的核心必要條件。

一旦思考深度降低，模型的工具使用模式就會從“先研究后修改”，明顯轉(zhuǎn)變?yōu)椤爸苯有薷摹保@也直接引發(fā)了用戶反饋的各類質(zhì)量問題。

Stella Laurenzo 以及其團隊基于以下幾個維度剖析了 Claude Code 這幾個月間的變化：

1.思考內(nèi)容隱藏時間線與質(zhì)量回退相吻合

從會話 JSONL 文件中對思考塊的分析結(jié)果來看，變化更為直觀：

調(diào)查報告顯示，質(zhì)量退化問題于 3 月 8 日被獨立上報，而這一天，恰好是脫敏思考塊占比突破 50% 的日子。據(jù)悉，脫敏功能是分階段部署的，從 1.5% 逐步提升至 25%、58.4%，最終在一周內(nèi)達(dá)到 100%。

2.脫敏前思考深度已大幅下降

1 月份時，Claude Code 每次思考的內(nèi)容大約有 2200 個字符，能看出是在認(rèn)真琢磨問題?？傻搅?2 月底，思考字符數(shù)直接暴跌至 720 個，相當(dāng)于減少了三分之二的思考量，思考深度下降了 67%。

除了思考偷懶，Stella Laurenzo 和 AMD 團隊還檢測了 Claude Code 的多項質(zhì)量指標(biāo)。

在思考分析完成前，他們已基于 18000 + 用戶提示詞獨立計算以下指標(biāo)：

此外，他們也編寫了 stop-phrase-guard.sh 停止鉤子，用于自動檢測推諉、提前停止、請求許可等敷衍行為。

結(jié)果顯示，3 月 8 日后的 17 天內(nèi)，這個鉤子被觸發(fā)了 173 次，而在此之前，從未被觸發(fā)過。

另外，Claude Code 的工作態(tài)度也發(fā)生了徹底轉(zhuǎn)變，最核心的變化就是修改代碼的邏輯：以前它會先認(rèn)真閱讀相關(guān)文件，再動手修改，但對 234760 次工具調(diào)用的分析顯示，現(xiàn)在的它，已經(jīng)不再先閱讀代碼再修改了。

調(diào)查數(shù)據(jù)清晰地呈現(xiàn)了這一退化：1 月份時，Claude Code 改一次代碼平均要讀取 6.6 次文件，生怕出現(xiàn)錯誤。這算是它的“良好期”，會先讀取目標(biāo)文件、關(guān)聯(lián)文件，全局檢索用法，查看頭文件與測試用例，再進(jìn)行精準(zhǔn)修改。

可到了 3 月底，它平均只讀 2 次文件就敢直接動手修改，降幅超過 70%。這樣一來，問題自然層出不窮：僅讀取當(dāng)前文件就直接修改，常常忽略上下文，進(jìn)而出現(xiàn)亂插代碼、破壞原有注釋、重復(fù)編寫邏輯等問題，寫出來的代碼 Bug 滿天飛。

很多程序員反饋，后續(xù)修改這些 Bug 的時間，比自己重新寫一段代碼還要久。

除此之外，Claude Code 全新寫入的占比翻倍，模型更傾向于重寫整個文件，而非精準(zhǔn)修改。這樣做雖然速度更快，但會丟失精度與上下文感知，反而得不償失。

Stella Laurenzo 還進(jìn)一部分分析了受影響的工作流，主要包括：

• 50 + 并發(fā)代理會話執(zhí)行系統(tǒng)編程（C、MLIR、GPU 驅(qū)動）
• 30 分鐘以上自主運行，執(zhí)行復(fù)雜多文件修改
• 嚴(yán)格的項目規(guī)范（5000 + 字 CLAUDE.md 文檔）
• 代碼評審、工單管理、迭代調(diào)試
• 良好期單周末合并 19.1 萬行代碼

其指出，擴展思考是模型實現(xiàn)以下能力的核心機制：

• 行動前規(guī)劃多步驟方案（讀取文件、執(zhí)行順序）

• recalling 并遵循項目規(guī)范

• 輸出前自我檢查錯誤

• 判斷任務(wù)是否完成、會話是否繼續(xù)

• 數(shù)百次工具調(diào)用中保持邏輯連貫

而當(dāng)思考深度不足時，模型就會選擇最省力的操作：不讀取文件直接修改、未完成任務(wù)就停止、推諉責(zé)任、用最簡單的方案替代正確方案。

從 2 月到 3 月，Claude Code API 請求量直接暴漲了 80 倍，輸出的 token 也增加了 64 倍。據(jù)估算，每月的使用成本從幾百美元，直接飆升到 4 萬多美元。本來想省單次思考的算力，結(jié)果因為 Claude Code 反復(fù)改錯、需要不斷重試，反而讓整體成本直接失控，簡直是賠本賺吆喝。

訴求：雖然我已換了其他大模型，但還是希望 Anthropic 能修復(fù)產(chǎn)品

面對這樣的結(jié)果，Stella Laurenzo 表示，這不是她一個人遇到的問題，而且情況已經(jīng)嚴(yán)重到無法在工作環(huán)境中繼續(xù)使用 Claude Code 的地步。

她說道：“我們的工作環(huán)境復(fù)雜度高且穩(wěn)定，通過挖掘數(shù)月日志，我們明確了問題的根源——自 2026 年 2 月起，Claude 已無法可靠完成復(fù)雜工程任務(wù)。團隊所有資深工程師均反饋了類似問題，其中一位工程師擁有可復(fù)現(xiàn)的測試流程，我們基于其日志開展實驗與數(shù)據(jù)分析，且已嘗試所有公開的變通方案。”

在 Stella 看來，自己發(fā)布這份反饋，并不是為了抹黑 Anthropic，而是真心希望他們能重視這個問題，拯救 Claude Code 這個曾經(jīng)的好產(chǎn)品?！?strong>我們已切換至其他服務(wù)商，其服務(wù)質(zhì)量更優(yōu)，但 Claude 曾為我們提供良好支持，因此提交此問題，希望 Anthropic 能修復(fù)產(chǎn)品。”

對此，其提出了四個建議：

• 關(guān)于思考資源分配的透明度：如果思考 token 被減少或設(shè)上限，依賴深度推理的用戶需要知情。目前的 redact-thinking header 讓外部無法驗證這一點。

• “最大思考”等級：執(zhí)行復(fù)雜工程工作流的用戶愿意為保證深度推理付出更高費用。目前的訂閱模式?jīng)]有區(qū)分需要每次 200 個思考 token 的用戶和需要 20,000 個的用戶。

• API 響應(yīng)中的思考 token 指標(biāo)：即使思考內(nèi)容被隱藏，如果在使用情況響應(yīng)中暴露 thinking_tokens，用戶仍可監(jiān)控自己的請求是否獲得了所需的推理深度。

• 高階用戶的金絲雀指標(biāo)：停止鉤子違規(guī)率（從 0 → 每天 10 次）是一個可機器讀取的信號，可以在整個用戶群體中監(jiān)控，作為質(zhì)量回退的領(lǐng)先指標(biāo)。

網(wǎng)友吐槽：從“封神”到“勸退”，落差太大

不光 AMD 這位高管，全網(wǎng)的程序員們看到這份反饋后，像是找到了組織，評論區(qū)里一片哀嚎。

有人表示，這段時間一直懷疑是自己技術(shù)下滑了，寫代碼總被 Claude Code 帶偏，直到看到這份反饋才知道，原來大家都有一樣的困擾。

作為 Claude 曾經(jīng)的忠實用戶，程序員 bbecausereasonss 在 Reddit 上發(fā)帖稱：“我已經(jīng)無法再心安理得地向客戶推薦 Claude Code 了?！?/p>

他表示：“我是 MAX 用戶。剛開始使用 Claude Code 時，我真的被震撼到了。自 2022 年以來我一直在用 AI 做開發(fā)，這一次確實讓我感覺像是一個重要的歷史時刻。我曾經(jīng)把 Claude Code 推薦進(jìn)客戶的項目和開發(fā)流程中，在社交媒體上大力稱贊它，也在私下里不斷安利給身邊的人。”

但他話鋒一轉(zhuǎn)，吐槽當(dāng)前版本的模型狀態(tài)：“懶惰、無知、能力退化且視野狹隘，在還沒有真正理解整體問題和各種邊界情況之前，就盲目開始‘修復(fù)’——而且大多數(shù)補丁反而把事情搞得更糟。我已經(jīng)無法再負(fù)責(zé)任地繼續(xù)推薦它了，因為這只會讓我看起來像個傻子，或者在胡說八道，甚至兩者兼具。”

他還直言：“Claude Opus 在過去幾周簡直是一場災(zāi)難——甚至還沒提到使用額度的問題。一個很貼切的比喻是，它像是被‘做了腦葉切除手術(shù)’，智商從 135–150 直接掉到 90–100，感覺退化成了 Sonnet 3.5。真的很失望。”

還有人追問 Stella Laurenzo 究竟在用什么模型替代 Claude Code：

“Claude 已經(jīng)退化到無法被信任去完成復(fù)雜工程任務(wù)的地步。”

差不多，但我覺得更準(zhǔn)確的說法是：Claude 已經(jīng)退化到連任何工程任務(wù)都不值得信任的程度了。

它從來沒有一次就把事情做對過，寫出來的代碼充滿 bug 和重復(fù)邏輯，而且必須全程盯著，否則它一定會把東西搞壞。

它已經(jīng)變成了另一個 AI“玩具”。挺可惜的。

能否分享一下你在用的“其他工具”？我也想試試。

不過，Stella Laurenzo 并沒有指出自己用的是哪款模型替代。而是補充說道：「在 6 個月前，Claude 在推理質(zhì)量和執(zhí)行能力上幾乎是獨一檔的。但現(xiàn)在，其他競品也需要被非常認(rèn)真地重新評估。就能力層級而言，Anthropic早已不再是唯一一個處在 Claude Opus 曾經(jīng)所在水平的玩家。」

現(xiàn)在網(wǎng)友們的呼聲其實很一致：對于 AI 編程助手，可以接受它慢一點，但絕對不能接受它變蠢、變懶，更不能接受它敷衍了事。畢竟大家用 AI 編程助手，不是想要一個“快但錯”的打字機，而是想要一個能一起思考、能扛事的隊友，要是連最基本的思考都沒了，那這個工具，也就失去了它存在的意義。

對此，你在使用 Claude Code 有什么樣的感受？

參考：

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

https://github.com/stellaraccident

https://www.theregister.com/2026/04/06/anthropic_claude_code_dumber_lazier_amd_ai_director/

【活動分享】"48 小時，與 50+ 位大廠技術(shù)決策者，共探 AI 落地真路徑。"由 CSDN&奇點智能研究院聯(lián)合舉辦的「全球機器學(xué)習(xí)技術(shù)大會」正式升級為「奇點智能技術(shù)大會」。2026 奇點智能技術(shù)大會將于 4 月 17-18 日在上海環(huán)球港凱悅酒店正式召開，大會聚焦大模型技術(shù)演進(jìn)、智能體系統(tǒng)工程、OpenClaw 生態(tài)實踐及 AI 行業(yè)落地等十二大專題板塊，特邀來自BAT、京東、微軟、小紅書、美團等頭部企業(yè)的 50+ 位技術(shù)決策者分享實戰(zhàn)案例。旨在幫助技術(shù)管理者與一線 AI 落地人員規(guī)避選型風(fēng)險、降低試錯成本、獲取可復(fù)用的工程方法論，真正實現(xiàn) AI 技術(shù)的規(guī)?；涞嘏c商業(yè)價值轉(zhuǎn)化。這不僅是一場技術(shù)的盛宴，更是決策者把握 2026 AI 拐點的戰(zhàn)略機會。