為生產環境選 AI 模型，不是一個“本週誰排在榜首”的問題。它是一個約束問題，而大部分答案你其實已經知道。先把六件事寫下來——任務型別、上下文長度、輸入模態、互動形態、可控性，以及對成本結構的敏感度——再用一小套取自你自己流量的自測收斂出選擇。本指南講為什麼榜單做不了這個決定、六條模型選擇標準、一個下午就能拼出來的最小黃金集，以及一張按任務族和模型型別組織的決策表。
為什麼榜單做不了你的生產模型選擇
基準測試衡量的是固定 prompt、固定條件下的一個平均任務。你的生產請求不是那個東西。它有自己的輸入分佈、自己的 prompt 結構，以及對失敗特有的容忍度，而這些沒有任何公開評測會共享。
這個差距在轉譯那一步就露出來了。一個公佈的分數告訴你某些模型在別人的測試集上得了多少分；它沒法告訴你你的任務是變好還是變差，因為你的任務從來不在那個測試裡。讀任何公佈數字時有一個有用的習慣：問它量的是什麼任務、用的是哪個 prompt 版本、什麼時候跑的、誰控制了那套設定。這些問題答不上來，數字就是裝飾，你還是得回到自己的約束和自己的測試。而且任何分數背後的條件都過期得很快：prompt 會變、版本會滾、各出版物之間的評測框架也不一樣，一個看不到日期和方法的分數是故事，不是證據。這一切並不讓評測變得無用，只是讓它成為別人的評測——這也正是為什麼任何模型選擇流程的最後一步，都是你自己跑、用你自己的輸入跑。
實際結論是：把榜單當作發現、初篩和建立詞彙表的訊號，把生產模型選擇當作一個由你自己收尾的約束匹配問題。初篩階段真正重要的能力，在源頭就有文件，各家的模型頁面就是這些規格所在的地方，OpenAI 的模型文件就在其中：模型接受什麼、返回什麼、為什麼場景設計。
先寫下來的六條模型選擇標準
在開啟任何對比頁面之前，先回答這些。六條裡有兩條——上下文視窗和模態限制——淘汰候選最快，所以要早點用。漏掉任何一條，你會在一個季度內把整個選擇重吵一遍，通常還發生在生產流量已經跑在你選的那個模型上的時候。
第一：任務型別。生成、抽取、分類、程式碼，還是多輪工具呼叫。怎麼判斷：分類真實的工作負載，而不是 demo。一個主要在抽取欄位的聊天功能，就是穿著聊天外衣的抽取任務，它的標準要按抽取來。
第二：上下文長度。典型輸入有多大，最壞情況又有多大？怎麼判斷：在真實請求上量，而不是手挑的樣本。決定性的問題是：一整個工作負載能一次裝下，還是必須切塊；一旦切塊進場，你就有了一個流水線問題，沒有任何模型能悄悄吸收掉。
第三：輸入模態。純文本、有圖片進來，還是要生成或編輯圖片？怎麼判斷：審計實際到達的東西。大廠當前所有模型都能處理文本和圖片輸入，Anthropic 的模型概覽就對其產品線說得很直白；但生成和編輯位於不同的端點、有不同的限制；如果你的產品會碰到它們，就先把模態當作硬性過濾條件。
第四：互動形態。離線批處理還是即時互動，隨之而來的延遲敏感度有多高。怎麼判斷：找出誰在等輸出，以及他們等更久時什麼會壞。夜間流水線和即時自動補全面對的是同一個模型問題，但這條標準一旦寫下來，答案就截然不同。
第五：可控性。結構化輸出的穩定性、工具呼叫的可靠性，以及可復現性。怎麼判斷：往下游看。如果解析器、schema 或自動化要消費這個輸出，那麼穩定性就是硬要求而不是偏好，而且在大多數日子裡它的優先順序高於能力。
第六：成本結構敏感度。不是一個數字，而是一種形狀：你的請求是輸入重還是輸出重，是否會重複，結果能不能快取，工作負載是批處理還是互動式？怎麼判斷：讀你自己的流量構成。兩個團隊做同一個功能，可能因為一個是把長文件送進去、另一個是把長文件拿出來，而落在不同結構上。
用最小黃金集收斂
六條標準寫下來之後，初篩出兩三個候選，然後用你處理其他所有生產決策的方式來定奪：用一小套取自真實資料的測試。
從真實流量裡抽十到三十個有代表性的樣本，並且刻意把那些彆扭的也放進去：最長的輸入、最奇怪的格式、讓人提了 bug 的那個案例。對每個樣本，對可接受的輸出形狀寫一條斷言：這個欄位存在、這個結構合法、這種拒答不出現、這個引用格式被遵守。斷言勝過感覺，因為它們可以顯式地失敗。
讓每個候選跑同一套集合，然後比較兩件事：有多少斷言通過，以及更有用的——失敗是如何分佈的。一個模型在格式上失敗、另一個在內容上失敗，這告訴你你的產品能容忍哪一種失敗。用完全相同的輸入重跑一遍，以捕捉不穩定和格式漂移，因為一個只在隔週的週二才成立的選擇不算選擇。把黃金集控制到可維護的規模：幾十個精心挑選的樣本，只要有任何變化就重跑，勝過每個季度從頭重建的宏大評測套件，因為真正抓到漂移的是重跑。這與我們相容性清單裡的“上線前先驗證”是同一種紀律，只不過從端點行為換成了模型行為。
決策表：任務族與模型型別
下表把任務族對映到應當優先考慮哪一類模型。是型別而不是名字，因為名字會輪換、版本會退役，而工作的形狀比任何具體模型都保持得更久。編碼用哪個模型、長文件用哪個，也不是一個有唯一答案的問題；表裡把它們分開，是因為它們的約束畫像不同。
| Task family | Priority type | The constraint doing the deciding |
|---|---|---|
| Summarization and rewriting | Lightweight-efficient or long-context | Volume and input size; interactive if users wait |
| Long-document analysis | Long-context | One-pass coverage versus chunk-and-merge pipeline |
| Code generation and review | Reasoning-heavy with strong tooling | Structured output and edit correctness |
| Structured extraction | Controllable structured-output, multimodal when inputs include images | Schema stability is the product |
| Multi-turn tool calling | Reasoning-heavy with reliable tool use | Failure behavior across turns |
| Low-sensitivity batch (drafts, tagging) | Lightweight-efficient | Cost structure and throughput shape, no human in the loop |
當你從型別下沉到具體的模型名字時，用活的清單而不是記憶：你平臺上的GET /v1/models會返回當前的陣容，平臺文件解釋了怎麼讀它。由提供商自己寫的模型目錄——Google 的平臺模型頁面就是一例——才是你在為某個條目投入一套黃金集之前，確認它接受什麼的地方。
組合與替換，不必大動干戈
一個有韌性的安排，給每個任務族最多兩個候選：一個主用、一個備用，兩者都通過黃金集，兩者都通過同一套整合可達。為每個任務族追一個唯一贏家，正是團隊最後落得一打整合、卻不知道哪一個在承載生產流量的原因。把結論寫進團隊已經在放決策的地方，並把黃金集結果附上；那份筆記才是資產，它決定了下一次替換是一個下午，還是一次事故。
替換遵循與選擇相同的紀律。當某個版本退役，或某個候選不再通過它的斷言時，用黃金集對著替代者重跑，而不是相信變更日誌，然後再次讓失敗型別來做決定。保持工具側配置可移植的機制，見我們關於一把 key 通用於多個編碼工具的配置指南；完整生命週期視角——通知視窗、別名層與回滾——見模型遷移手冊。
一頁紙就能讓這件事保持誠實：寫下六條約束，抽樣，寫斷言，跑候選，讀失敗型別，記錄結論。六列筆記勝過任何分數表格，因為每一條都能映射回你真實擁有的某個需求。
有些替換不是可選的：退役日期一到，關停彙總就是確認哪個快照停止工作、由什麼接替的地方。
接下來讀什麼
- 看看模型選擇如何嵌入更完整的工作流。 把研究、寫作和評審分派給不同模型，就是本指南的邏輯在整個流水線上的應用。
- 順著產品這條線讀下去。更多關於模型與平臺選擇的文章在產品指南裡。
按約束選擇，用測試收斂，並記錄原因。榜單會繼續變；下個季度你的約束還在那兒。