Opus 4.8 是榜首，但不該成為預設模型

Claude Opus 4.8 在 Nate 的基準測試拿下第一，但它不該成為所有工作流的預設模型。

Claude Opus 4.8 是 Nate 目前基準測試裡的第一名，但我仍不會把它設成每個工作流的預設。它的 strict-average 81 分，明顯高於 GPT-5.5 的 71 分，確實把多數對手甩開；但真正重要的不是排行榜，而是它最強的地方剛好是專業 AI 工作最常失手的環節：來源紀律、可追溯性、操作判斷、自我修正，以及知道何時該停下來，不再假裝一個髒問題已經被乾淨解掉。這代表它是重大升級，不代表它能當萬用解答。

第一個論點

Opus 4.8 拿下第一名，不只是因為它會寫得更像人，而是因為它把高風險工作裡最無聊也最關鍵的部分做得更好。Nate 的拆解指出，它在 source discipline、canary handling、provenance 和 self-correction 上，都比 Opus 4.7 更強。這些不是裝飾性提升，而是模型輸出會不會變危險的分水嶺：一個看起來很完整、其實證據鏈斷掉的答案，一個把資料問題蓋過去的修補方案，或是一份表面漂亮、實際隱藏不確定性的摘要。

如果模型真的改善了這些地方，它降低的不是打字錯誤，而是審查成本與決策風險。這也是為什麼 81 分有意義：它不是單純代表更聰明，而是代表更少需要人類事後補洞。對研究、法務、產品決策、內部審核這類工作來說，這種提升很值錢。

第二個論點

但分數高，不等於該成為預設。Nate 的測試也顯示，GPT-5.5 雖然 strict-average 只有 71 分，卻在 Artemis 的 visualisation 任務上贏過 Opus 4.8。這提醒我們：多數團隊需要的不是「全場最強」模型，而是「某一類工作最適合」的模型。如果你的日常輸出偏向視覺、前端、或 artifact-heavy 任務，那麼一個總分更高的模型，並不能直接證明它應該成為預設。

另一個更大的警訊來自 Andon Labs 的結果：在長時間線的 business benchmark 上，Opus 4.8 的 max effort 表現，反而比 high effort 更差，而且兩者都輸給 Opus 4.7。這不是邊角案例，而是對「把推理開到最大就會更好」這種直覺的直接反駁。更強的推理，有時會帶來漂移、額外複雜度，甚至更差的結果。也就是說，模型可以同時更驚人、也更不實用。

反方可能怎麼說

最強的反方觀點很簡單：既然 Opus 4.8 是基準測試第一名，那就應該直接標準化，別再浪費時間做模型路由。預設模型能降低認知負擔，減少團隊混亂，也避免每次都靠主觀偏好選模型。若一個模型在審查品質上持續最好，那最安全的組織策略，就是全面採用它，接受多一點成本或延遲。

這個論點不是空話。對重視正確性勝過吞吐量的團隊來說，單一預設也能讓文件、 prompt 設計與評估流程更一致。大家都用同一個模型，團隊就更容易建立可重複的工作流，也更容易比較結果。在組織很亂的情況下，一致性本身就有價值。

但這個論點最後還是敗在同一個地方：工作類型。Nate 的例子已經顯示 Opus 4.8 並非全域最佳，而 Andon Labs 的測試更證明，推理強度拉高不一定帶來更好的長任務結果。預設模型只有在跨越所有工作型態都夠穩時才合理；Opus 4.8 不是那種模型。它適合來源敏感、判斷密集、需要反覆校正的任務，不適合視覺工作、長鏈 agent loop，或任何比深度推理更重視速度與狀態維持的流程。

你能做什麼

如果你是工程師、PM 或創辦人，別再問哪個模型贏了排行榜，改問它最常在哪種失敗模式裡出錯。把 Opus 4.8 用在 provenance、修正、判斷最重要的任務：研究整理、審查、模糊分析、高風險修改。把 GPT-5.5 或 Codex 留給更偏 artifact、視覺、執行導向的工作。長時間 agent loop 先不要預設 max reasoning，先在你自己的任務上做小規模測試，再決定是否標準化。真正有效的工作流，不是同一個模型包辦一切，而是一組模型分別處理你最不能接受的錯誤。