功能做完就能上線？用AI建立Go／No-Go上線準備度檢查表

原內容日期：2026-09-20。本文為既有教學內容補發；範例依原文標示使用，實際權限與規則請以所屬組織核定資料為準。

功能做完，為什麼還不能直接上線？

因為開發完成只代表其中一段工作結束。

使用者是否驗收、資料能否對帳、權限是否正確、第一天由誰支援、問題如何監控、失敗後能否回復，都是正式上線的一部分。

如果這些內容只停留在「應該沒問題」，上線決策就不是基於證據，而是基於希望。

先定義這次上線的範圍

試行、單一部門、平行運行與全面切換，風險完全不同。

一份上線基準要列出包含、不包含、延後與核准例外，也要標記版本與需求凍結日期。需求仍在討論時，真正的問題不是開發速度，而是團隊還沒有共同測試基準。

九個面向缺一不可

上線準備度至少要檢查範圍需求、開發設定、測試驗收、缺陷風險、資料介面、權限合規、教育溝通、維運監控及部署回復。

程式可以運作，不代表使用者知道怎麼做；連線成功，也不代表資料語意與對帳正確。

每個完成都要有證據

「測試完成」「文件完成」「備份完成」都只是狀態文字。

更可靠的做法是附上測試案例、驗收紀錄、版本編號、對帳結果、演練紀錄與責任人。沒有證據時，可以寫「自述完成，待驗證」，不要假裝不確定性不存在。

通過率不是全部

95%測試通過，可能只是測了大量簡單案例，仍缺少最重要的權限、重複操作、介面中斷或回復情境。

報告應同時顯示通過、失敗、未執行、受阻，以及核心流程覆蓋缺口。未執行不能被平均數隱藏。

缺陷要看影響，不只看數量

二十個版面問題，可能比一個會產生重複付款或資料遺失的缺陷低風險。

每個未關閉缺陷都要說明影響對象、核心任務、替代方式、偵測方法與風險接受角色。沒有替代方式的核心阻斷通常不能只靠「上線後再修」帶過。

Conditional Go不是模糊妥協

有條件上線需要明確條件、責任人、截止時間、監控與停止條件。

「先上再密切觀察」沒有說誰觀察、看什麼、多少算異常、何時停止，因此不是真正的控制措施。

回復方案必須能執行

「有問題就切回舊版」沒有回答新資料怎麼處理、誰能下令、如何驗證回復成功，以及使用者何時收到通知。

最好實際演練；做不到時，至少進行桌上推演並記錄未驗證風險。

Go、No-Go之外還有縮範圍

期限固定時，不一定只能在完整上線與延期之間二選一。也可以只開放已驗證功能、採單一部門試行、延長平行運作，或先以只讀模式提供服務。

但縮範圍同樣需要重新確認需求、測試、支援及溝通，不能只是把問題藏起來。

AI整理決策包，人承擔決策責任

AI可以把大量測試、缺陷、待辦與風險整理成準備度矩陣，也能產生Runbook及回復檢查表。

但正式門檻、風險接受與上線核准，仍需由有權限的人做出。成熟的上線決策不是保證零風險，而是清楚知道哪些已驗證、哪些尚未確認，以及什麼情況下必須停止。

文章CTA： 收藏完整提示詞，下次有人問「能不能上線」時，先要求九面向證據，而不是只問開發做到幾成。

逐步操作

步驟 1：先定義「上線」是哪一種上線

同一句「上線」可能指：

• 內部測試環境發布
• 少數使用者試行
• 單一廠區或部門啟用
• 與舊流程平行運作
• 全面正式切換
• 只開放查詢，不開放寫入

先寫清楚日期、範圍、使用者、地點、功能與資料，避免有人以為是試行，另一個人以為全面上線。

步驟 2：確認決策者與建議者

至少分開：

• 上線決策者
• 專案負責人
• 開發負責人
• 測試與驗收人
• 業務或流程負責人
• 資安、法務、品質或財務審查人
• 維運與客服負責人

專案經理可以整理建議，但不能在沒有授權時替決策者拍板。

步驟 3：建立上線範圍基準

列出：

• 本次包含功能
• 明確不包含功能
• 延後項目
• 已核准例外
• 版本或建置編號
• 需求基準日期
• 上線後才處理的改善

如果需求還在變動，上線風險不是「開發慢」，而是基準尚未穩定。

步驟 4：把準備度分成九個面向

1. 範圍與需求
2. 開發與設定
3. 測試與驗收
4. 缺陷與風險
5. 資料與介面
6. 權限、法規與安全
7. 教育、溝通與文件
8. 維運、支援與監控
9. 部署、回復與決策

不要只看程式是否完成。

步驟 5：每個檢查項目都要有完成證據

狀態不能只寫「完成」，應附：

• 測試報告或案例編號
• 驗收紀錄
• 簽核或決議
• 截圖、日誌或版本編號
• 對帳結果
• 演練紀錄
• 教育出席或通知證據

沒有證據的完成聲明，先標示「自述完成，待驗證」。

步驟 6：定義硬性門檻與軟性門檻

硬性門檻可能包括：

• 核心流程可完成
• 無未解決的致命或重大缺陷
• 權限與必要審查完成
• 資料備份與回復可用
• 上線責任人與值班安排確認

軟性門檻可能包括：

• 次要版面優化
• 非核心報表
• 低影響文字調整
• 可用人工替代的便利功能

硬性與軟性標準必須由組織定義，不能讓 AI 自行宣布。

步驟 7：檢查測試覆蓋，而不只看通過率

「95% 通過」可能很好，也可能只是測了大量簡單案例。應同時看：

• 核心正常流程
• 權限與角色
• 邊界值
• 錯誤輸入
• 中斷與重試
• 併發或重複操作
• 跨系統介面
• 資料轉換
• 效能與容量
• 回復與復原
• 使用者驗收

未執行與失敗要分開，不能都算進未通過後用百分比模糊。

步驟 8：把缺陷分成影響，而不是只看數量

每個未關閉缺陷要記錄：

• 會影響誰
• 是否阻止核心任務
• 是否有替代方式
• 是否造成錯帳、資料遺失或安全風險
• 發生條件
• 偵測方式
• 暫行措施
• 修復與驗證時間

20個文字問題可能比1個付款重複或資料遺失問題低風險。

步驟 9：檢查資料與上下游介面

確認：

• 初始資料是否完整
• 轉換前後筆數與金額是否對得上
• 編碼、時區、日期與單位是否一致
• API、設備、檔案或排程是否連通
• 重送、重複、延遲與失敗如何處理
• 舊資料能否查詢
• 回復時新產生資料如何處理

「連線成功」不等於資料語意與對帳正確。

步驟 10：檢查人與流程是否準備好

至少確認：

• 使用者知道何時切換
• 新舊流程差異有說明
• 操作手冊與常見問題可取得
• 現場或遠端支援入口清楚
• 第一線人員知道哪些問題能自行處理
• 升級窗口與服務時間已公告
• 停機、延遲或替代方案已通知

系統可用但人不知道怎麼做，仍不能算完整上線。

步驟 11：設計監控與成功標準

上線後要看：

• 成功交易或完成率
• 失敗、逾時與重試
• 資料差異或對帳失敗
• 使用者求助量
• 核心流程完成時間
• 積壓量
• 設備、介面或服務健康狀態

每項指標要有資料來源、負責人、門檻與查看頻率。

步驟 12：把回復方案寫成能演練的步驟

回復方案至少包含：

• 誰能決定回復
• 何時停止新交易
• 如何備份與保留證據
• 如何切回舊版本或人工流程
• 上線期間產生的新資料如何處理
• 如何驗證回復成功
• 如何通知使用者
• 何時重新嘗試上線

如果沒演練，至少要做桌上推演；「可以回復」不是證據。

步驟 13：準備三種決策方案

Go： 所有硬性門檻通過，剩餘風險在容許範圍。
Conditional Go： 有明確條件、責任人、期限與停止條件，且不違反硬性門檻。
No-Go： 硬性門檻未通過、重大證據缺失或回復不可行。

必要時另提供：

• 縮小上線範圍
• 分批開放
• 延長平行運行
• 只讀模式
• 延期至下一窗口

步驟 14：安排決策會議與截止時間

上線會議應在實際部署前留有修正空間。會議包包含：

• 上線範圍
• 硬性門檻結果
• 未解缺陷與風險
• 測試與驗收證據
• 監控與回復
• 建議方案
• 需要決策的事項

沉默不等於同意；要記錄誰在什麼時間批准哪一個版本與範圍。

步驟 15：上線後設觀察期與結案條件

不要部署完成就宣布結案。設定：

• 加強監控期間
• 每日或每班檢查節奏
• 問題回報與分級
• 成功條件
• 風險解除條件
• 未結改善移交
• 正式結案或轉維運時間

技術部署成功、業務可用與穩定結案是三個不同狀態。

可直接複製的完整提示詞

【角色】
你是一位謹慎的資深專案經理與上線準備度審查助理。你的任務是根據證據整理Go／No-Go決策材料、找出準備缺口、設計替代方案與上線Runbook。你不能替決策者核准上線，也不能把預計完成、自述完成或未發生問題當成通過證據。

【任務】
根據下方專案資料：
1. 確認本次上線範圍、版本、使用者與時間窗口。
2. 從九個面向檢查準備度：範圍需求、開發設定、測試驗收、缺陷風險、資料介面、權限合規、教育溝通、維運監控、部署回復。
3. 分開已驗證完成、自述完成、進行中、未開始、受阻與不適用。
4. 將硬性門檻、軟性門檻與待決策例外分開。
5. 產生Go、Conditional Go、No-Go及縮範圍方案。
6. 建立上線Runbook、監控表、停止條件與回復計畫。
7. 所有判斷都附來源編號與完成證據。

【上線基本資料】
- 專案／功能：[可替換名稱]
- 上線類型：[試行／單一部門／平行運行／全面切換／其他]
- 目標日期與時間：[YYYY-MM-DD HH:mm]
- 版本／建置編號：[填寫／未知]
- 使用者與地點：[填寫]
- 本次包含：[功能或流程]
- 明確不包含：[填寫]
- 舊流程或版本：[填寫]
- 上線決策者：[角色／未知]
- 專案負責人：[角色]

【組織門檻】
- 硬性門檻：[貼上組織既有標準；沒有填「尚未定義」]
- 缺陷分級定義：[貼上／尚未定義]
- 可接受風險核准角色：[填寫／未知]
- 必要審查：[資安／法務／財務／品質／客戶／無]
- 變更凍結時間：[填寫／未知]

【準備度資料格式】
來源編號｜面向｜檢查項目｜負責角色｜目前狀態｜完成證據｜預計日期｜阻礙｜備註
[貼上資料]

【測試資料格式】
測試編號｜類型｜情境｜預期結果｜實際結果｜狀態｜證據｜缺陷編號｜驗證人
[貼上資料]

【未解缺陷與風險】
編號｜類型｜影響對象｜核心任務影響｜發生條件｜替代方式｜目前狀態｜負責角色｜預計處理｜證據
[貼上資料]

【上線與回復資料】
- 部署步驟：[填寫／未知]
- 預估時間：[填寫／未知]
- 監控指標與門檻：[填寫／未知]
- 停止條件：[填寫／未知]
- 回復決策者：[角色／未知]
- 回復步驟：[填寫／未知]
- 資料備份與對帳：[填寫／未知]
- 值班與支援：[填寫／未知]
- 使用者通知：[填寫／未知]

【限制與判斷規則】
1. 僅依提供資料判斷，不假裝執行過測試、部署、備份或回復。
2. 每項結論必須引用來源編號與完成證據；只有口頭聲明時標示「自述完成，待驗證」。
3. 不得把預計日期、進行中或已提交改寫成已完成。
4. 沒有組織門檻時，提出候選門檻供決策者確認，不自行宣告正式標準。
5. 分開硬性門檻、軟性門檻與需核准例外。
6. 測試通過率必須同時說明未執行、失敗、受阻及核心情境覆蓋，不只報百分比。
7. 不得因缺陷數量少就判定低風險；依核心任務、資料、財務、安全、法規、品質與可回復性評估。
8. 不得將「尚未發生」當成風險已排除。
9. 需求、費用、流程或規則尚未定案時，標示範圍未凍結及其下游影響。
10. 提出日期不等於開發、測試、維運及決策角色已承諾。
11. 權限、資安、個資、財務、法規及品質事項缺核准時，不得建議繞過。
12. 回復方案若未演練，標示未驗證；「有備份」不等於可成功回復。
13. Conditional Go必須有明確條件、責任人、期限、監控及停止條件，不能只是「密切觀察」。
14. 若硬性門檻未通過，優先提出縮範圍、分批、平行運行或延期，不得以加班保證補足。
15. 任何加人、取消測試、延長工時或週末支援均需相關角色確認，不自行承諾。
16. 上線決議需記錄決策者、版本、範圍、時間、附帶條件與反對意見。
17. 技術部署成功、業務驗證完成與穩定結案必須分開。
18. 不得責怪個人；以證據、依賴、權責與決策缺口描述風險。
19. 不得輸出密碼、金鑰、內部主機或可被濫用的部署細節。
20. 使用繁體中文，語氣專業、友善、簡潔。

【輸出格式】

一、資料完整性
- 已讀取的來源、測試、缺陷與風險數量
- 缺少的決策、門檻、證據與責任角色
- 目前能否形成建議

二、主管摘要
限180字，說明建議狀態、阻擋上線的前三項缺口、可採替代方案及需要誰在何時前決定。若證據不足，明確寫出。

三、上線範圍基準
| 類別 | 內容 | 版本／來源 | 狀態 | 待確認 |
分類：包含／不包含／延後／核准例外。

四、九面向準備度矩陣
| 面向 | 檢查項目 | 門檻類型 | 狀態 | 完成證據 | 負責角色 | 截止時間 | 缺口影響 |

五、測試與驗收摘要
| 測試類型 | 總數 | 通過 | 失敗 | 未執行 | 受阻 | 核心覆蓋缺口 | 證據 |

六、未解缺陷與風險
| 編號 | 影響 | 是否阻擋核心任務 | 替代方式 | 偵測方式 | 狀態 | 建議處置 | 需誰接受風險 |

七、硬性門檻判定
| 門檻 | 結果 | 證據 | 未通過原因 | 可否以條件替代 | 決策角色 |

八、決策方案
分別提供：
- Go
- Conditional Go
- No-Go
- 縮範圍／分批方案
每個方案列出前提、優點、風險、所需資源、停止條件及對時程影響。

九、建議判定
只能使用：建議Go／建議Conditional Go／建議No-Go／證據不足無法建議。
說明理由，並提醒正式決策由指定角色做出。

十、上線Runbook
| 時間 | 步驟 | 負責角色 | 前置條件 | 完成證據 | 失敗處理 | 通知對象 |

十一、監控與停止條件
| 指標 | 資料來源 | 門檻 | 檢查頻率 | 負責角色 | 超標動作 |

十二、回復計畫
| 觸發條件 | 決策角色 | 停止新交易 | 備份／資料處理 | 回復步驟 | 驗證方式 | 通知 |

十三、上線後觀察期
| 時段 | 檢查項目 | 成功標準 | 問題分級 | 負責角色 | 結案條件 |

十四、決策會議議程
提供30分鐘時間盒，包含範圍、證據、缺口、方案、異議與正式決議記錄。

十五、人工確認清單
列出發布、縮範圍、接受風險、取消測試、加班、回復與結案前必須確認的事項。

建議使用方式

第一次只要求 AI 整理「資料完整性、九面向準備度矩陣與缺口問題」，補齊證據後再產生決策方案。不要一開始就問「可以上線嗎」，否則答案很容易被模糊狀態影響。

實際教學範例

情境：秤量系統標示卡功能準備上線

團隊希望星期六上線。初步安排：

• 星期一前完成流程與欄位定案
• 星期二、三開發
• 星期三、四由兩位測試人員測試
• 星期四回饋修正
• 星期五保留緩衝與部署準備
• 星期六上線

但在星期一上午，仍有以下未決事項：

• 標示卡欄位與列印版面尚未正式核准
• 人工調整重量的權限與原因欄位仍在討論
• 電子秤部分通訊指令尚未完全驗證
• 只有一位測試人員已確認時間
• 沒有完成回復演練
• 上線後第一天支援窗口未公告

AI應整理的準備度

面向	狀態	證據	影響
範圍與需求	受阻	欄位、版面與權限未核准	開發與測試基準可能改變
開發與設定	未開始	等待定案	可用開發時間被壓縮
測試與驗收	部分準備	僅1位測試人員確認	難以同時覆蓋正常與異常情境
資料與介面	高風險疑點	部分秤指令未完整驗證	可能無法正確取得或重送重量
維運與支援	未完成	無第一天窗口	使用者遇阻礙時無明確處理路徑
部署與回復	未驗證	無演練證據	發生問題時回復時間不可預測

不好的結論

只要星期一完成定案，星期二、三加緊開發，星期四測試修正，星期六應該可以順利上線。

問題是：

• 將排程當成完成證據。
• 假設第二位測試人員會到位。
• 沒有處理通訊與回復風險。
• 把「有機會」改寫成「應該順利」。
• 沒有說明何時必須停止硬趕。

建議判定

目前建議：證據不足，暫列 Conditional Go 候選，尚不能正式核准。

必須在星期一結束前完成：

1. 欄位、版面、權限與重量調整規則正式定案。
2. 確認本次上線範圍，未定案功能移出本版。
3. 兩位測試人員確認時段與測試責任。
4. 明確列出電子秤指令的必測清單與阻擋門檻。
5. 指定上線決策者、第一天支援與回復決策人。

若任何一項未完成，應改採縮範圍或延期，而不是繼續壓縮測試。

三種方案

方案A：星期六完整上線

前提：星期一範圍全數凍結、兩位測試人員到位、通訊與回復測試通過。
風險：開發與測試高度重疊，任何重大缺陷都缺少修正餘裕。

方案B：星期六縮範圍試行

只開放已完成驗證的標示卡查詢與列印；人工重量調整、高風險權限與未驗證設備延後。
優點：保留上線窗口，同時降低核心資料風險。
條件：清楚標示限制、提供人工替代方式與支援窗口。

方案C：延期至下一窗口

保留完整範圍，完成通訊、權限、例外、回復及完整驗收。
優點：品質與可維運性較高。
影響：需重新公告時程並處理既有期待。

上線停止條件範例

• 核心秤重資料無法穩定取得或重送。
• 標示卡內容與核准版面不一致。
• 權限可讓未授權角色修改正式重量。
• 重複列印或重送造成資料無法對帳。
• 重大缺陷沒有替代方式。
• 回復步驟無法在窗口內完成。

這些條件需要決策者與領域負責人確認，AI不能自行宣布為正式標準。

常見錯誤、隱私與使用注意事項

常見錯誤

• 把開發完成當上線完成： 還缺驗收、支援、監控與回復。
• 把排程當證據： 寫了日期不代表工作已完成。
• 只看測試通過率： 未執行的核心案例可能被藏在百分比後面。
• 用缺陷數量決定風險： 一個資料遺失問題可能比二十個文字問題嚴重。
• 需求沒凍結仍硬排上線： 下游測試基準持續變動。
• Conditional Go沒有條件：「密切觀察」不是可執行控制。
• 回復只寫一句話： 沒有資料處理、驗證與決策人。
• 假設大家能加班： 人力與週末支援必須明確確認。
• 沉默視為同意： 上線需記錄正式決策者與範圍。
• 部署成功就結案： 業務可用與穩定仍待觀察。
• AI直接替團隊下Go結論： 正式核准必須由有權限者完成。

資料隱私

• 移除帳號、密碼、權杖、內部IP、主機名稱與部署憑證。
• 測試資料避免使用真實客戶、員工、配方、價格或醫療資訊。
• 缺陷截圖可能包含個資或內部路徑，分享前遮罩。
• 上線Runbook可分成一般版與受控技術版，避免過度揭露。
• 使用組織核准的AI環境處理專案資料。
• 對外報告只呈現必要風險，不揭露可被利用的安全弱點。

使用注意事項

• AI只能依已提供的證據整理，不能真正驗證系統狀態。
• 組織沒有門檻時，AI提出的只能是候選標準。
• 涉及財務、品質、法規、資安或安全時，需要專業審查。
• 縮範圍方案仍需重新確認需求、測試與溝通。
• 每次上線後要將實際結果回寫，改善下一次門檻與Runbook。