「可以發佈了」聽起來很直接——直到有人追問：實際上是什麼證明了這件事？ 迴歸套件跑過了，但它通過了嗎？效能檢查過了，是對照哪一個預算？團隊說可以 rollback，但有人演練過嗎？在軟體 QA 裡，這些不是措辭上的小事。「檢查做過了」與「檢查通過了，這裡是證據」是兩種不同的主張。基於前者做出的發佈決定，可以在沒有建立「產品已就緒」的情況下，先建立起信心。

正因如此，發佈檢查清單需要的不只是一排可以打勾的格子。每一項都應該具備三件事：一份別人可以檢查的證據、一位對該檢查負責的負責人，以及失敗時的明確動作。對 AI 功能來說，這件事更重要，因為應用程式可以看起來完全正常，而助手同時產出錯誤的答案、降級得不理想，或消耗超出預期的資源。最後那道關卡要建立的，不只是「團隊做過檢查」，而是「這次發佈滿足它的條件」——而且團隊知道，當線上行為與這些預期矛盾時，該在什麼時候停止。

1. 每一項都需要證據

證據是第三個人可以檢查、或可以用來重複驗證的東西。迴歸檢查應該指向它的 CI 報告；API 契約檢查應該有記錄下來的結果；效能主張應該有延遲與成本的量測支持；rollback 的主張應該指向一份演練紀錄，證明復原真的被測試過。證據也應該對應到正在發佈的那個版本：上週建置的一次成功迴歸，不會自動證明今天的發佈候選版本也通過——尤其當程式碼、prompt、設定或模型版本已經改變的時候。

每一項檢查清單項目還需要一位負責人與一個失敗動作。迴歸失敗，QA 擋下發佈、調查失敗原因，並在修好之後重跑套件。契約被破壞，後端負責人與依賴它的服務確認這個變更是不是預期的。效能超出約定預算，QA 與後端一起決定要不要降量、關掉昂貴路徑，或延後發佈。如果沒有這些後果，一項沒有證據的檢查，最後會變成沒有人可以質疑的綠燈，或沒有人知道該怎麼處理的紅燈。檢查清單只有在它的證據能支撐一個決定時，才有用。

2. AI 功能需要自己的發佈檢查

傳統的發佈檢查可以確認：應用程式能建置、API 有回應、迴歸套件通過。它們不一定能證明：當模型不可用、prompt 被更動、或使用成本超出預期時，AI 功能的行為仍然安全。第一個額外檢查是降級（fallback）行為：當模型逾時、斷路器跳脫、或服務不可用時，使用者實際看到的是什麼？我需要直接測試這些條件，而不是依賴一份設計文件。例如，如果 Aurora Shop 的助手取不回退貨政策，它不應該為了讓對話繼續下去而捏造一個答案；它比較好的做法是說明自己無法確認政策，並提供安全的替代方案，例如把這位客戶轉給真人客服。

其餘的檢查要建立的則是：被發佈的行為，就是被評估過的行為。prompt 版本必須對應到它的黃金集結果，團隊才知道上線的是哪一個 prompt、以及正是這個版本通過了必要的評估。新的 prompt 版本必須觸發相關的迴歸測試，而不是承襲前一版的通過資格。成本控制需要類似的證據：單次對話上限、每日總量上限，以及斷路器跳脫時的行為，都必須事先設定並驗證。最後，抽樣觀察必須在發佈前就位：誰來審看線上樣本、他們看哪些訊號、樣本存在哪裡、以及如何去識別化。這些檢查把 AI 特有的風險變成明確的發佈條件，而不是等客戶碰到了、團隊才發現的問題。

3. Canary 驗證：用一小片流量問問題

通過發佈檢查清單，不代表團隊應該立刻把新版本暴露給每一位使用者。Canary 發佈讓變更先接觸一小片流量，讓團隊在擴大暴露之前先觀察它的行為。關鍵在於：在 rollout 開始之前，就把驗證協議寫下來。這份協議應該陳述：要監控哪些訊號、觀察窗持續多久，以及哪些條件成立時必須停止 rollout。對 AI 助手來說，相關訊號可能包括錯誤率、延遲百分位數、每次對話成本、降級頻率，以及審樣產出的品質指標。

停止條件必須具體到在壓力之下仍然可以執行。「留意不尋常的延遲」是一個觀察，不是一條可執行的規則。更可執行的例子是：「若 p95 延遲連續五分鐘超過約定上限，停止 rollout，並在增加流量之前先行調查。」實際的門檻應該來自產品的效能需求與實測基準線，而不是在事故中當場拍出來的一個任意數字。同樣的原則也適用於 AI 品質：如果審樣發現未經授權的動作或嚴重的政策違反，團隊需要一套事先定義好的昇級與停止程序。Canary 不只是一次比較小的部署；它是一個受控制的決策點，站在「有限暴露」與「擴大發佈」之間。

發佈檢查清單 v1

上面的表把「發佈就緒」變成一組可以驗證的義務，四個欄位分別指出每個項目、它的證據、負責的負責人，以及檢查失敗時要求的動作。它涵蓋了迴歸套件、API 契約、效能與成本預算、rollback 就緒度、降級行為、prompt 對黃金集的對應、成本上限與斷路器，以及線上抽樣。分配好的負責人——QA、後端、SRE，或共同負責——讓「誰該交出證據」變得清楚。同樣重要的是，失敗欄防止檢查清單止步於「提醒」：迴歸失敗就擋發佈、未測試的降級必須先修好、缺少成本控制就擋部署直到設定完成。

兩條補充規則補完這份清單。第一，任何被標記為「不適用」的項目，都需要書面原因與簽署人的核准，這樣團隊就無法悄悄跳過一項不方便的檢查。第二，在 canary 期間，觀察結果應該每天更新，並且必須有一位被指名的人擁有喊停的權限。這兩條規則合起來，讓檢查清單成為一份發佈決策紀錄，而不是一個形式。另一位審查者應該能夠檢視證據、理解例外情形、確認每一項檢查歸誰負責，並判斷團隊為什麼繼續或停止。

檢查清單是一種控制手段，不是保證

這份檢查清單會隨著新的失敗模式出現而成長，但每一項都有維護成本，而清單越長，越容易被橡皮圖章式地蓋過。它還有一個盲點：canary 只會顯示你選擇去觀測的訊號，永遠不會顯示你從來沒為它建立訊號的失敗模式；而一小片流量，也代表不了長尾使用者。一次發佈可以通過所有列出的檢查，卻仍在一個沒被測過的場景中失敗；一次成功的 canary，也無法保證每一位使用者都會有好的體驗。解法不是無限增加檢查清單的項目，而是維持一組聚焦而有意義的檢查、定期回顧它們的證據是否仍然反映當前的風險，並在線上環境暴露出缺口時改進監控。「可以發佈」應該意味著：團隊驗證了它知道如何量測的風險、記錄了仍然不確定的部分，並且明確了當證據說停的時候，誰會出手。