你以為是 AI 降智?或許是硬塞的資訊稀釋?

AI降智

最近 AI 開發者社群鬧得沸沸揚揚,話題是 Claude Code「變笨了」。

事情的導火線,是 AMD 的 AI 總監 Stella Laurenzo 在 GitHub 上丟出一份超詳細的分析——6,852 個工作階段、234,760 次工具呼叫——直接用數據說話:從今年二月開始,Claude 在複雜工程任務上的推理深度明顯下降,改程式前「先讀再改」的次數從平均 6.6 次跌到 2 次,編碼規範的遵守也開始劣化。這份報告在社群引爆,跟著一堆人說「對!我也覺得變笨了!」

然後 Anthropic 的 Claude Code 負責人 Boris Cherny 出來說:那個推理內容隱藏機制只是介面層面的變更,不影響推理本身。雙方各有說法,社群繼續吵。

說來有趣,身為一個偶爾用 Claude Code 進行小規模專案的開發者,我個人其實感受不到這波「降智」。

這不是因為我要求低——而是讓我開始思考,這件事的真相可能比「Anthropic 偷偷降級」更有意思。


使用模式,才是感受差異的關鍵

仔細看 Laurenzo 的情境:13 個並行代理人、複雜的多檔案工程、長達數小時的工作階段。

這和我偶爾開一個任務、做完收攤的方式,根本是兩種完全不同的使用情境。

Anthropic 在這段期間做了幾個產品調整:推理力道改為預設中等等級、推理過程內容隱藏上線、使用量限制收緊。這些調整對輕度使用者幾乎無感,但對重度長工作階段的使用方式來說,影響是乘法的——推理深度被壓縮,加上任務本身複雜,感受到的退步就非常明顯。

所以「降智了」和「沒有感受到降智」,其實是同一個現象在不同使用情境下的不同切面。兩件事可以同時為真。


還有一個時間點,讓我有點在意

這波「降智」感受,恰好發生在 Claude Opus 4.6 開放 1M 上下文視窗大小(context window)之後。

(補充說明:context window,就是模型在單次對話中能同時「看見」的資訊總量。數字越大,理論上能處理的文件和程式碼就越多。)

這個時間重疊,讓我有個不太確定的推測:支撐 1M tokens 上下文視窗的運算需求是巨大的。為了騰出空間,後台把其他用戶的推理深度往下調,是說得通的工程取捨邏輯。

當然,這只是我的推測,沒有直接證據。

但更有趣的問題其實是:上下文視窗越大,模型就會越聰明嗎?

研究上有個現象叫「中段遺忘」——資訊放在對話的中間位置,模型的回應品質比放在頭尾明顯更差。上下文視窗越大,這個問題只會更嚴重。所以 1M tokens 是一個很好的規格數字,但「容量更大等於更聰明」這件事,本來就值得打問號。

有趣的是,就在這波降智爭議沸沸揚揚之際,Anthropic 在四月十五日發布了一篇官方文章,主題是「Claude Code 工作階段管理與 1M 上下文視窗」。文章裡,他們親口承認了「脈絡腐化(context rot)」這個現象:

使用脈絡容量對效能有輕微影響。隨著上下文增長,模型效能會下降,因為注意力分散在更多 tokens 上,而較舊、不相關的內容開始干擾當前任務。

這句話說清楚了一件事:1M tokens 不是讓你放心塞更多東西進去的,而是給你更多空間來手動管理脈絡。


那麼,解法是什麼?

Anthropic 的官方建議,是把脈絡管理的責任交回給用戶——透過 /rewind/compact/clear、以及subagent 等工具,在適當的時機點主動清理脈絡、隔離噪音。

其中 subagent 的概念特別值得一提:讓中間過程的大量輸出留在 subagent 自己的脈絡裡,只把最終結論帶回主工作階段。判斷標準很簡單——「我之後還需要這個過程本身,還是只需要結論?」

這個思路,其實就是「脈絡隔離」(註¹) 的實踐:與其讓一個代理人扛著越來越重的脈絡跑,不如用明確的邊界讓每個代理人只看它該看的資訊,有限的推理深度才能用在刀口上,而不是浪費在噪音裡。

只是這樣的工作方式,需要用戶主動學習和調整。這或許也解釋了為什麼有些人感受到退步、有些人沒有——除了任務複雜度的差異之外,工作階段管理的習慣,可能才是那個真正的分水嶺。

(我自己的使用方式,碰巧也偏向小任務、短工作階段,所以大概歪打正著了。Orz)

所以這篇文章與其說是結論,不如說是一個觀察起點——如果你正在密集使用 Claude Code,感受到明顯退步,或許值得先回頭看看自己的工作階段管理方式,說不定比等 Anthropic 修好問題還更有效。


註¹:「脈絡隔離」是豆腐個人在探索 multi agents 工作流程時,於「脈絡專注框架」(Context Attention Framework,CAF)中自行定義的概念詞彙,並非 Anthropic 官方用語。Anthropic 的 subagent 設計在實作層面與這個思路吻合,但官方並未使用此命名。

參考資訊