排隊才是真正的成本
Descript 在打造影片編輯 agent「Underlord」時，遇到一個典型的工程排隊問題。團隊原本直接整合 OpenAI、Anthropic 和 Google 三家供應商，並自己寫 fallback 邏輯。每新增一個模型，工程上要花兩小時，但要把這兩小時排進工程師的行事曆，卻要等上好幾天。結果一個有潛力的模型，可能放了一週還沒人知道值不值得追。
真正貴的不是那兩小時，而是等待本身。團隊只會測試「值得打斷工程師」的模型，其他的一律跳過。這讓模型選擇變成一種特權，而不是日常的探索。
用 Claude Tag 把評估變成一句話
Descript 的 AI 產品負責人 Aleks Mistratov 描述現在的工作流程：他在散步時看到新模型的消息，直接在 Slack 說「用 OpenRouter 跑這個模型的 evals」，一兩小時後評估結果就出來了。背後用的是 Anthropic 的 Slack 整合 Claude Tag，它會自動執行評估、開 pull request，再由人類審核批准。
關鍵在於，測試模型不再需要先建立供應商整合。不用開新的 vendor 關係，也不用接另一個 API endpoint。工作還是有，但不再需要「拜託」工程師。這讓評估從排隊問題變成一個可自動化的參數。
每週多次評估改變了什麼
Descript 現在一週會評估模型好幾次，大部分測試的模型最後沒有上線。但這帶來了三個具體的改變。
第一，模型選擇變成實證導向。團隊用自己的測試案例衡量新模型，只有當新模型真的超越現有選擇時才換。以前的做法是早早選定一個模型，之後除非被迫，否則不重新評估。
第二，新模型發布不再是「事件」。最近一次 Anthropic 發布，Descript 從公告到上線只花了兩小時。剩下的步驟都是內部的：跑評估、決定是否勝過現任模型、加進模型選擇器、部署。大部分工作來自 Descript 自己的程式結構，而不是與模型的連線。
第三，可測試的範圍變廣了。Descript 從未直接整合 xAI，但 Grok 4.5 現在已經在 production 上運行，走的是跟其他模型一樣的路徑。
測試與上線用同一套整合
這不代表把所有流量都丟到一個共享 endpoint 就完事。Descript 會帶自己的 key 到 Baseten，為 open-weight 模型建立專屬部署，並讓 OpenRouter 優先路由到 Baseten，其他供應商則作為 fallback。這些 fallback 只換推論供應商，模型本身不變，所以某個主機掛掉時，回答的模型不會跟著換。
Mistratov 給其他工程師的建議很直接：「這比試著搞懂所有不同的連線簡單多了。你做一次，其他都只是參數。」Descript 用同一套整合來測試新模型，也用來運行正式採用的模型。測試是找到模型的方式，路由設定則是運行模型的方式。
對產品團隊的啟示
Descript 的案例點出一個常見的盲點：模型評估的瓶頸往往不在模型本身，而在於「誰有權限嘗試」。把整合層抽象掉之後，評估變成一個可以隨時觸發的動作，產品團隊就能用更低的成本探索更多選項。這跟我們之前討論過的 AI 工作流延遲的三個層次 有相似之處：先分清瓶頸在哪一層，才能對症下藥。
當然，這套流程的前提是團隊已經有自己的評估 harness 和測試案例。如果沒有，自動化只會放大混亂。Descript 的經驗是，先有可重複的評估標準，再談加速。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。