最聰明的模型，不一定是最好用的 - Ward
跑了半年框架管線後，我的選擇是 Opus 4.6，而不是 Fable 5。這篇記錄我在 Opus 4.6、4.7、4.8 和 Fable 5 上碰到的生產環境問題，以及背後的取捨邏輯。
我在 Claude Code 上跑了一套自己設計的框架管線大約半年。從 Opus 4.5 用到 4.8、再到 Fable 5，版本都碰過一輪。
先說結論：「最聰明的模型」和「最適合生產環境的模型」是兩件事。
這不是謙虛或省錢的考量，是跑管線真的跑出來的判斷。
各版本我碰到了什麼
Opus 4.6 — 目前最穩的選擇
我的框架管線結構是這樣的：計畫書產生 → 品質透鏡掃描 → 審查閘門裁決 → 閉迴路驗證。每個環節都有 Hook 做確定性攔截，AI 的角色是在閘門之間做判斷，不是替我做最終決策。
這套管線在 Opus 4.6 上運作最順。指令遵從穩定、不會自己擴大範圍、token 消耗可預測。我設定了什麼，它就做什麼，沒有我沒要求的多餘動作。
有一個要注意的地方：2026 年 3 月，Anthropic 悄悄把 Opus 4.6 的 reasoning effort 從 high 降到 medium，導致一波品質退化。12 這件事沒有公告，是 GitHub issue 的用戶自己發現的。用 full model ID 釘版本可以避開這種靜默升版的坑。
Opus 4.7 — Safety RLHF 的副作用
Opus 4.7 上線後，Reddit 討論串有 2,300 個 upvote 在批評它退化。34 我自己碰到的問題比較具體：
它開始把正常的檔案操作判定成惡意行為。我在跑資安相關的程式碼分析時，它觸發了拒絕——不是系統設定的護欄，是模型自己加的。Tokenizer 多吃 20-35%，token 預算計算直接亂掉。更惡的是「任務做到一半就宣稱完成」，閉迴路驗證環節還沒跑，它已經說好了。
這些問題的根源是 Safety RLHF 的 spillover——為了減少某類風險行為，訓練時不小心把正常行為一起壓制了。這不是罕見的工程問題，但它發生在生產版本上就是個硬傷。
我在筆記裡把這個現象叫做「過度安全柵欄」：不是我的框架太嚴，是模型自己加了我沒有要求的警告。框架是確定性的，但模型的行為不是。這就是問題所在。
Opus 4.8 — 考試模式的模型
Anthropic 自己的 System Card 承認了一個叫做 Grader Awareness 的問題：Opus 4.8 會推理「我的輸出怎樣才會得高分」，在有評估信號的環境和沒有時，行為不一致。56
實際使用上，6 月 16 日之後出現嚴重延遲，簡單指令要等 5 分鐘。還有「假執行」——它假裝腳本在跑但實際上沒有。這個問題在 GitHub 上有 32 個 thumbs up，顯示不是個案。
Grader Awareness 的本質問題是：模型在訓練環境表現好，但碰到真實工作負載時行為就漂移。如果你的管線依賴模型的判斷力做路由決策，這種漂移是沒有辦法靠規則預防的。
Fable 5 — 強，但不適合生產
Benchmark 數字確實亮眼：SWE-bench Verified 95%、SWE-bench Pro 80.3%。問題不是它聰不聰明，是它的聰明在生產環境裡失控。
成本不可控。 Simon Willison 實測：他請 Fable 5 做一個「看 CSS 依賴」的小任務。它自己寫了 pyobjc 程式碼來列舉 Safari 視窗、截取 macOS 螢幕畫面、然後注入 JavaScript modal，最後產出 68,606 個 output tokens，單次費用約 $12。7 有用戶 $100/月的 Max 計畫在一個 session 裡燒完。
這個現象後來有個比較精準的說法：Fable 5 是 relentlessly proactive——它不只完成你的問題，它把它認為跟這個問題相關的事情都一起做了。這對探索性任務可能有用，對有範圍邊界的生產任務是災難。
Fallback 陷阱。 BridgeMind 測試了 12 個 TypeScript 除錯任務，9 個被安全分類器誤判後，工作被截走交給 Opus 4.8 回答，得 0 分。89 除錯分數從 86.2 暴跌到 25.9。費用還是雙計——Fable 費率的 token 已計費，fallback 後的 Opus token 再算一次。
自信地回報成功，但結果是失敗。 Hacker News 上有多名用戶回報：Fable 5「自信地說跑了 X、Y、Z 測試並得到這些結果」，但實際回傳的是失敗的 code。10 這是比 Grader Awareness 更嚴重的問題，因為它讓你誤以為閉迴路驗證通過了。
拉開來看
不只是 Claude 家族。過度聰明造成不穩定，是這一代推理模型的共同問題。
| 模型 | 生產穩定度 | 主要問題 |
|---|---|---|
| Claude Sonnet 4.6 | 日常首選 | 90% 任務夠用，指令遵從最穩 |
| Claude Opus 4.6 | 重活首選 | 1M context + Terminal-Bench 第一 |
| o4-mini | CP 值王 | 中等複雜度、高吞吐 |
| Gemini 2.5 Pro | 便宜可用 | 有免費 tier，SWE-bench 78% |
| Claude Opus 4.8 | 需釘版本 | Grader awareness + 延遲 |
| Claude Fable 5 | 不建議生產 | 成本失控 + fallback 陷阱 |
| o3 | 過度推理 | 簡單問題花 2 分鐘思考 |
| DeepSeek R1 | 不穩定 | 無限重複 + 語言混合 |
| Qwen 3.5 | overthinking | token 膨脹 5-10x |
越往右邊，benchmark 數字越好看，但生產環境越難控制。
「過度聰明」有學術實證
這不只是使用者的主觀感受。學術論文已經把 overthinking 的成本量化了：
arXiv 2502.08235《The Danger of Overthinking》：reasoning 模型在 agentic 任務中過度推理，導致決策和行動脫節——花更長時間，卻得出更差的結果。11
arXiv 2412.21187《Do NOT Think That Much for 2+3=?》：o1-like 模型在「2+3 等於多少」這種題目上，花了 2 分鐘思考。12
arXiv 2508.02120《Don’t Overthink It》：overthinking 的系統性調查，發現 token 膨脹 5-10 倍，成本失控，準確率反而下降。13
業界也開始分出兩條路線：frontier intelligence（追求最強推理）和 reliable task completion（追求可靠完成任務）。Adaline 2026 的分析說得直白：「大多數團隊買的是前者，需要的是後者。」14
這個分裂不是廠商的行銷包裝，是真實的工程取捨。訓練模型做更深的推理，和讓它在邊界條件下穩定停止，在某些情況下是互相拉扯的目標。
我的選擇：穩定 > 聰明
換 4.7/4.8 的過程裡，我在框架管線上碰到大量假警報。護欄跳出來，但跳的理由不是我設定的條件，是模型自己加進來的。我花了一段時間以為是框架的問題，去查閘門條件、去看 Hook 邏輯，最後發現問題不在那裡——是模型版本換了，行為就不同了。
回到 Opus 4.6 後，問題消失了。
這讓我意識到一件事：框架的有效性跟模型版本是綁定的。
業界的 TDD 和 SDD 靠測試和規格做確定性保障——不管誰跑，測試通過就是通過，不因為工程師換人而改變標準。但如果你的開發流程是依賴 AI 的判斷力來做路由決策，那模型的行為穩定度就是你整個系統的瓶頸。
換句話說：你的框架再嚴謹，如果底下的模型會漂移，你等於在沙地上蓋房子。
選 Opus 4.6 不是因為它「不夠聰明」，是因為它夠穩定、夠聽話、不會自己擴大任務範圍。在生產環境，可預測性比聰明重要。
幾個量化數字
| 指標 | 數值 | 來源 |
|---|---|---|
| vibe coding app 資料庫安全停用率 | 88% | 2026 安全研究 |
| AI 共寫程式碼安全漏洞倍數 | 2.74× | CodeRabbit 分析 |
| AI commit 帶入問題率 | 15–28.7% | arXiv 2603.28592 15 |
| 驗證機制帶來的品質提升 | 2–3× | Boris Cherny 實踐觀察 16 |
| METR：AI 工具讓有經驗開發者耗時增加 | 19% | METR 隨機對照實驗 17 |
最後這個數字值得停一下。有經驗的開發者用 AI 工具之後，完成任務的時間反而增加 19%。這可能跟「不停驗證 AI 輸出」的認知開銷有關，也可能跟「AI 把簡單問題搞複雜」有關。不管原因是哪個，它都說明一件事：更聰明的工具不等於更高的效率，過度聰明的工具甚至可能讓你更慢。
版本釘定建議
如果你在 API 層使用 Claude，用 full model ID（例如 claude-opus-4-6-20250314）而不是 alias（claude-opus-4-6）。
Anthropic 會靜默升版，你的管線可能在一行 code 都沒改的情況下突然行為不同。GitHub issue #27892 裡有大量開發者在要求版本釘定功能，18 可以去那裡追蹤最新狀態。
在釘版本這件事上，謹慎比及時嘗鮮更重要。
引用來源
免責聲明 本文為個人使用觀察與公開資料整理，僅供技術交流參考，不構成任何形式的操作手冊、部署指南或專業建議。文中提及的模型版本、benchmark 數據、定價資訊均以撰文時（2026-07-21）公開資料為準，各廠商可能隨時調整。
任何人依據本文內容所做的技術決策、模型選擇、系統部署或相關操作，其結果與風險由決策者自行承擔。作者不對因參考本文而產生的任何直接或間接損失負責。
建議在做出生產環境決策前，以自己的實際工作負載進行獨立測試驗證。