2026年2月Claude Opus 4.6更新后，開發者圈子一片哀嚎：復雜工程任務從"Senior Expert"級協作，迅速退化成"需要反復監督的實習生"。AMD高級AI總監Stella Laurenzo甩出的6852次日志實錘把一切量化：中位思考長度從2200字符暴跌至600字符（降73%），代碼閱讀/修改比例從6.6:1崩到2:1，模型"上來就瞎寫"而不看上下文；錯誤導致API重試暴增80倍，用戶實際支出上升卻質量下滑。

GitHub Issue、Reddit r/ClaudeAI、HN討論和獨立分析（6800+會話數據）進一步確認：這波"shrinkflation"（縮水通脹）從2月下旬開始，3月思考內容隱藏功能上線后更難察覺。Anthropic官方回應稱是"自適應思考（adaptive thinking）+默認effort=85（中等努力）"的優化結果，目的是提升延遲和token效率，并非惡意降智。但用戶數據表明，復雜工程場景下模型嚴重低估任務復雜度，導致淺層推理。

下面，我們不糾結"動機"（成本控制 vs 新模型Mythos鋪路），而是純技術推測：Anthropic到底通過哪些服務器端/推理時操作，就能讓一個已經訓練好的旗艦模型（Opus 4.6）在不重新訓練、不改變定價的情況下，系統性地"降智"？

1. 最核心推測：推理預算（Thinking Budget）從固定高配切換到動態自適應限流

Anthropic早在Claude Code文檔中就支持MAX_THINKING_TOKENS和/effort參數。Opus 4.6引入"adaptive thinking"后，服務器端默認把effort從"high/max"下調至"medium（85）"。模型內部有一個meta-decider（元決策器），根據prompt復雜度估算需要多少思考token，然后動態截斷。

推測細節：后端配置文件中，adaptive_thinking_threshold被調低，或引入負載感知的budget_scaler（例如高峰期自動乘以0.3-0.5系數）。日志顯示思考長度"時段性"波動，正好匹配AWS/Google Cloud的動態負載均衡API。

效果：簡單任務不受影響，復雜多文件工程直接"淺思考"，Read:Edit比率崩盤。用戶付的output token（思考也按output計費）反而更多，因為重試循環。

2. 努力等級（Effort Levels）映射到底層算力配額

Anthropic把effort拆成離散等級（low/medium/high/max），每個等級對應不同的內部compute allocation。Medium effort限制總推理步數（steps）或并行CoT鏈數量，強制模型早停（early stopping）。更狠的可能是：服務器端路由部分請求到量化/蒸餾子模型（quantized Opus-lite），對外仍標"Opus 4.6"，用戶無感知。日志中"閱讀上下文不足"正是低比特量化后注意力機制退化的典型癥狀。

3. 負載感知動態配額 + 時段性throttling

后端部署了global rate limiter + per-region budget allocator，根據GPU/TPU實時利用率自動縮減單查詢的max_tokens_for_thinking。峰值時段（5-7pm，美西/全球用戶重疊）觸發throttle_factor=0.4，深夜恢復1.0——這解釋了AMD總監日志的"智商按時段分配"。

4. 輔助優化手段：上下文壓縮 + 采樣策略微調

Context Compaction自動壓縮歷史對話/代碼庫，丟失關鍵細節，導致模型"讀不懂"長上下文。Decoding tweaks方面，默認temperature下調、top_p收緊、top_k限制，減少探索性，輸出更"保守"但也更淺薄、易翻車。

結論與用戶建議

Opus 4.6的"降智"本質是商業成本優化在技術上的完美落地——通過自適應預算、努力映射、負載throttling三板斧，把高階推理的GPU小時從用戶身上摳出來，轉嫁到重試費用和用戶挫敗感上。

開發者應對建議：強制/effort max + CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING；拆解任務（先規劃再執行）；監控自己的thinking長度（用第三方proxy）；或切換到Sonnet 4.6（有時反而更穩）。

AI時代，模型能力不再是"訓練出來"的固定屬性，而是服務器端可實時調節的旋鈕。Anthropic這次把旋鈕往"省錢"方向猛擰了一把，用戶用數據和錢買了教訓。