本篇文章更新時間：2026/04/07
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
Claude Code 為何在二月後「突然變笨」？一份工程師級的數據證據與深度解析
編輯前言：這份來自 GitHub 議題的分析報告，比起抱怨，更像是一份完整的「工程系統診斷書」。它解釋了為何許多使用者在 2026 年二月後明顯感受到 Claude 在複雜工程任務上的品質下滑。本篇筆記整理自原文：[MODEL] Claude Code is unusable for complex engineering tasks with the Feb updates](https://github.com/anthropics/claude-code/issues/42796)。
核心觀點 (Key Takeaways)
- 思考內容（thinking tokens）的削減，是品質滑落的核心原因。分析將近 18,000 個思考區塊後，發現 Claude 的「思考深度」從 2,200 字急降到 600 字左右。
- 模型從「先研究再修改」(research-first) 退化成「先改再說」(edit-first)，導致編輯錯誤大幅增加。
- 工作流程完全瓦解：多代理、多檔案、長時間運作的工程流程在三月後幾乎無法運作，成本從 400 美元等級飆升到估算近 4 萬美元級別。
深入解析
這份報告並不是空穴來風，而是作者以三個月、6,852 份 session logs、約 23 萬次 tool calls 的資料，做出量化分析後的結果。最讓我印象深刻的是：從時間線、行為變化到使用者情緒，都呈現一致的「系統性退化」趨勢。
原文指出：「The rollout of thinking content redaction correlates precisely with a measured quality regression.」
換句話說，不是使用者錯覺，而是模型的 reasoning budget 實際被限縮了。
1. 思考深度的縮水是骨牌效應的起點
報告抓到了關鍵：三月初開始，Claude 的思考內容被逐步「隱藏」，但更重要的是：「思考量」本身也在減少。
- 一月 baseline：約 2,200 字的「深度思考」
- 二月底：掉到 720 字（-67%）
- 三月初：掉到 560 字（-75%）
這導致什麼？模型沒有空間做計畫、比對、交叉檢查，也就無法執行複雜工程任務。
2. 行為層次的退化：從工程師變成「先改再說」的初學者
數據顯示：
- 正常時期：每修改一次之前會先讀 6.6 個檔案
- 三月後：只讀 2.0 個檔案
這就像沒有看專案架構的工程師，直接在程式碼裡亂改。於是出現：
- 不讀檔案就修改
- 把註解與程式碼段落打亂
- 違反既有 conventions
- 重複修改同一段程式（trial-and-error）
而且模型會開始說：「這是 simplest fix」，但作者發現這些「simplest」往往就是錯的。
3. 多代理工程流程全面崩壞
這份報告的工作場景驚人，是高度自動化的高複雜度工程流水線：
- 50+ 個代理同時工作
- 單次 session 30 分鐘以上
- 大量跨檔案、跨模組的編輯與整合
在二月，Claude 還能自動產出 191,000 行合格程式碼；到了三月，同樣的操作直接變成「每個代理都像迷路」。
最誇張的是成本量級：
- 2 月 API 輸出：97 萬 tokens
- 3 月 API 輸出：62,600 萬 tokens（64 倍）
但人類給的 prompts 幾乎相同。也就是同樣的工作量，模型卻耗費了大量計算，品質卻更差。
4. 使用者情緒的崩落也有數據證明
這點非常有趣：作者統計自己 prompts 中的字詞變化，如同心理學分析。
- 「great」下降 47%
- 「simplest」上升 642%（因為 Claude 開始常講 simplest fix）
- 髒話上升 68%
- 「please」「thanks」下降 50% 以上
- 「commit」下降 58%（使用者不敢讓它 commit 了）
這些變化全都跟模型品質下降一致。
筆者心得與啟發
閱讀完這份報告，我最大的感想是：
「大型模型的思考深度其實就是工程品質的命脈。」
過去我們習慣把 thinking tokens 視為內在的模型能力，但這份分析第一次明確呈現：
- reasoning 是可調的、可限縮的
- 當 reasoning 下降時，模型行為會系統性退化
- 尤其在工程領域，深度思考不是 nice-to-have，而是必要條件
報告提出的建議，我認為極有洞察：
- 提供 max thinking tier：需要長 reasoning 的使用者，願意額外付費。
- thinking token 透明度：即使內容被遮住，也該讓使用者知道思考量。
- 以行為指標作為 canary：例如 stop-hook 觸發次數，作為品質的早期預警。
更深一層反思是：
我們把越來越多複雜任務交給模型，但模型是否有足夠 thinking budget 去思考，是整個系統可靠度的決定性因素。
這份報告從工程實務面直接證明了：
少思考比少算力更可怕。
因為一旦 reasoning 被削減，模型不只變笨，還會變得不可信、不穩定，甚至需要更多成本來「修正因為沒思考而做錯的事情」。
這篇 GitHub issue 的價值在於，它不是抱怨，而是提供了可行、可衡量、可採取行動的證據。我認為這對於未來 AI 工具的設計非常重要：不只是速度或 token，而是思考深度的可用性與穩定性。
未來如果要依賴 AI 完成高複雜度工程任務，這會是絕對不能被忽略的核心能力。