你把排行榜第一名設成所有工作的預設模型，結果卻可能是：簡單任務變慢、帳單變高，真正困難的任務仍要重試。這不是排行榜失靈，而是它回答了「誰在別人的考卷得分最高」，沒有回答你的問題：AI 模型怎麼選，才能把自己的工作穩定做完？
本篇不再整理一張總榜，而是帶你做一個 10 題小型 Eval：從日常工作抽題、先寫品質 Gate、遮住模型名稱盲測，再把延遲、token、重試與人工修補換成「每件完成成本」。最後，你會得到的不是 Fable、Opus、Sol、Terra 四者的總冠軍，而是一張可以執行的任務路由表。
先校準期待：10 題是本文給新手的最低限度、探索性 smoke test，可能先發現候選差異與流程問題，但不保證抓得到差異，更不足以證明任何模型普遍較強。Anthropic 對初始 agent eval 的建議起點是 20～50 題、取自真實失敗，並對非決定性輸出做多次 trials；正式路由與高風險結果都應擴題重跑。
先說結論：AI 模型怎麼選，只記這條路由公式
任務路由＝Model × Effort × Harness；先過品質 Gate，再比完成成本。
這句話有兩個重點。第一，你實際部署的是一整套設定，不是一個模型名稱；第二，只有品質合格的答案才有資格進入成本比較。一次呼叫很便宜、但最後要重跑三次或花 20 分鐘人工修補，並不是便宜的路線。
AI 模型怎麼選：先分清 Model、Effort、Harness、Eval
許多「體感和 benchmark 相反」的爭論，其實把四個不同層次混在一起。先拆開，你才知道自己究竟在測什麼。
- Model：模型本身，例如
claude-fable-5、claude-opus-5、gpt-5.6-sol、gpt-5.6-terra。供應商的定位只能幫你提出假設，不能直接替你的任務下結論。 - Effort：同一模型在整個回應投入多少工作量，會影響文字、工具呼叫與 thinking。Anthropic 說明
effort是行為訊號，不是硬性的 token 上限；OpenAI 也建議用代表性工作判斷更高 effort 是否值得。兩家的high或max沒有可安全假定的一對一等價關係。 - Harness：包在模型外面的系統，包括 system prompt、工具、context 管理、agent loop、驗證、重試與 fallback。想理解這一層，可先讀什麼是 AI Agent Harness。
- Eval：題庫、資料分布、品質準則與計分方法。它決定什麼叫「成功」，所以同一模型換題目、grader 或 retry cap，就可能得到不同結論。
截至 2026 年 7 月 30 日，Anthropic 將 Fable 5 定位為最高能力、長時間 agent 模型，Opus 5 主打複雜 agentic coding 與企業工作；OpenAI 則把 GPT‑5.6 Sol 定位為旗艦，Terra 定位為能力與成本的平衡。下面是 API 基礎 token 單價快照：Claude Fable／Opus 5 的完整 1M context 使用同一標準單價，OpenAI Sol／Terra 則列 Standard 短上下文價；未計 fast mode、inference geography、cache 與工具費，也不是 ChatGPT、Codex 或 Claude 訂閱額度。最新定位可交叉查看 Claude models overview 與 OpenAI models。
還有一個容易忽略的差異：官方列出的 reliable knowledge cutoff，Fable 5 是 2026 年 1 月，Opus 5 是 2026 年 5 月。最高 tier 不必然等於知識日期最新；需要即時資料的任務，應把搜尋工具與引用驗證放進 harness，而不是只換更貴的模型。
為什麼總榜和實際體感會分岔？MineBench 給了一個好案例
MineBench 3.11.0 要模型輸出 voxel 建築的結構化 JSON。發布頁把新跑的 Opus 5 cohort，與 v3.7 的 Fable 5 舊 cohort 並列；兩者各列 15 件 accepted builds，但不是同版 harness 下的 paired A/B。Opus 作者回報這批資料共 37 次 attempts，US$89.97 除以 37 約為 US$2.43／attempt，其中 12 次是 invalid JSON。Fable 舊 cohort 沒有追蹤 attempts，只能確認 US$54.93 除以 15 accepted builds，約 US$3.66／accepted build；兩者分母不同，不能直接比較每次 attempt 單價。
依兩個 cohort 的公開總額各除以 15 accepted builds，Fable 約 US$3.66，Opus 約 US$6.00，後者在這份快照高約 64%。但只有 Opus 有 attempt telemetry，不能把差距解讀成對稱的 retry-rate 比較。這個案例真正示範的是：若不保存 attempts，就連 cost per completed task 的原因都無法正確歸因。
這個結果也不與其他榜單矛盾。Artificial Analysis 的 Opus 5 測試使用自己的題庫與配置：部分 agentic 測試走 Stirrup，Coding Index 的 Opus 5 xhigh 搭配 Claude Code，部分指標還啟用 server-side fallback；該機構也揭露曾協助 Anthropic 做發布前評估。真正該學的不是「哪一邊才對」，而是 benchmark 的任務分布、prompt、工具、effort、輸出上限、grader 和 retry policy 都會改變系統結果。任何社群或第三方案例都只能代表該日期與 workload，不是普遍勝負。
AI 模型怎麼選：用自己的 10 題 Eval 建立路由
步驟 1：先決定你要比較「模型」還是「可部署系統」
若目標是隔離 model effect，就要盡量固定 prompt、context、工具 schema、endpoint、timeout、max output、retry cap 與 harness；但跨供應商 effort 刻度仍不等價，結論要保守。若目標是選出明天要上線的工作流，則可讓每個候選使用自己的 production harness，測「整套配置誰更適合部署」。
兩種問題都合理，不能混著解讀。用 Claude Code 對 Codex 的結果，是產品與 agent harness 的比較，不是模型權重的純 A/B；這也是閱讀Claude Code vs Codex 實測時最重要的邊界。
步驟 2：從真實工作抽 10 題，不要臨時發明考題
一個容易上手的起步比例是：6 題日常任務、2 題邊界案例、2 題過去曾造成昂貴失敗的任務。以下模板要換成你每週真的會做的內容：
- 結構化抽取：從混亂文件取出 12 個欄位；Gate 是 schema valid、零漏填、不得新增事實。
- 受限摘要：長文壓成 5 點；Gate 是指定事實都保留、不能出現原文沒有的主張。
- 規則分類：依公司規則標記 10 筆資料；Gate 是 label exact match。
- 改寫或翻譯：同時限制字數、語氣與禁用詞；Gate 是限制全過且原意不變。
- 文件比對：找出兩份文件的矛盾；Gate 是抓到預先植入的衝突，並引用兩側證據。
- 有來源的問答：只能依提供資料作答；Gate 是關鍵主張可回指，資料不足時明確說不知道。
- 模糊而可能越權的要求：Gate 是先問必要問題，不直接執行不可逆動作。
- 小型 bug 修復：從 failing test 開始；Gate 是測試通過、diff 最小、沒有 scope creep。
- Diff review：放入 3 個 seeded defects；Gate 是抓到 critical defects，且沒有重大 false blocker。
- 高風險 migration 規劃：Gate 是 dependencies、驗證、rollback 與 approval 齊全，而且不能自行執行。
如果你的工作以程式碼為主，可把第 8～10 題換成真實 repository 任務，沿用大型程式庫安全重構中的測試、最小 diff 與回滾思維。題目來源越接近 production，路由越有用。
步驟 3：看答案之前，先寫好品質 Gate
每題先設一個二元 hard gate：通過或失敗。例如 JSON 是否有效、必要欄位是否齊全、測試是否通過、是否捏造關鍵事實、是否做了明令禁止的修改。Hard gate 沒過，文筆再漂亮都不算完成。
每題再保存一份 known-passing reference answer，先確認 grader 真的會讓它通過。若兩位評分者獨立判斷時常得出不同的 pass/fail，先修題目與 rubric，不要急著測模型；否則最後比較的可能只是 grader 的歧義。
通過後再評軟性品質，建議用 0～4 分檢查正確性、指令遵循、完整性、可驗證性、克制與表達。不要只問「你比較喜歡哪個」，因為冗長答案容易占便宜。OpenAI 的eval best practices也建議優先使用 pass/fail 或 pairwise 判斷，並提醒 LLM judge 有位置與冗長偏誤。
步驟 4：凍結候選設定，再做 model-label-blinded 測試
把每個候選寫成完整配置，例如「Fable 5＋high＋Harness A」或「Terra＋medium＋Harness B」，並記錄 model ID、surface、日期、system prompt、工具、context、max output、timeout、cache、retry 與 fallback。這些條件一改，就是新的實驗。
會修改狀態的 coding 或 agent 任務，每個 trial 必須從同一份 clean snapshot 開始，使用 sandbox、臨時 repository copy 或可丟棄 branch；不要帶 production credentials，跑完要重設檔案、資料庫與 cache。否則後跑的模型可能只是看到前一次殘留狀態。
第一輪做 10 題 × 4 個候選，共 40 次 first-pass runs，只把它當作題目、Gate 與 harness 的 smoke test。每題都重新產生匿名 output ID 並洗牌；runner 私下保存 mapping，judge sheet 不放模型名稱，評分鎖定後才揭露模型、時間與成本。這是 model-label-blinded，不必假裝完全雙盲。
進入路由決策前，把每組前兩名與所有高風險、差距接近的 task × config，從相同 clean snapshot 補到至少 3 個獨立 trials。預算不足時，結果只能標成初篩；想主張類別層級的穩定差異，還要增加同類 production cases。10 題不要報過度精密的統計，直接保留逐題結果。想理解成對 A/B 的實作細節，也可參考Claude Code token A/B 實測。
步驟 5：用試算表記錄「完成一次」的全成本
每個 attempt 一列；trial_id 代表同一題的獨立重跑，attempt_id 則是該 trial 內的 retry。不需要先導入昂貴平台，一張 CSV 或試算表就能開始：
task_id, trial_id, attempt_id, route_id, config_id,
anon_output_id, requested_model, served_model,
gate_pass, final_status, fallback_trigger, failure_type,
wall_time, input_tokens, output_tokens,
thinking_or_reasoning_tokens, cache_tokens, api_cost,
tool_cost, human_repair_minutes, notes另做 route summary，統計 started trials、accepted trials 與 terminal failures。端到端時間要從送出任務算到 Gate 接受成果，包含等待、重試和 fallback；只記第一個 token 有多快，無法回答工作何時真正完成。若 API 有暴露 returned／serving model 或 fallback trace 就保存，沒有則填 unknown，不要精確歸因。Claude 的 thinking 明細位於 usage.output_tokens_details.thinking_tokens，已包含在 usage.output_tokens，計費時不可再加一次；若啟用 server-side fallback，也要記 top-level model 與 iterations trace。
步驟 6：算 cost per completed task，而不是 token 單價
Route 每件完成成本
= 所有已啟動 trials 的全部成本
÷ 在預設 retry／time／human policy 內
被品質 Gate 接受的 trials分子要包含首次呼叫、所有重試、fallback、Gate、工具／基礎設施與人工修補；完成數為 0 時，成本是 undefined，該 route 直接不合格。人工修補若本來就是正式 workflow，可計入 completed result，但仍要另報 model-only first-pass pass rate、最終 completion rate 與 terminal failures，避免把失敗任務藏掉。Token 壓縮有價值，但前提仍是成果通過 Gate；可搭配Claude 如何節省 token閱讀。
把結果寫成任務路由，不要再做一張總排名
完成測試後，不要把 10 題平均成一個冠軍。先為每一題選出「在這批題目與重跑中通過 Gate、且完成成本最低的配置」，再把相近任務分組觀察。10 題分到摘要、抽取、寫作、coding、review 與高風險規劃後，每類往往只有 1～2 題，所以產出的只是暫定 per-task policy；要升級成正式的類別路由，還要加入更多 production cases 與 shadow runs。接著加入四個風險欄位：
- Blast radius：錯了會影響一段文字、一個 repository，還是客戶與金流？
- 可逆性：能不能一鍵回滾？錯誤會不會已送出或寫入外部系統？
- 驗證難度：有 schema、test、引用可自動檢查，還是只能靠專家判斷？
- 時效：允許多長的端到端完成時間？注意，急件也不能跳過 Gate。
你的第一版暫定 policy 可以很簡單；「不可逆、權限、安全、金流」是先於四象限的覆寫條件：
if 不可逆 or 涉及權限／安全／金流:
fail closed
使用已驗證配置 + 硬驗證 + 人工批准
elif 高影響 and 難驗證:
使用實測最強配置 + 獨立 review + 人工批准
elif 高影響 and 易驗證 and 可回滾:
使用通過 Gate 的配置 + 硬驗證 + 回滾機制
elif 低影響 and 難驗證:
使用較強配置，或增加第二個獨立 reviewer
else:
使用在題庫與重跑中通過 Gate 的最低完成成本配置
若沒有配置同時通過 Gate 與 SLA：
回報「無可行路線」，調整範圍或 SLA最後再把自己量到的候選名稱填進去。例如 Terra 可能負責格式抽取，Opus 負責 code review，Sol 負責高風險規劃，Fable 負責長時間 agent；也可能完全相反。把第一版標成暫定，累積更多 trials 後再升級。路由表的價值就在於它能容納「沒有單一總冠軍」這個現實。
Fallback 怎麼寫，才不會便宜模型失敗後反而更貴？
先把兩件事拆開：routing 是任務開始前選路線；fallback 是執行中遇到明確失敗後的處置。下面是你在 harness 自行實作的 client-side quality fallback；Anthropic 的 fallbacks beta 是另一項 refusal-only 機制，不處理 schema invalid、test fail、timeout、rate limit、overload 或 5xx。品質 fallback 與 outage／quota 的 reliability fallback 也應分開統計。
一套容易落地的規則是：
- 只有 schema invalid、test fail、缺引用、超時或指定矛盾未解等可觀察事件才觸發 fallback。
- 純格式錯誤可讓同模型修一次；一般語意、規劃或測試 Gate 失敗，可升級到下一條已驗證路線。
- 安全、越權、不可逆操作或權限邊界失敗要 fail closed 並交人工，不能只換更強模型繼續執行。
- 設定有限 retry budget。第二次仍失敗就停止自動循環，交給人工或回報 terminal failure。
- 強模型 review 的 token、人工等待與前面失敗的成本，都記在原本那條 cheap-first route。
E[Ccheap-first]
= Ccheap + Cgate,cheap + Cmandatory-review
+ P(需要升級)
×（Cfallback + Cgate,fallback + Crework）
另看：
P(Gate 漏接壞答案) × 失敗影響若 reviewer 每次都要看，成本要放在機率項外；P(需要升級) 必須來自重複 route trials，不能採用模型自評信心。選好 cheap-first 與 fallback 後，還要把完整的「cheap → Gate → fallback → final Gate」當成一個候選配置重跑題庫，實測 escalation rate、端到端時間與成本。
如果 cheap-first 的期望成本高於直接走強模型，或完整 cascade 讓端到端時間超出 SLA，就不要為了 token 單價硬走便宜路線。相反地，若有可靠的 deterministic Gate、失敗容易回滾，便宜候選即使偶爾升級，也可能仍是好路由。
AI 模型怎麼選：最常見的 5 個 Eval 陷阱
- 只算一個總冠軍：平均分會掩蓋各類任務的差異。路由要按任務群組決策。
- 看完答案才改規則：這會讓評分追著喜好跑。題目、Gate、權重與 retry cap 都應先凍結。
- 讓模型自己當唯一裁判：LLM judge 可輔助規模化，但先用人類標籤校準；高風險題保留人工覆核。
- 只固定 prompt：工具、context、effort、endpoint、輸出上限、cache 與 fallback 不同，測到的就不是同一條路線。
- 只記首次延遲與 API 單價：真正影響營運的是 Gate 接受前的總時間、所有 attempts、人工修補與 terminal failure。
常見問題 FAQ
1. 10 題真的夠決定 AI 模型怎麼選嗎？
這是本文給新手的最低限度探索，可用來啟動第一版 smoke test，但不保證抓得到差異，更不足以證明普遍優劣。正式路由應擴到 20～50 題、取自真實失敗，並做多次 trials；高風險任務尤其不能只看第一輪。
2. 不會寫程式，也能做這個 Eval 嗎？
可以。用試算表保存題目、A／B／C／D 輸出、Gate、時間與成本就能開始。先用手動盲測理解流程，題庫穩定後再自動化。
3. 四個模型一定要用完全相同的 prompt 嗎？
看問題。隔離模型差異時要盡量相同；選可部署工作流時可用各自最佳 harness，但結論只能說哪個「系統配置」較好，不能全歸因於模型。
4. 不同供應商的 reasoning effort 要怎麼對齊？
不要把名稱當成等量刻度。記下每家確切設定，先以各自建議 baseline 測試，再在同一供應商內做 effort sweep；跨供應商只比較最終品質、完成時間與成本。
5. 可以讓另一個 AI 自動評分嗎？
可以輔助，但要先用一小批人工答案校準，並隨機交換左右順序。Schema、測試與 exact match 優先用確定性 grader；主觀、高風險內容不能只靠單一 LLM judge。
6. 某模型只失敗一次，需要立刻淘汰嗎？
不用。先看失敗類型與風險，再重跑該題。如果是隨機波動可增加 trials；如果是高 blast-radius 的 silent failure，即使只發生一次也應提高 Gate、review 或路由門檻。
7. 訂閱方案的額度能直接換算成 API 成本嗎？
不能直接混算。訂閱通常有產品功能與用量限制，API 則按 token、cache、工具等項目計費。你的試算表要註明使用 surface，否則成本比較沒有共同基準。
8. 任務路由多久要重跑一次？
模型版本、prompt、工具、資料分布或價格有實質變動時就重跑；平時把 production 的新失敗加入題庫。路由應是一套持續更新的測試資產，不是一次性的排行截圖。
新手現在先做這 6 件事
- 從工作紀錄抄出 6 題常見、2 題邊界、2 題昂貴失敗，並為每題保存 reference answer。
- 先寫二元 hard gate、用 reference answer 預跑 grader，不准看完模型答案才補規則。
- 選 2～4 個完整配置，記錄 model、effort、harness、日期與 retry cap；狀態型任務一律用 clean sandbox。
- 做 10 × 候選數的 first-pass runs；4 個候選就是 40 次，每題重新匿名洗牌。
- 把 finalists 與高風險格補到至少 3 trials；先用 Gate 判定 route 是否合格，計算成本仍納入失敗 trials、重試與 terminal failures。
- 按 blast radius、可逆性、驗證難度與 SLA，寫暫定 policy，再把 routing＋fallback 完整 cascade 重跑一次。
把模型比較變成一套會累積的能力
如果你想先補齊底層概念，可從AI 模型如何學習開始；若想看模型、工具與流程如何組成完整工作系統，接著讀AI Agent Harness與如何建立 Agent Harness。也可到 AlphaLab AI 專區查看更多實戰教學。
最後回到本文的錨點：任務路由＝Model × Effort × Harness；先過品質 Gate，再比完成成本。排行榜適合幫你建立候選清單；較有機會幫你省錢、縮短時間並降低失敗風險的，是自己的 10 題起步題庫，以及每次真實失敗後持續長大的路由政策。
想把這套方法延伸到完整 AI 工作流，可瀏覽 AlphaLab 課程，從題庫、驗證到 agent 自動化逐步建立自己的實戰系統。