要用 AI 構建軟件發佈檢查清單，先凍結確切的發佈版本，為每道門禁收集證據，再請模型把這些證據整理成一張可審核的表格。AI 可以揭示欠缺的負責人或前後不一的字眼，但只有問責的發佈負責人才能批准豁免（waiver）或作出最終的 go/no-go 決定。

這個流程比一般的負責任使用 AI 指南範圍更窄。它產出的是針對單次發佈的營運控制，而不是可重用的 SOP、發佈說明、拉取要求摘要或遷移設計。

關鍵要點

把清單綁定到一個 release ID、原始碼修訂版、製品、環境和時段。

讓每道門禁都能以可長久保存的證據回答，而不是憑信心或記憶。

明確記錄負責人、狀態、豁免、停止條件和回滾觸發條件。

不讓 AI 接觸正式環境憑證，亦不讓它聲稱某項測試已通過。

發佈前演練清單，發佈後保存已填妥的紀錄。

甚麼樣的發佈檢查清單才可審計？

有用的發佈檢查清單是針對某項具體變更的決策紀錄。它寫明要發佈甚麼、哪些條件必須成立、由誰核實、證據存放在哪裏，以及條件未達成時怎樣處理。NIST 的安全軟件開發框架（SSDF）建議把安全實務融入每次開發生命週期的實施之中，而不是把安全當作孤立的最後一步。［1］

Google 的發佈工程指引同樣把發佈視為可重複、受控的程序，強調自動化、自助服務和可審計性。其推出指引則強調在擴大影響範圍之前做好規劃、可靠性評審、容量、監察和回滾。［2］［3］這些原則指向一份記錄證據和決定的清單，而不是一堆含糊的提示。

每道決策門禁佔一行：

欄位	它確立甚麼
門禁 ID	方便討論和審計的穩定參考
發佈身份	release ID、原始碼修訂版、製品識別碼和目標環境
要求	二元或邊界明確的條件
證據	測試報告、已簽署的建置紀錄、查詢、儀表板、批准或指令輸出
證據負責人	負責產生證據的人或系統
決定負責人	有權把門禁標為通過或豁免的人
狀態	未執行、通過、失敗、受阻或已豁免
豁免	理由、範圍、到期日、批准人和補償控制
時間戳	證據和決定於何時有效
失敗行動	停止、調查、縮小影響範圍或回滾

當真正的條件是「修訂版 abc123 所需的測試工作已成功完成」時，不要寫成「測試已完成」。後一種寫法人人理解不同；前一種可對照製品核查。

步驟 1：凍結發佈身份和範圍

由一個不可更改的發佈標頭開始。記錄 release ID、程式庫和原始碼修訂版、建置或映像識別碼、目標環境、包含的服務、設定組合、資料庫變更、功能開關、計劃時段，以及問責的發佈負責人。任何身份資料一旦改變，便建立新的清單版本，或明確宣佈受影響的證據失效。

把納入的工作與鄰近的工作分開。一個分支可能包含實驗、文件、產生的檔案，或打算日後部署的變更。清單應寫明被推進的確切製品，而不是假設某個分支標籤便能唯一確定其內容。

這裏亦要把本任務與代碼遷移計劃分開。遷移計劃解釋依賴、相容性、先後次序和架構；發佈檢查清單則回答：已批准的計劃及其證據，是否已為這一次具體的推進準備就緒。

步驟 2：先建證據目錄，再向 AI 提問

只收集已批准而且必要的資料。典型的輸入包括 CI 工作連結、測試摘要、依賴和漏洞報告、製品證明、變更工作單、資料庫遷移演練、運作手冊、警報定義、容量測試結果、功能開關計劃、支援說明和回滾說明。

不要把密碼密鑰、正式環境權杖、客戶紀錄、私鑰、未經遮蓋的日誌或專有原始碼貼進 AI 工具。以穩定的標籤取代敏感值，並保留指向權威內部系統的連結。如果模型需要理解某個失敗，只提供最少量的已遮蓋摘錄，並說明刪去了甚麼。

把每項輸入歸入以下四種證據狀態之一：

已核實： 由指定系統就已凍結的發佈身份產生。
待定： 預期會有，但尚未產生。
不適用： 已排除，並記錄了理由和批准人。
有衝突： 兩個來源不一致，需要調查。

AI 不得把待定或有衝突的證據升級為已核實。NIST 的生成式 AI 設定檔強調了虛構內容、資訊完整性、私隱和人手監督方面的風險；一份行文流暢的清單，並不能證明其中各行都屬實。［4］

步驟 3：按要防止的失敗設計發佈門禁

按門禁要防止的失敗來分組，而不是按負責的團隊分組。這樣跨團隊的依賴便一目了然。

構建與身份門禁

確認製品來自已凍結的原始碼修訂版、必需的建置工作已完成、依賴按預期鎖定、可提供來源證明，而且推進到預備環境的製品與計劃發佈到正式環境的是同一個物件。如果機構會為製品簽署，便記錄驗證結果和驗證人，而不是簽署所用的私密資料。

功能與兼容門禁

連結必需的單元、整合、端對端、回歸和平台測試結果。寫明受支援的版本和重要的向後相容性檢查。針對性的測試可以是有用的證據，但不能把它當作某個無關的完整測試套件門禁已經完結。

安全與私隱門禁

記錄已完成的審查要求、漏洞處置、權限變更、密碼密鑰處理、數據遷移的影響、私隱審查和未解決的例外。掃描工具的結果本身並不代表風險已獲批准；應由獲授權的安全或私隱負責人記錄決定。

運維就緒門禁

確認儀表板、日誌、警報、服務水平指標、值班負責人、容量、速率限制、依賴健康狀況、支援升級路徑，以及能否分辨新舊兩個版本。寫明發佈期間會使用的查詢或儀表板畫面。

部署與恢復門禁

訂明部署前檢查、變更次序、canary 規模、觀察時段、擴大範圍的準則、停止條件、回滾觸發條件、回滾指令或運作手冊、回滾後的數據相容性，以及有權採取行動的人。如果沒有人測試過回滾路徑，或沒有識別出不可逆的數據變更，「可以回滾」這句話並不足夠。

步驟 4：用 AI 構建軟件發佈檢查清單時只給不推斷任務

請 AI 整理所提供的證據，而不是判斷是否準備就緒。一個有用的提示如下：

按所提供的發佈標頭和證據目錄製作一張發佈門禁表。
逐字保留 release ID、修訂版、製品 ID、負責人、來源連結和狀態。
不得推斷任何測試、審查、批准、部署或回滾已經成功。
欠缺證據標為 [PENDING]，有衝突標為 [CONFLICT]。
為每道門禁提出二元要求、所需證據、決定負責人、
失敗行動和需向負責人確認的問題。不得批准豁免或發佈。

要求模型列出各版草稿之間的變更紀錄。如果模型合併了兩行，要求它說明合併了哪些證據參考。如果它加入了一道新門禁，在相關負責人接受之前，該行只屬建議。

AI 亦可把草稿與一份穩定的 SOP 清單比較，但這兩種產物必須保持分開。SOP 解釋反覆使用的方法；發佈紀錄則把這個方法綁定到一個製品和一個決策時段。

步驟 5：固定狀態、例外和權限規則

使用封閉的狀態集合。「大致完成」之類的自由狀態標籤會掩蓋不同程度的風險。一套實用的狀態是 NOT_RUN、PASS、FAIL、BLOCKED、NOT_APPLICABLE 和 WAIVED，並由機構規定誰可以設定每個值。

豁免應包含未達成的要求、理由、受影響的範圍、風險負責人、補償控制、到期日、覆核觸發條件和批准人。絕不能因為無人反對便產生豁免。如果發佈經理無法確定獲授權的批准人，該行便保持受阻狀態。

把證據負責與決定負責分開。CI 系統可能產生測試結果；工程主管可能解釋某個已知失敗；風險負責人可能接受有邊界的例外；發佈負責人作出最終發佈決定。把這四種角色合併到一個含糊的「負責人」欄位，會削弱問責。

步驟 6：把 canary、監控和回滾寫成測試

把每項運維陳述都變成可觀察的條件。例如：

Canary：讓已批准的用戶群組接觸新製品 20 分鐘。
健康：錯誤比率、延遲、飽和度和業務護欄指標都維持在指定門檻之內。
停止：任何嚴重警報觸發，或任何護欄指標超出門檻時，停止擴大範圍。
回滾：執行經測試的運作手冊，確認已恢復上一版本，並核實數據相容性。
升級：證據欠缺、含糊或延遲時，傳呼指定角色。

以上數字只是結構示例；請使用為該服務批准的門檻。AI 不得虛構可接受的錯誤率、canary 規模或觀察時段。這些數值來自服務目標、過往證據和問責的營運人員。

需要對外溝通發佈內容時，把經核實的變更邊界交給另一個發佈說明工作流。面向用戶的說明描述的是影響，不能取代運維就緒的證據。

步驟 7：做冷演練和獨立挑戰

在發佈時段之前，請一位沒有參與草擬清單的人，在非正式或已批准的演練環境中執行清單。他們應能找到每個製品、重現每項檢查、識別決定負責人，並在不依賴私下背景的情況下解釋失敗行動。

最少挑戰以下失敗情況：

某條測試連結屬於較舊的修訂版；
預備環境的製品識別碼與發佈標頭不一致；
某位必需的負責人無法抽身；
某個儀表板沒有新版本的數據；
遷移可以向前執行，但回滾不相容；
某項豁免已過期或欠缺批准人；
某個依賴在審核時健康，卻在推出期間出錯；
canary 看似健康，但一條流量很少的關鍵路徑仍未測試。

記錄更正，而不是悄悄取代歷史。如果拉取要求摘要欠缺背景，便透過 PR 描述流程改善它，再從發佈紀錄連結到經審核的產物。

步驟 8：執行、簽字並保存記錄

發佈期間，只按權威證據更新各行。記錄實際的時間戳、執行人、製品、觀察結果和決定。如果發佈內容改變，便令過時的行失效，而不是把綠色標記沿用下去。

最終的 go/no-go 部分應顯示未解決的失敗、生效中的豁免、回滾準備情況、目前的依賴狀態，以及發佈負責人的決定。部署完成後，記錄實際運行的版本、監察結果、事故、回滾結果（如有使用），以及後續工作的連結。

把已填妥的清單連同其證據參考和變更紀錄一併存檔。範本可以重用，但絕不能照搬上一次發佈的「已通過」狀態。這份紀錄的價值在於，另一位審核人能還原當時已知的資料和決定者。

哪些檢查最容易發現問題？

總結

把清單綁定到一個不可更改的發佈身份。
先收集證據，再請 AI 整理紀錄的結構。
把門禁寫成可觀察的通過／失敗條件，並寫明有權決定的人。
不讓 AI 聲稱測試已通過、批准豁免或作出 go/no-go 決定。
演練 canary、監察、停止和回滾路徑。
保存已填妥的紀錄，作審計和改善之用。

常見問題

發佈檢查清單與 SOP 相同嗎？

不同。SOP 描述反覆進行的流程，而發佈檢查清單記錄的是某一個確切製品在特定時間是否符合其門禁。清單可以引用 SOP，但必須把狀態和證據綁定到發佈身份。

AI 能判斷軟件是否可以發佈嗎？

不能。AI 可以整理所提供的證據、找出欠缺的欄位並提出問題。它無法核實外部工作是否正確執行，無法理解未披露的營運背景，不能接受風險，亦不能作出問責的 go/no-go 決定。

清單需要多少道門禁？

使用能涵蓋重大發佈風險和強制控制的最小集合。當證據、負責人、狀態或失敗行動不同時，便拆成不同的行；只有這些屬性確實相同時才合併。

缺少證據時怎麼辦？

把門禁標為待定或受阻，寫明證據負責人，並訂下限期和失敗行動。不要以舊報告、口頭保證或 AI 產生的文字代替證據。

每個失敗都必須停止發佈嗎？

應由機構政策訂明哪些門禁具阻斷作用，以及誰有豁免權。未達成的強制門禁一直保持阻斷，除非有獲授權並有紀錄的例外；AI 不得判定某個失敗無關痛癢。

數據庫遷移怎樣寫入清單？

引用已批准的遷移計劃、演練證據、相容時段、備份或恢復路徑、向前和回滾指令、負責人以及停止條件。不可逆的操作要明確寫出。

甚麼樣的發佈回滾計劃可信？

它寫明上一個製品、觸發條件、權限、經測試的程序、數據相容性假設、預期恢復時間和驗證步驟。只連結一份未經測試的通用運作手冊並不足夠。

發佈後怎樣維護清單？

保存已填妥的紀錄，記下事故和意料之外的手動步驟，並另行更新可重用的範本。切勿為了令這次發佈看來更整潔而改寫歷史狀態。

來源

NIST, Secure Software Development Framework (SSDF) Version 1.1 — https://csrc.nist.gov/pubs/sp/800/218/final
Google, Site Reliability Engineering: Release Engineering — https://sre.google/sre-book/release-engineering/
Google, Site Reliability Engineering: Reliable Product Launches at Scale — https://sre.google/sre-book/reliable-product-launches/
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 4 日。

用 AI 構建軟件發佈檢查清單，讓每道門禁都有可查證據