AI 供應商驗收教學：別把「已交付」直接當成「驗收通過」

10月 23, 2026

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

供應商說「做完了」，先別急著簽驗收

供應商寄來一封信：「五項需求皆已完成，請協助驗收。」附件是一張更新清單，狀態全部標綠色。這時最容易發生的錯誤，是把對方的完成聲明直接複製到驗收單，再補一句「功能正常」。

交付與驗收其實是兩件事。交付代表供應商提供了某些成果；驗收則代表這些成果符合約定的範圍、標準與證據要求。中間還隔著版本核對、測試、缺陷判斷、文件移交與授權決策。

AI 很適合協助整理這些資料，但使用方式不該是問「這份可以驗收嗎？」而是要求它建立一條可以回查的證據鏈。

先確認本次驗收基準

同一個專案可能同時存在報價單、需求訪談、Email 補充、會議紀錄及變更單。第一步是確認哪些已正式核准、哪個版本是本次基準，以及哪些明確不在範圍內。

沒有這一步，就可能把未核准的想法強加給供應商，也可能漏掉已核准的變更。

每項需求都要連到交付與測試

一條完整追溯鏈應該是：需求來源與版本、驗收標準、交付模組、測試案例、實際結果、證據位置及驗收狀態。

如果供應商說功能完成，但找不到對應測試；或測試通過，卻不知道它對應哪項需求，都不應直接判定正式通過。

版本對不上，證據就不能直接沿用

測試環境使用候選版，正式環境安裝最終版，是常見情況。兩者可能只差建置標籤，也可能包含新的修正。應要求差異清單，並依風險決定是否重新執行關鍵測試。

「應該一樣」不是驗收證據。

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

十個文字或排版問題，也許可以列入 Punch List；一個讓報表錯帳或權限失效的問題，則可能阻斷驗收。每項缺陷都要說明影響對象、發生條件、可否偵測、替代方式及修正計畫。

人工替代也不是免費。它可能增加工時、引入新的錯誤，甚至無法長期持續。

別忘了「程式以外」的交付

安裝文件、操作手冊、帳號權限、備份還原、監控告警、教育訓練、授權與支援窗口，都可能是能否安全接手的關鍵。

功能跑得動，但只有供應商知道怎麼設定，這個系統還不算真正移交。

五種驗收狀態比二選一更實用

除了通過與不通過，還可以有附條件通過、部分驗收及待補件。重點是每一種狀態都要明確寫出範圍、排除事項、補正期限與關閉證據。

至於這些狀態是否觸發付款、保固或其他商務效果，必須回到合約及授權流程，不能讓 AI 或驗收表上的模糊文字自行決定。

實例：五項功能完成，為何仍不能正式驗收？

某生產管理系統維護版包含五項功能。三項有畫面證據，但其中一項匯出尚未測試；一項舊資料出現空白；另一項只有口頭聲明，手冊也未更新。更重要的是，測試使用候選版，正式交付包是另一個版本標籤。

此時合理狀態不是「全部失敗」，也不是「全部通過」，而是「部分技術測試完成／待補件」。接著以 Punch List 管理版本差異、匯出測試、資料補救、功能證據與手冊更新。

驗收文件要說清楚它的效力

收到檔案、完成安裝、技術測試通過、商務付款條件成立與保固開始，不一定是同一天，也不一定由同一個人決定。

簽署前要明確寫明：本文件只是收件確認、部分技術確認，還是正式驗收。這一行往往比整張表的綠色狀態更重要。

AI 最適合做的是整理與質疑：找出追溯斷點、版本矛盾、未測項目及缺少證據。是否接受風險、啟動付款或放棄進一步修正，仍要由真正有權限的人做決定。

行動邀請：拿出最近一份驗收單，找出其中所有「正常、完成、沒問題」。每一個詞後面，是否都有可回查的案例與證據？

逐步操作

步驟 1：先確認「這次到底驗收什麼」

寫清楚：

專案、維護案或採購案名稱
本次驗收批次
系統、模組、設備或據點
需求版本與凍結日期
合約／報價／變更單編號
本次包含與不包含範圍
預計付款或結案里程碑

「某版本更新」不是足夠範圍。驗收對象應能對應到明確需求及交付物。

步驟 2：蒐集六類基準文件

至少整理：

合約、報價或工作說明書
核准的需求與驗收標準
正式變更紀錄
供應商交付清單與版本說明
測試、部署與問題紀錄
付款、保固及維護條款

Email 或聊天中未正式核准的想法，不能直接變成供應商義務；同樣地，已核准的變更也不能因沒寫在最初報價就被漏掉。

步驟 3：建立需求追溯矩陣

每項需求記錄：

需求編號
來源與版本
核准狀態
驗收標準
對應交付項目
對應測試案例
實際結果
證據位置
驗收狀態

只要有任何一欄斷裂，就應列為追溯缺口，而不是直接判定通過。

步驟 4：核對交付版本與環境

確認：

產品／模組版本
建置編號或發布標籤
資料庫結構版本
設定檔版本
韌體或設備版本
安裝日期與時間
測試、正式環境差異
部署人與核准單

測試的是 v2.6.0.3，不代表正式環境裡的 v2.6.0.4 自動通過。

步驟 5：區分收件、安裝、測試與驗收

建議使用不同狀態：

已收到交付物
已完成安裝
已完成基本啟動檢查
已執行測試
測試通過
附條件驗收
部分驗收
正式驗收通過
不通過／退回補正

簽收快遞、確認檔案可開啟或系統能登入，都不是完整驗收。

步驟 6：把驗收標準改寫成可觀察結果

避免：

系統穩定
報表正常
效能良好
操作方便

改成：

使用指定角色登入，可完成某流程並留下指定紀錄
報表在指定資料條件下顯示哪些欄位與計算結果
於定義的資料量及環境下，回應時間符合核准門檻
錯誤輸入時顯示正確訊息，不建立錯誤資料

如果原需求沒有可測標準，AI 可以提出候選寫法，但不能追溯性地宣稱它已成為合約條件。

步驟 7：設計最小但完整的測試集合

至少涵蓋：

正常流程
不同角色與權限
邊界值
無效與缺漏資料
重複送出或併發操作
歷史資料與既有功能回歸
匯入、匯出及報表
介面、設備或第三方串接
中斷、重試與復原
稽核軌跡及時間戳

測試數量多不代表覆蓋完整；應優先覆蓋高影響流程與容易失敗的交界面。

步驟 8：記錄「預期、實際、證據」

每個測試案例至少包含：

前置條件
測試資料
操作步驟
預期結果
實際結果
通過／失敗／受阻／未執行
執行人與日期
截圖、日誌或紀錄位置
缺陷編號

「工程師說已測過」只能算資訊，不能取代可核對的驗收證據。

步驟 9：對未解缺陷做風險分級

每項缺陷評估：

影響誰
是否阻斷核心流程
是否造成資料錯誤、遺失或安全問題
發生條件與頻率
是否能被偵測
是否有可接受的人工替代方式
修正日期與責任人
是否會影響付款、保固或正式使用

缺陷數量少不代表可以驗收；一個會造成錯帳的問題可能比十個版面問題重要。

步驟 10：檢查非功能性交付物

不要只驗程式，還要核對：

安裝與設定文件
操作及管理手冊
系統架構與介面文件
帳號、角色與權限清單
備份、還原及回復程序
監控與告警設定
教育訓練與出席紀錄
授權、憑證與到期資訊
原始碼、部署包或託管條件（若合約要求）
保固、維護及聯絡窗口

步驟 11：決定驗收型態

常見選項：

正式通過：所有硬性標準與必要交付完成。
附條件通過：剩餘事項不阻斷使用，且有明確補正、期限與保障。
部分驗收：只有可獨立使用且範圍清楚的部分通過。
待補件：功能可能完成，但文件或證據不足，暫不判定。
不通過：核心標準未滿足或風險不可接受。

驗收型態與對應權利、付款效果必須依合約及組織授權確認，不能由 AI 自行決定。

步驟 12：建立 Punch List

每項未結事項應有：

編號
類型：缺陷／文件／設定／訓練／測試／資料
影響與風險
責任人
預定完成日
複測方式
關閉證據
逾期處理或升級方式

避免只寫「後續優化」，因為沒有完成標準的項目很難真正關閉。

步驟 13：分開簽收、驗收、付款與保固

確認四件事是否為同一事件：

收到交付物
技術驗收通過
商務付款條件成立
保固／維護期間開始

不同組織與合約可能定義不同。驗收文件應清楚寫明本次簽署的效力，不要用模糊的「確認無誤」一次包辦所有效果。

步驟 14：設定觀察期與重開條件

正式使用後才可能出現：

尖峰效能問題
真實資料例外
長時間連線中斷
權限與稽核問題
特定設備或介面不穩

定義觀察期間、監控指標、問題回報方式、停止條件及何種事件可重開驗收。

步驟 15：由有權限的人複核並簽署

至少確認：

技術／使用者測試人員
業務流程負責人
專案負責人
商務、採購或財務（如涉及付款）
資安、品質或法務（如適用）
正式驗收核准者

參與測試的人不一定有權放棄缺陷修正、改變合約範圍或核准付款。

可直接複製的完整提示詞

【角色】
你是一位資深專案驗收經理、品質保證顧問與商務風險整理員。你要依據合約、核准需求、正式變更、交付版本與測試證據協助建立驗收包。你不替任何人接受缺陷、變更合約、放棄權利、核准付款或簽署驗收。

【任務】
請根據我提供的資料：
1. 確認本次驗收範圍、基準版本與排除項目。
2. 建立合約／需求／變更／交付／測試的追溯矩陣。
3. 區分已收件、已安裝、已測試、已通過、附條件、部分驗收與未通過。
4. 檢查版本、環境、部署時間與證據是否一致。
5. 找出缺少驗收標準、測試覆蓋、文件、帳號、教育、備份及移交項目。
6. 整理缺陷、偏差、未測項目與風險；標示是否阻斷驗收。
7. 比較正式通過、附條件通過、部分驗收、待補件及不通過。
8. 建立 Punch List、複測與關閉證據要求。
9. 分開說明技術驗收、付款、保固與結案可能受到的影響。
10. 產出驗收單草稿、主管摘要及供應商回覆信。

【案件基本資料】
- 案件名稱：[名稱]
- 客戶／部門：[代碼或去識別名稱]
- 供應商：[代碼或去識別名稱]
- 合約／報價／工作說明書編號：[編號]
- 本次驗收批次：[批次]
- 驗收日期與時區：[YYYY-MM-DD，時區]
- 驗收地點／環境：[測試／正式／現場]
- 需求基準版本與日期：[版本]
- 交付版本／建置／韌體：[版本]
- 本次付款里程碑：[若未知填未知]
- 保固／維護起算規則：[若未知填未知]
- 有權核准驗收角色：[角色；未知請填未知]

【需求與交付資料格式】
每項一列：
- 項目編號：
- 來源文件／版本／頁次：
- 核准狀態：已核准／提案／未知
- 需求或交付內容：
- 驗收標準：
- 本次是否包含：是／否／待確認
- 供應商完成聲明：
- 對應版本／模組：
- 對應測試案例：
- 證據位置：
- 備註：

【測試資料格式】
- 測試案例編號：
- 對應需求：
- 前置條件與測試資料：
- 操作步驟：
- 預期結果：
- 實際結果：
- 狀態：通過／失敗／受阻／未執行
- 測試版本與環境：
- 執行人與日期：
- 截圖／日誌／紀錄位置：
- 缺陷編號：

【缺陷與未結事項格式】
- 編號：
- 類型：功能／資料／權限／效能／文件／訓練／設定／介面／其他
- 說明：
- 影響對象與流程：
- 風險：安全／法規／金錢／資料／營運／使用體驗
- 是否阻斷核心流程：
- 替代方式：
- 修正責任人：
- 預定完成日：
- 複測與關閉證據：

【限制與判斷規則】
1. 只能依提供資料整理，不得虛構測試、工時、版本、期限、費用或核准狀態。
2. 供應商的「已完成」只是聲明，除非有驗收證據，不能直接標示通過。
3. 收件、安裝、啟動、測試、技術驗收、商務付款與結案必須分開。
4. Email 或口頭要求若沒有正式核准，標示為範圍爭議／待確認，不自動納入合約。
5. 正式核准的變更不得因原合約未列而遺漏。
6. 測試版本、交付版本與正式環境不同時，不得推定結果可直接沿用。
7. 未執行、受阻與失敗必須分開，不能合併成未通過比例。
8. 缺陷是否可接受，必須由有權限者依風險與合約決定。
9. 不得因存在人工替代方案，就自動判定缺陷不阻斷驗收。
10. 不得將附條件或部分驗收改寫成全面正式通過。
11. 不得自行推論驗收簽署會啟動付款、保固或權利拋棄；依合約標示待確認。
12. 涉及法律、採購、稅務、資安、品質或法規時，提醒交由相應專業角色複核。
13. 個資、客戶名稱、價格及系統敏感資訊要去識別。
14. 每個結論附來源或證據；證據不足時標示未知／待補件。
15. AI 輸出是驗收草案，不是正式簽署文件。

【輸出格式】
A. 30 秒驗收摘要
- 本次驗收範圍
- 證據完整度
- 主要缺陷／阻塞
- 建議狀態與信心
- 需核准者決定事項

B. 文件與版本一致性檢查
| 項目 | 應有基準 | 實際資料 | 一致／不一致／未知 | 影響 | 待辦 |

C. 需求追溯矩陣
| 需求編號 | 來源與核准狀態 | 驗收標準 | 交付版本／模組 | 測試案例 | 結果 | 證據 | 狀態 |

D. 測試覆蓋摘要
| 面向 | 已測內容 | 通過 | 失敗 | 受阻 | 未執行 | 關鍵缺口 |

E. 缺陷與風險表
| 編號 | 問題 | 影響 | 嚴重度候選 | 替代方式 | 是否可能阻斷 | 修正／複測 | 決策者 |

F. 非功能性交付檢查
涵蓋文件、設定、帳號、備份、監控、教育、授權、部署包、保固與窗口。

G. 驗收方案比較
| 方案 | 可接受範圍 | 排除／保留事項 | 付款／保固影響：依已知條款或待確認 | 風險 | 適用條件 |
方案包含：正式通過、附條件通過、部分驗收、待補件、不通過。

H. 建議與人工決策點
- 建議狀態及理由
- 不能由 AI 決定的事項
- 最晚決策日期
- 建議參與角色

I. Punch List
| 編號 | 類型 | 未結事項 | 責任人 | 完成日 | 複測方式 | 關閉證據 | 逾期升級 |

J. 驗收單草稿
包含案件、範圍、版本、測試摘要、未結事項、驗收狀態、保留條款、附件與簽署角色。明確區分簽收與正式驗收。

K. 可直接傳送的文字
1. 給主管／核准者：結論、風險、選項與需決定事項。
2. 給供應商：缺口、證據要求、補正期限與複測方式，語氣專業不對立。
3. 給內部測試團隊：尚待執行的案例與證據要求。

L. 結案與觀察期計畫
- 觀察期間
- 監控指標
- 問題回報管道
- 重開驗收條件
- 保固／維護追蹤項目

M. 人工確認清單
只列會改變驗收、付款、保固、範圍或風險判斷的問題，依優先順序排列。

【待分析資料】
[貼上去識別後的合約摘要、需求、變更、交付清單、測試與缺陷資料]

可替換欄位快速表

[案件名稱]：專案、維護案或採購案名稱
[驗收批次]：避免把不同交付混在一起
[需求基準版本]：本次真正用來判定的需求
[交付版本]：程式、資料庫、設定與韌體版本
[付款里程碑]：只填已知條款，不要猜測
[有權核准角色]：區分測試者、簽收者與驗收核准者
[待分析資料]：先去識別再貼入

實際教學範例

情境：生產管理系統維護版本驗收

供應商交付 v2.6.0.4，聲稱完成五項工作：

異常單增加異常機台顯示
生產進度報表修正預計狀態選單
生產進度報表增加忽略狀態
報表新增訂單編號與廠內單號，預設隱藏
增加進階顯示模式

已知資料：

原需求版本為 v2.6.0.3，第 2 項後來由資料庫設定直接調整。
測試環境安裝的是 v2.6.0.4-rc2；正式交付包標示 v2.6.0.4。
第 1、3、4 項有截圖；第 5 項只有供應商口頭表示完成。
第 4 項尚未測試匯出 Excel 是否包含新增欄位。
第 3 項在舊資料上出現一筆狀態空白，原因未確認。
操作手冊仍是舊版，沒有進階顯示說明。
合約摘要顯示驗收後進入付款流程，但是否允許附條件驗收未提供。

AI 整理後的追溯摘要

項目	證據狀態	驗收判斷草案
異常機台顯示	測試截圖與案例齊全	可列技術通過候選
預計狀態選單修正	已在資料庫調整，但缺正式變更與回歸證據	待補件／補測
忽略狀態	新資料通過，舊資料有空白異常	尚有缺陷，需評估影響
新增兩欄	畫面通過，匯出未測	部分測試，不能全面通過
進階顯示	無測試及截圖；手冊未更新	證據不足

不能直接簽正式驗收的原因

測試版與正式交付版標識不同，缺少差異與重測說明。
第 5 項沒有測試證據。
第 4 項的匯出行為尚未驗證。
舊資料空白可能影響報表正確性。
手冊未更新，非功能性交付不完整。
附條件驗收對付款的效果尚未依合約確認。

建議處理方式

先列為「待補件／部分技術測試完成」，而非正式驗收通過：

供應商提供 rc2 與正式版差異清單或重新以正式版執行關鍵回歸。
補測第 4 項畫面、匯出及權限情境。
補交第 5 項測試案例、證據與操作手冊。
釐清舊資料空白的影響、修正與資料補救方式。
由採購／財務確認部分或附條件驗收是否觸發付款。

可直接寄給供應商的文字

感謝提供 v2.6.0.4 交付包。目前第 1 項已有完整測試證據；其餘項目仍有版本、匯出測試、舊資料異常及文件更新等缺口，因此現階段先記錄為「部分技術測試完成」，尚不等同正式驗收通過。請協助提供 rc2 與正式版差異、補齊第 4、5 項測試證據及新版手冊，並回覆舊資料空白的處理方案。資料齊備後，我方將安排複測；正式驗收與付款效果仍依合約及授權流程確認。

Punch List 範例

編號	未結事項	責任角色	關閉證據
P01	`rc2` 與正式版差異未說明	供應商開發	差異表＋正式版建置資訊
P02	新增欄位匯出未測	雙方測試	正式版測試結果＋匯出檔
P03	舊資料狀態空白	供應商開發	根因、修正、資料補救及回歸結果
P04	進階顯示缺證據	供應商測試	案例、截圖與結果
P05	操作手冊未更新	供應商 PM	核准版手冊與版本日期

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

常見錯誤

供應商清單直接變驗收結果：完成聲明仍需對照證據。
登入成功就算系統通過：還要驗核心流程、權限、資料與復原。
測試版本不一致仍沿用結果：需有差異分析與風險判斷。
只記缺陷數量：應看核心流程、資料、安全與可偵測性。
人工替代就自動接受：替代方式也有工時、錯誤與持續性成本。
把部分驗收寫成全部通過：範圍及排除項目必須明列。
簽收人代替核准者：收件、測試與商務核准可能是不同角色。
驗收後才補文件：文件、設定、帳號與教育本身可能就是交付物。
Punch List 沒有關閉證據：會變成永遠的「後續優化」。
AI 補造空白欄位：未知就標示未知，不能自動生成期限或工時。

資料隱私

客戶、供應商、人名與聯絡方式使用代碼。
合約金額、付款條件及報價內容依授權範圍揭露。
不上傳密碼、私鑰、API 金鑰、正式資料庫連線或個資樣本。
截圖遮蔽帳號、客戶資料、訂單與設備識別碼。
日誌先移除權杖、IP、路徑及敏感參數。
使用公司核准的 AI 服務與儲存位置。

使用注意事項

本方法是專案與品質管理輔助，不是法律、會計或採購意見。
合約解釋、付款、扣款、保固起算與權利保留要由相應角色複核。
涉及 GMP、資安、職安或其他法規時，依正式程序增加審查。
AI 讀到截圖描述不等於已執行系統；關鍵測試需人工操作並留證。
任何修正應先在合適環境測試，避免直接在正式環境驗證破壞性情境。