AI 多模型大戰第二回合：Gemini 3.1 Pro、GPT-5.6、Claude Fable 5、Opus 4.8，以及 Grok 4.5
上一篇才寫完，版本號已經往前跑
上一篇文章的標題是 Gemini 3 Pro、GPT-5.1 和 Claude 4.5 Opus。當時這三個名字看起來還像是同一個時代的產品，放在一起比較也很自然。
但現在回頭看，這個標題已經有一點歷史感了。Gemini 已經更新到 3.1 Pro，OpenAI 在 7 月 9 日推出 GPT-5.6，Anthropic 公開了 Claude Fable 5，Grok 4.5 也在 7 月正式加入。GPT-5.6 目前分成 Sol、Terra、Luna 三個層級，Claude 這邊則同時有 Fable 5 和 Opus 4.8，已經不是單純把舊模型換一個小數點。
模型名稱的生命週期變得很短。你才剛花時間適應一個版本，下一個版本就已經在產品介面裡等你了。
Gemini 開始像一整套 Google 工作環境
Gemini 3 Pro 時期，我對它最有印象的是視覺理解和多模態能力。到了 Gemini 3.1 Pro，Google 的方向更明顯了：它不只是一個聊天模型，而是同時出現在 Gemini API、Vertex AI、Gemini App 和 NotebookLM 裡。
這個差別其實很實際。當我需要看一張 UI 截圖、整理一份規格、分析文件，或是把很多資料放在同一個脈絡裡時，模型本身的能力只是一半。另一半是它能不能自然地接上我已經在用的工具。
Google 在這一塊有一個很難忽略的優勢。它不一定每次都讓我覺得回答最有個性，但當任務本身和文件、圖片、NotebookLM 或 Google 的服務放在一起時，Gemini 很容易變成順手的那一個。
GPT 的角色越來越像工作流程的中間層
GPT-5.1 時期，OpenAI 強調 adaptive reasoning、no reasoning mode、prompt caching，還把 apply_patch 和 shell tool 放進開發者工具裡。到了 GPT-5.6，重點更往長流程工作、工具操作、文件、試算表、研究和電腦使用移動。
GPT-5.6 的命名方式也有點不一樣。Sol 是旗艦，Terra 比較平衡，Luna 則把速度和成本放在前面。再加上不同的 reasoning effort，使用者選的其實不只是模型名稱，而是要花多少時間和成本把一件事情做完。
這讓我覺得 GPT 的定位有點改變了。它不只是回答問題的模型，也開始變成一個知道什麼時候該想久一點、什麼時候該直接做事的中間層。它可以接工具、看工作狀態，再決定下一步。
Claude 這次不是更新一個版本，而是多了一層
Claude Opus 4.5 原本就很強調 coding、agents 和 computer use。Opus 4.6 把長上下文、程式碼審查和大型 codebase 的處理再往前推，4.7 和 4.8 則繼續改善長時間工作、瀏覽器代理和工具呼叫。
但真正改變比較大的，是 Anthropic 在 6 月推出 Claude Fable 5。Anthropic 把 Fable 5 定位成目前最強的廣泛公開模型，專門處理高難度推理和長時間 agentic work。它加上了安全分類器，讓這種等級的能力可以面向一般使用者發布。
這裡有一個使用上很容易忽略的細節：遇到部分高風險的資安或生物問題時，Fable 5 可能會拒絕，或把請求交給 Opus 4.8 處理。也就是說，使用者選了 Fable 5，不代表每一次回應都一定由 Fable 5 完成。這件事對做測試和算成本都很重要。
我對 Claude 的印象一直不是「它每次都最快」，而是它比較願意待在一個複雜問題裡。現在要再補一句：如果任務夠難，Fable 5 可能是 Anthropic 真正想推到最前面的那張牌；如果遇到安全限制，Opus 4.8 仍然是很重要的 fallback。
Fable 5 在 6 月中曾短暫被撤下，7 月 1 日重新開放。這讓它的發布故事比一般版本更新多了一層現實因素：模型能不能用，不只看技術，也跟政策和部署方式有關。
Grok 4.5 不是來湊人數的
Grok 4.5 在 2026 年 7 月 8 日發布。xAI 把它定位成面向 coding、agentic tasks 和 knowledge work 的模型，並且特別強調它和 Cursor、Grok Build 的整合。這個進場方式很直接：不要只聊天，直接幫你把東西做出來。
xAI 公布的資料裡，Grok 4.5 強調 80 tokens per second，API 價格是每百萬 token 2 美元輸入、6 美元輸出，也把它描述成更省 token 的工程模型。這些數字看起來很有吸引力，但我不會直接把它翻譯成「Grok 已經贏了」。
因為每家公司使用的 benchmark、工具、提示詞和測試流程都不完全一樣。官方數字適合拿來了解廠商想把模型推向哪裡，不適合直接當成一張公平的世界排名。
真正的戰場已經不在聊天視窗裡
這一輪更新最明顯的變化，是模型越來越少單獨出現。Gemini 往 Google 的文件和研究工具裡走，GPT 往 Codex、瀏覽器和專業工作裡走，Claude 用 Fable 5 處理更長、更難的任務，再用 Opus 4.8 接住受到限制的請求，Grok 則從 Grok Build 和 Cursor 切進開發流程。
以前我們會問：「哪個模型回答得比較好？」現在這個問題有點太小了。更接近實際的問法是：哪個模型放進這個流程之後，最少需要我收拾？哪一個可以看懂目前的上下文？哪一個在失敗之後比較容易修正？
模型能力、工具連接、上下文長度、速度、價格，現在幾乎不能分開看。你換一個模型，很多時候其實是換了一整套工作方式。
如果是我現在來選
需要整理文件、看圖、處理 Google 生態系的資料時，我會先想到 Gemini。它的優勢不一定是每一個回答都最好，而是很容易接到我手上的資料。
需要把需求拆開、接工具、處理一般 coding 或代理流程時，我會看 GPT。它現在的方向很明顯，就是把模型放進一個可以做事的環境裡。
遇到大型 codebase、長時間 debugging，或是我希望模型仔細檢查自己做了什麼時，我會在 Claude Fable 5 和 Opus 4.8 之間選。Fable 5 適合更長、更難、可以非同步跑的工作；Opus 4.8 則是比較穩定的通用選項，也可能接手 Fable 5 不處理的高風險請求。
想要快速做 prototype、在 Cursor 或 Grok Build 裡直接試一個想法，Grok 4.5 值得放進候選名單。它的價格和速度看起來很有競爭力，剩下的問題就要靠實際專案驗證。
下一場比賽，不會只看誰的分數最高
我覺得下一階段的差異，會出現在一些很無聊、但真正影響工作的地方：模型能不能連續工作幾個小時、遇到錯誤會不會自己繞圈、能不能少改壞既有功能、失敗之後能不能說清楚自己哪裡錯了。
這些事情不一定會出現在一張漂亮的 benchmark 表格裡，但它們會直接決定一個獨立開發者願不願意把重要的工作交出去。
所以我現在不太想選一個「永遠最強」的模型。比較實際的做法，是讓不同模型負責不同工作，再由人決定什麼結果可以留下來。這不如宣布冠軍來得漂亮，但比較接近我每天真的在用的方式。