把提示、模型與工作流程邏輯綁成同一個 AI 發布版本

一次 AI 發布，應是整套會影響服務行為的設定，而不是單獨一段提示或一個模型端點。即使團隊把模型退回舊快照，新的提示、工具綱要、權限政策、檢索設定或重試路徑仍可能繼續運作；這種「只退一件」的做法，既不能確認事故請求實際用了甚麼，也未必能恢復受測狀態。較穩妥的做法，是為完整候選組合建立單一身份，讓評估、批核、分階段上線、監察及回滾都指向同一套已解析設定。

甚麼才算是一個完整的 AI 發布版本？

完整的 AI 發布版本，是所有足以改變輸出、操作權限、風險、成本、延遲或可觀察性的運行依賴。模型只是其中一項；生產系統還有設定、自動化、驗證、服務基建和監察。NIST 亦把 AI 生命周期活動視為互相依存，要求清點相關組件，包括會實質影響系統的第三方軟件及資料。因此，發布邊界要按實際服務畫出，而非照搬某個產品登錄表的欄位。

• 運行清單應涵蓋提示、已解析模型識別碼與推理參數、工具綱要與權限、政策或護欄，以及檢索或情境設定。
• 同一身份亦要綁定工作流程程式碼、輸入輸出綱要、運行依賴，以及會改變請求處理方式的環境綁定。
• 評估資料集、評分器、準則與門檻通常不在服務路徑執行，但會改變發布決定，故須另行版本化並連接發布記錄。
• 只有能實質影響服務或放行決定的第一方及第三方依賴才需納入；精確邊界由系統特性決定。

組件各自的版本歷史仍然有用，但不能代替發布身份。每當提示、模型快照、有效參數、工具合約、權限、政策、檢索設定、工作流程、綱要、依賴或行為相關環境綁定有變，都應產生一個新候選版本。這樣事故調查毋須從多個登錄系統重組猜測，服務負責人亦能直接回答：當時測試、批核和實際供應的是否同一套設定。

如何把整套行為設定綁進發布清單？

做法是凍結一份不可變候選清單，為每個組件保存可穩定解析的版本、提交編號、產物摘要或內容雜湊，以及實際生效的設定。清單至少要有發布識別碼、建立時間、擁有人、目標服務、狀態、停止條件、回滾負責人及上一個已知良好版本。「production」或「latest」只能當作指標；記錄必須保存它在候選建立時實際指向的目標。

• 對連線、資料或檢索參照、功能旗標、路由限制及其他環境綁定保存身份與核准關係，但不要把密鑰寫入清單。
• 把相容限制、必要遷移及可用供應商條件寫清楚，避免上一版本只在名稱上存在，實際卻已不能接收現時資料。
• 把曝光比例、部署時間、觀察期及每次推進決定放進連結的部署事件，不要為更新流量分配而改寫候選清單。
• 評估套件、評分器版本、結果及批核屬發布封包的證據連結；改動評估關卡要保留新版本及比較基準。

以內部支援助理為例，候選版本 support-assistant-r18 可綁定提示 p-42、模型快照 m-2026-07 及參數、CRM 工具綱要 t-9、權限政策 policy-12、工作流程提交 wf-a71、輸出綱要 reply-6 與運行依賴鎖；發布封包另連接 eval-23 及評分器版本。回滾目標 support-assistant-r17 只有在確認能處理新增的選填到期日和升級欄位後，才是真正可用的已知良好組合。

凡是能改變服務行為，或改變批准該行為所用證據的東西，都要在發布記錄中有一個已解析身份。

哪些證據足以決定候選版本能否推進？

候選版本只有在成文證據支持下，才應獲得推進、暫緩或拒絕的明確處置。發布說明先交代行為意圖、所有變更依賴、受影響情境與介面、權限或可觀察性變化、已知限制、剩餘風險、上線擁有人及相容回滾目標；評估則必須針對可能上線的完整候選組合，而非分開測過提示和模型便假設整合後仍然成立。

• 以現行版本作基準，檢查工作流程特定任務、真實案例、重要分段及罕見但代價高的邊緣情況。
• 獨立檢查合約、服務介面、權限邊界、工具行為、護欄、可靠性、延遲、資源用量及每項完成工作的成本。
• 版本化資料集、評分器、準則與門檻，並由合適的業務或領域人員審核自動評分器及重大失敗個案。
• 不得以一個總平均分掩蓋重要合約、權限、安全、昂貴邊緣情況或關鍵分段的倒退。

每個關卡都要留下證據版本、結果、例外、決定時間及具名負責人。較高風險發布可把變更作者與推進批核人分開，並透過部署保護規則強制取得覆核或外部品質檢查。門檻則須按服務目標和風險訂立；供應商基準、離線測試或自動評分器都不能單獨證明生產安全。

同一候選版本應如何分階段進入生產環境？

同一套已解析候選設定應由低風險環境逐步移到真實流量，期間只改變已批准的曝光安排，不改動候選本身。離線評估與生產觀察互相補足：前者提供可重複比較，後者揭示真實請求、介面和營運條件。有限流量仍可能漏掉罕見失效模式，因此每次推進都只代表證據增加，而不是安全已獲完整證明。

1. 可行時先做影子或非動作式重播，把寫入工具及其他具後果的副作用停用或放入沙盒，切勿盲目重播生產動作。
2. 再讓內部團隊使用完整候選版本，保留必要的人手批核，確認工作流程、工具及追蹤資料符合預期。
3. 把一個固定黏着的生產群組導向候選版本，與現行版本比較任務、安全、工具、可靠性、延遲及成本訊號。
4. 達到服務自行批准的樣本與觀察要求後才擴大曝光，最後才移至全流量，並持續保存帶發布標記的監察證據。

每次部署事件應記錄群組規則、流量分配、開始及觀察時間、結果和處置。曝光量按預先批准計劃增加，可以仍屬同一候選版本；若中途改了提示、模型參數、工具、權限、政策、檢索、工作流程、綱要、依賴或行為相關環境綁定，就要建立新候選並重新取得證據。流量比例及觀察期須按風險、流量、偵測延遲和當值能力決定，不能抄用通用數值。

何時應停止發布，回滾又要恢復甚麼？

安全或政策違反、未獲授權的工具行為、重大合約失效及嚴重可靠性故障，應在曝光前列為硬性停止條件；其他質素、延遲或成本倒退則採用服務自行批准的限制。證據若重大但含糊，可先暫停流量和調查，不一定立即自動回滾，但處置、時限及負責人必須清楚。真正回滾的目標，是完整而相容的已知良好組合，不是孤立退回一個模型。

• 事故前演練流量切換及驗證步驟，並確認舊組合的綱要、狀態、工具合約、路由、遷移和供應商仍然相容。
• 回滾記錄要列出觸發原因、首次發現時間、受影響版本與群組、目標版本、相容檢查、恢復時間及驗證結果。
• 透過帶發布標記的追蹤找出受影響請求、工作流程路徑、工具呼叫及外部動作識別碼。
• 把流量恢復與外部動作補救分開授權、執行和記錄，避免把兩項工作誤當成同一個按鈕。

設定回滾只會阻止往後請求繼續使用問題候選版本，不會刪除已發出的訊息、逆轉資料寫入、取消已完成批核，亦不會自動移除外部系統已建立的工作。這些後果須按另一套獲授權程序處理，包括停止相關動作路徑、核對記錄、修正資料、通知相關擁有人、恢復狀態或執行補償動作；具體方式取決於實際權限、系統和組織規定。

保存哪些記錄，才能日後重建一次 AI 發布？

能供日後重建的最低記錄，是不可變候選清單連同完整證據及決策鏈。團隊須保留已解析組件識別碼與參數、環境綁定、相容結果、評估資產版本與結果、批核、部署事件、流量分配、發現、回滾事件及最終處置。把發布識別碼附加到追蹤元資料，才可把生成、工具呼叫、交接、護欄、時間和結果歸因至實際服務該請求的設定。

• 在供應商提供時，同時保存供應商請求識別碼及應用追蹤識別碼，支援跨系統疑難排解。
• 保存版本、摘要、時間、擁有人、結果和受管制樣本，不代表必須長期留下每段提示、工具輸入、模型輸出或客戶內容。
• 敏感內容的收集、存取、遮蓋及保留應遵從組織資料政策；追蹤完整度不能自動凌駕資料處理要求。
• 記錄最後要讓獨立覆核者重建有效設定、所見證據、批核理由、曝光歷史及停止或回滾決定。

這種成果應稱為「設定可重建」及「決策可重建」，而不是保證逐位元重播。固定模型快照、保存參數或留下內容雜湊，只能減少不明變化；隨機抽樣、託管服務行為及基建差異仍可能令輸出不同。實務上可先採用最小發布封包，只要它能辨認不可變候選版本、版本化評估證據、分階段決定及相容回滾目標；涉及敏感資料、具後果權限、受規管流程或外部動作補救時，則應交由組織內合資格的安全、私隱、法律、紀錄、風險或領域人員判斷。