事件背景
2026 年 7 月，Anthropic 官方發表長文澄清一個大誤會：大量 Claude Code 使用者發現模型在 3 月時「變笨了」——該讀的檔案不讀、該跑的測試不跑、任務做到一半就要求更多資訊。使用者的第一反應是升級模型，從基礎版一路砸錢到最貴的 Fable，但問題依舊。GitHub 上罵聲一片，直指 Anthropic 出賣了品質。
真相是：使用者把「模型選擇（Model）」和「努力度（Effort）」這兩個完全獨立的參數混淆了。過去的認知是簡單二分法——換更大的模型就更聰明、調高 Effort 就是讓 AI 多想一陣子。但實際的機制遠更細緻：Effort 不是單純的「思考時間」，而是控制 AI 在任務執行時的探索深度、重試邏輯、以及對上下文的挖掘力度。
當 Anthropic 在 3 月調整了預設 Effort 參數（可能是因應某個系統更新或成本考量），使用者在沒意識到的情況下，突然面對了一個「懶惰」的系統。但因為認知框架裡只有「模型大小 = 智能」這一條線索，他們開始瘋狂升級模型、燒錢卻無效，反而把怨氣都指向 Anthropic 在暗中降質。
AnthropicC 的澄清相當於一場「認知除錯」：問題不在模型、在於使用者的心智模型（mental model）跟系統的真實架構之間斷層了。
本質機制
這個案例觸及了一個深層的人類認知問題：當複雜系統有多個操作維度時，使用者傾向於把所有變異都歸因於最『可見』或最『顯著』的那個維度。
在 Claude Code 的例子裡： - 可見維度：模型名稱（Claude 3.5、Fable），用戶界面大、價格標籤清晰、升級流程直觀 - 隱形維度：Effort 參數，埋在設定頁面某角落、名字抽象、效果難以直觀量化
當系統表現下滑時，使用者會自動走向「顯著維度」找答案，因為： 1. 可及性偏誤（availability bias）：最容易想起的解釋就是最頻繁接觸的 2. 控制錯覺（illusion of control）：升級模型是一個「明確的行動」，感覺自己在「做什麼」 3. 因果逆向推理：「我付錢了但系統變差」→「肯定是被坑了」，而非「我沒調對參數」
應用場景
這個模式在複雜軟體系統中無處不在：
場景 1：資料庫查詢變慢 使用者常見反應：「升級 CPU / 加記憶體」 真實原因常常是：某個 SQL 查詢的 index 失效、或者執行計畫被預設參數卡住
場景 2：手機電池續航下降 使用者常見反應：「換新機」 真實原因常常是：背景程序、螢幕亮度、定位服務沒關——都在「設定」隱角落
場景 3：員工績效下滑 主管常見反應：「換人、加薪激勵」 真實原因常常是：流程改變了但沒有培訓、資訊流斷掉了、目標定義變糊了
對產品設計的啟示
Anthropic 的教訓是：複雜系統的多維度參數必須設計得『可見』、『可理解』、『改變效果可驗證』。 否則使用者會被迫瞎猜、最後指責產品而非調整自己的使用方式。
具體對策： 1. 讓隱形參數顯形：Effort 應該像「模型選擇」一樣突出，用清晰的視覺反饋（如「高探索 vs 快速回應」這樣的對比） 2. 提供因果診斷工具：當性能下降時，系統應該主動提示「這可能是 Effort 設定」而不是等使用者自己挖 3. 建立預期管理：文件、新手指南要明確說「模型和 Effort 的獨立性」，不是事後補救
結構性反思
更深層的問題是：複雜系統的複雜性往往被隱藏在「簡單的外殼」下。 使用者不想學習 10 個參數，希望一鍵解決；但系統的真實狀態就是多維的。這時候產品方有兩個選擇：
1. 真的簡化：減少用戶面對的維度（但可能犧牲靈活性） 2. 聰明地複雜化：保留多維度但用互動設計讓使用者逐步理解（Anthropic 現在該做的）
Claude Code 的「變笨」風波，本質上是選項 2 做得不夠好的結果。