將模型與提示詞鎖定在版本中：別讓上游悄悄更換引擎，導致你的任務半夜出包

凌晨三點，自動化任務跑了一整夜，儀表板上的解析成功率從 99% 掉到 71%。第一反應是資料來源出了問題，翻了兩小時的日誌才發現，情況相當尷尬：幾天前路由器進行了一次上游資源池遷移，我們一直使用的 `qwen-cloud-plus` 這個別名，被悄悄指向了另一個模型。提示詞（prompt）一個字都沒動，但它背後的權重已經換了。原本穩定輸出 JSON 的結果，開始不時回傳一段自由文字，導致下游那一排 `json.loads` 全在做無謂的重試。

修復它只花了一行程式碼，將別名換成了帶有日期戳記的版本名稱。但這件事讓我意識到，我們一直把「模型」當成一個固定的服務來呼叫，其實它是會漂移的。別名背後指向什麼，由上游決定，而他們更換引擎這件事，通常不會通知你。你以為你在評估、回歸測試、做為最後防線的，都是同一個模型，實際上昨天和今天可能根本不是同一個。

後來我們將三樣東西釘進設定檔中，寫死在程式碼倉庫裡，誰修改誰就要留下記錄。

第一是模型版本。生產環境的任務中禁止出現裸別名，必須寫成 `qwen-cloud-plus-2026-08` 這種帶有快照日期的名稱。想要升級不是隨手修改字串，而是要執行一次對比：使用下面那組固定輸入來執行舊版和新版，將差異拉出來人工審查一遍，通過後才將設定中的指標往前移動。無論上游哪天又更換資源池，頂多是產生一個「新版本待評審」的狀態，而不是讓線上任務自己變成另一個物種。

第二是提示詞本身。提示詞看起來只是幾行文字，其實是核心資產，也是最容易被人隨手「順手優化」然後悄悄改壞的東西。現在每個生產環境的提示詞都有一個獨立的檔案和版本號，修改提示詞等於修改程式碼，必須保留 diff（差異比較），並且需要有人審查。別再讓提示詞只活在某個腳本的字串常數和某人的腦海裡。

第三是我認為最有價值的一條：一組很小的固定輸入集，我們稱之為 golden set（黃金測試集）。就只有十幾二十筆，全是歷史上真實踩過坑或者真實驗證過該給什麼答案的請求，並配上「標準答案」。無論是升級模型、修改提示詞，還是上游被動遷移，任何一項發生時，就把 golden set 整個跑一遍，逐條比對。它是你唯一的、不依賴線上流量的回歸測試尺規——線上樣本會漂移、會帶有業務雜訊，但 golden set 是你自己認定過的基準。

有人會說就十幾二十筆，值不值得專門維護一套基準。我的回答是，解析成功率那兩個百分點的背後，是任務佇列卡到早上九點、人工清理半天所付出的代價。維護 golden set 所花的功夫，是替你把「半夜出包」從機率事件變成基本不可能。

最後這點是踩了坑才補上的：光鎖定版本不夠，還得把它顯性地列印出來。現在任務每次執行時，啟動日誌的第一行就會寫清楚模型版本、提示詞版本、建構時間。出問題時不用猜當天用的是哪一套，一行日誌直接確認。在可觀測性方面，我們之前花了成本上架心跳檢測和告警機制，解決的是「任務有沒有在執行」的問題，而這三項版本鎖定解決的是「執行的是不是我以為的那一套」的問題，兩件事不重疊，都需要具備。

一句話總結：把模型當作會漂移的相依套件來管理，就像管理一個你自己無法控制發版節奏的第三方函式庫。別名是給人用的，版本是用於生產環境的，而 golden set 是你判斷「換過的那個版本到底行不行」的那把尺規。