更好、更便宜的 AI 模型不斷推出。你發布應用程式時選用的模型，幾週後可能已不再是最佳選擇。但如果該模型的 ID 寫在已上架的 iOS 應用程式或已部署的伺服器裡，每次升級就得多跑一次發布流程。怎麼讓應用程式保持最新，而使用者執行的還是舊版本？Haimaker 讓你在不重新部署的情況下更新應用程式所使用的模型。 只要將 haimaker/auto 作為模型 ID 傳送，就能在儀表板中變更預設模型或針對特定提示詞的規則。
這個問題在每次模型發布時都會重演。開發者需要針對自己的工作負載測試品質、成本和能力。將模型選擇抽離已部署的程式碼，就能根據這些結果採取行動，不必另外排一次應用程式或伺服器的發布。
固定的模型 ID 在發布後就會過時
模型 ID 一旦寫死，每次升級模型就得走一遍應用程式的發布流程。開發第一版時這還算好處理，但上線之後，任何值得關注的新模型或價格調整，都可能意味著改程式碼、跑測試、部署伺服器或提交行動更新。新模型隨時可能在兩次發布之間推出。
以 iOS 應用程式為例，嵌入在用戶端的模型 ID 無法為尚未更新的使用者變更。Apple 會在發布前審查應用程式更新，而使用者往往在新版可用後很長一段時間仍停留在舊版。將 API 呼叫移至後端可以避免在應用程式中暴露供應商金鑰，但後端裡硬編碼的模型 ID 依然需要變更設定或重新部署。
僅靠閘道端點也解決不了這個問題。如果請求中指定了固定模型，呼叫端就被綁在那個選擇上。舉例來說，OpenRouter 支援具名模型，也提供了自己的 openrouter/auto 路由器。自動路由器能將底層模型選擇抽離已部署的程式碼。Haimaker 讓你在應用程式上線後，針對自己的提示詞類別調整路由策略。
已部署的應用程式如何跟上新模型？
從應用程式傳送一個穩定的模型 ID，把選擇策略放在 Haimaker。路由器有一個預設模型用於處理未符合規則的請求，另有多條規則可將特定類型的提示詞導向不同模型。路由器綁定在一個 API 金鑰上；當你變更其目標時，後續請求就能到達不同的模型，即使已部署的呼叫端持續傳送 haimaker/auto。
在行動產品中，應用程式應呼叫你的後端，再由後端呼叫 Haimaker，這樣 API 金鑰就不會落在使用者裝置上。伺服器應用程式可以直接採用相同模式：請求程式碼維持不動，由管理人員調整路由器即可。設定文件說明了如何建立路由器、選擇預設模型、指派 API 金鑰並測試請求。
import OpenAI from "openai";
// Run this on your backend; do not bundle the API key in a mobile app.
const client = new OpenAI({
baseURL: "https://api.haimaker.ai/v1",
apiKey: process.env.HAIMAKER_API_KEY,
});
const response = await client.chat.completions.create({
model: "haimaker/auto",
messages: [{ role: "user", content: prompt }],
});
上述程式碼在預設模型變更時不需要改動模型名稱。Haimaker 會快取路由器設定最多 60 秒，因此請預留一分鐘，讓儀表板上的編輯反映到所有後續請求。
先更新預設模型，再將較便宜的工作分流
變更預設模型會升級整體工作負載所使用的模型。規則則讓你在某個新模型對特定任務更便宜或更好時，做更精準的調整。這個區分很重要：一個應用程式可能需要能力強的預設模型來處理長文編輯，同時把簡短的標題建議交給成本較低的模型。這兩個決定都可以在發布後變更，而不需要改動呼叫端的模型 ID。
想像一個寫作應用程式，其後端透過同一個路由器傳送所有 AI 請求。某個新發布的模型在長文編輯上表現更好，團隊測試後便變更了路由器的預設模型。後來，一個更便宜的模型足以勝任標題建議。團隊新增了一條規則，放入諸如「為這篇筆記建議五個簡短標題」和「為這份草稿擬一個簡潔的標題」等範例，再將該規則指向較便宜的模型。仍在使用舊版應用程式的使用者，透過現有後端就能獲得這兩項變更。
使用基於範例的規則時，每個任務建議提供 3 到 10 個具代表性的提示詞。符合條件的請求會被路由到該規則的目標；未符合的請求則使用預設模型。系統會進行能力檢查，防止規則將視覺、工具使用或結構化輸出等請求傳送至不支援的模型。路由日誌會顯示實際路由到的模型及觸發該選擇的規則。關於比對與回退機制的詳細說明，請參閱我們的路由逐步指南和成本路由指南。
這對上線後的團隊有什麼改變？
最大的好處是模型選擇可以配合實際工作負載調整，而不必綁死在發布時程上。團隊可以採用新的預設模型、將重複性的提示詞類別轉移到更便宜的模型，或在效果變差時恢復先前的目標。伺服器程式碼和已安裝的行動用戶端繼續發出相同的 API 請求，工作重心轉移到測試與審查路由決策。
| 上線後的變更 | 程式碼中使用固定模型 | 使用 haimaker/auto |
|---|---|---|
| 出現更好的通用模型 | 修改模型 ID 並發布程式碼或設定 | 測試後直接變更路由器的預設模型 |
| 更便宜的模型適合某一提示詞類別 | 在應用程式中加入路由邏輯並部署 | 為該提示詞類別新增或編輯規則 |
| 模型變更導致輸出品質下降 | 還原程式碼或設定變更 | 恢復先前的路由器目標 |
| 使用者仍在使用舊版行動建置 | 嵌入的模型 ID 無法更新 | 後端可使用目前的路由器策略 |
當伺服器發布有其他無關的工作在排隊時，這點特別有幫助。模型決策不必等那個部署時段。不同的工作負載也可以各自使用獨立的路由器，只要指派不同的 API 金鑰即可；Haimaker 支援每個金鑰一個路由器。
路由變更仍然需要與程式碼變更相同的嚴謹判斷。儀表板沙盒能顯示某個提示詞會被路由到哪個模型，但它無法保證輸出品質。請用具代表性的提示詞測試擬採用的模型、檢查實際輸出、觀察路由日誌，並在品質下滑時恢復先前的目標。Haimaker 改變的是模型選擇；變更提示詞、工具 schema 或應用程式行為，仍然需要應用程式層面的開發工作。
為下一次發布做好模型選擇的準備
建立一個路由器、選擇預設模型，並將它指派給後端使用的 API 金鑰。在請求中傳送 haimaker/auto，然後用幾個代表工作負載的提示詞進行測試。當新模型推出時，先針對這些提示詞評估效果，再變更預設模型或調整特定規則。Haimaker 文件涵蓋了路由器設定、測試沙盒和路由歷史記錄。
新模型可能在你下一次應用程式發布之前就已推出。將模型選擇交給 Haimaker 管理，讓應用程式保持最新狀態，開發者則能把發布週期留給需要新程式碼的變更。
常見問題
如何更換已上架行動應用程式中的 AI 模型？
讓應用程式呼叫你的後端，由後端向 Haimaker 傳送 model: ‘haimaker/auto’。之後你可以在儀表板中變更路由器的預設模型或提示詞規則，無須提交新的行動建置版本。路由器變更最多需要 60 秒生效。
透過 Haimaker 切換模型是否需要重新部署伺服器？
不需要。如果已部署的伺服器已經使用指派給路由器的 API 金鑰傳送 model: ‘haimaker/auto’，你就可以直接在儀表板中變更路由器的模型目標。應用程式提示詞、請求格式或程式碼的變更仍需要一般的部署流程。
可以只將簡單的提示詞導向更便宜的模型嗎？
可以。針對簡單任務新增一條包含 3 到 10 個範例提示詞的規則，並選擇較便宜的目標模型。Haimaker 會檢查目標模型是否支援該請求；未符合任何規則的提示詞則使用路由器的預設模型。