AI 說完成，誰說了算？用 Acceptance Criteria 把需求寫成可以驗收的成果

專題編輯：Adrian Hsu｜企業 AI 策略編輯

下載需求驗收卡（ZIP，內含 Markdown）

驗收條件的目的，是減少各說各話

想像企業主管說：「請增加案件管理系統的優先級篩選。」工程師可能完成一個下拉選單；客服主管希望能依高、中、低優先級找到案件；營運主管則還希望未選擇篩選條件時，所有案件保持原來的排序。三個人都認為自己講得清楚，卻對「完成」有不同理解。

驗收條件是特定需求或使用者故事必須符合的可判定條件。Atlassian 將它與 Definition of Done（完成定義）分開：驗收條件聚焦單一需求對使用者的預期行為；完成定義則是團隊共同遵守的品質標準，例如測試、文件和審查。兩者都重要，但不能互相取代。參考：Atlassian Acceptance Criteria、Agile Alliance ATDD。

壞需求與好需求，差別不是字數

「系統要好用」、「畫面要美觀」、「AI 分析要準確」這些敘述缺乏判斷標準，可能各自引發無限次修改。相對地，「使用者選擇高優先級時，列表僅呈現高優先級案件」、「當 API 逾時，顯示可理解的錯誤且不改動既有資料」可以設計出明確測試。

好的驗收條件應描述期望結果，而非綁死工程師如何實作。除非技術選擇本身是安全或法規要求，否則不必把每個按鈕的程式語言和函式名稱寫成需求。這樣既能保留實作彈性，也能降低「照做了，卻不是我要的」爭議。

用 Given／When／Then 寫一個可測試情境

以案件管理系統為例，可採下列情境格式。這裡的系統和資料都是教學假設，非既有企業系統的實測：

需求：新增「優先級篩選」
Given：使用者已登入，且有權查看的案件中包含高、中、低優先級
When：使用者選取「高」並套用篩選
Then：列表只顯示該使用者有權查看、優先級為高的案件
And：沒有符合條件的案件時，顯示明確空狀態
And：清除篩選時，還原既定預設列表

這個案例還缺什麼？至少要定義如何處理未設定優先級、翻頁、排序、篩選與搜尋同時使用、API 錯誤，以及不同權限是否看見相同項目。若只測試一筆正常資料，無法證明功能已可用於正式營運。

把驗收條件分成 5 個面向

第一是正確行為：使用者依指定操作得到哪個結果。第二是邊界情境：沒有資料、輸入格式錯誤、重複送出或多個條件同時成立時如何處理。第三是權限與安全：誰能看見、修改或刪除資料，應拒絕哪些越權要求。第四是資料一致性：數字、列表與後端紀錄如何核對。第五是可觀測性與交接：完成時留下哪些測試、版本、錯誤與核准證據。

這 5 個面向是本文提供的檢核框架，不表示任何功能都要添加完全相同數量的條件。對一篇新聞文章，驗收可能是來源、圖權、連結及前台呈現；對財務報表，驗收可能是期間、欄位、加總、排除規則和覆核；對客戶服務的 AI Agent，驗收可能是正確查詢、拒絕越權與避免重複寫入。

給採購、企訓與 AI 開發團隊的驗收卡

需求名稱：＿＿＿＿
業務目的：讓哪位使用者完成什麼工作？
使用情境：何時、在哪個系統使用？
前提：權限、資料、環境、版本是什麼？
正常結果：輸入 A，應看見／得到 B
例外結果：錯誤、空資料、逾時、重試如何處理？
證據：截圖、測試報告、資料核對、API 回應或操作紀錄
判定：PASS／HOLD／FAIL，由誰確認？
回退：失敗時恢復到哪個版本，誰負責？
排除範圍：哪些需求不在本次交付內？

這張卡的價值不只是工程管理。企業可以在採購 AI 系統前，先用它整理委外範圍；教育訓練可以用它讓學員自行核對成果；內部資訊部門可以將它連到測試案例與版本紀錄。當兩種方案報價差異很大時，先確認兩者承諾的驗收範圍是否相同，比單看展示畫面更有判斷力。

AI Coding 的特殊陷阱：輸出很多，不代表驗收充分

AI 工具可以快速產生程式、文件和測試草稿，但它無法僅憑自己的回答證明所有條件已達成。若模型說「功能已完成」，主管應查看實際程式變更、測試回執與目標環境。當程式碼檢查通過但正式前台破版，仍應記錄未完成；當畫面看起來正確但超出資料授權範圍，也不能視為通過。

因此 Acceptance Criteria 應在開發前由業務、開發與測試相關角色一起確認，再隨需求變更保留版本。Agile Alliance 將事先共同討論驗收測試的做法稱為 ATDD（Acceptance Test Driven Development）；它的意義是降低開發結束才發現需求不同的風險，而不是保證每個案例都能自動化。參考：Agile Alliance：ATDD。

從一次交付走向可採購、可追蹤的成果

一項高價企業 AI 專案，若只用「顧問到場」、「完成課程」、「建立系統」作為交付敘述，仍難以判斷是否產生工作改善。更合理的做法，是在不捏造成效的前提下，先記錄既有流程的耗時、錯誤和人工覆核，再明確約定新流程要用哪些證據比較。成效數據須依實際導入現場收集，不應把提案中的預估比例寫成已達成結果。

Acceptance Criteria 不只是開發團隊的術語，它是經營者把投資意圖轉成可驗證成果的最小管理單位。需求越早說清楚，AI 和工程師越有機會做對事，而不是只是做更多事。

一個驗收條件被忽略，可能影響後面三個角色

以企業內部的案件管理系統為例，業務主管要求「可以依優先級篩選」，開發者很快做出下拉式選單，測試人員也看到高優先級案件正常顯示。但如果沒有事先約定未設定優先級的案件如何處理，使用者可能以為資料遺失；如果沒有約定「僅顯示本人有權查看的案件」，篩選甚至可能暴露其他部門資料。驗收的缺口因此從 UX 問題擴大成營運與權限問題。

這類需求不應等開發完成才讓人猜測。負責人可以先請三種角色共同檢查需求：業務代表提出實際工作情境，開發人員確認系統依賴與可行性，測試代表提出邊界及反例。Agile Alliance 在 ATDD 討論中提到從客戶、開發、測試等不同觀點共同定義驗收測試，重點在開工前對齊對「可接受結果」的理解。

三種寫法，實際可測試性差很多

第一種是模糊承諾：「網站載入要快。」它沒有說快到什麼程度、在何種設備與網路下量測。第二種有方向卻缺少口徑：「大部分使用者應該很快看到畫面。」它仍缺少「大部分」的統計定義。第三種才可形成具體驗收：「在明確指定的測試設備、網路、頁面與樣本條件下，以事先約定的效能指標與門檻測試，提交可追溯報告。」實際數值應由業務與工程團隊依需求設定，不能憑空寫成每家企業都適用的標準。

AI 成果的驗收也一樣。「摘要正確」需要對應來源與錯漏判定方法；「報表無誤」需要欄位、筆數及合計核對；「客服 Agent 有效」需要測試集、授權拒絕與錯誤處理。若沒有測量口徑，後續再說「準確率 95％」，也無法判斷分母、時間與樣本是否合理。

Acceptance Criteria 與 KPI 有何不同？

驗收條件通常判斷這一次交付是否符合約定，KPI 則追蹤流程或商業成果在一段期間的表現。某個自動化工具可能通過全部功能驗收，卻因員工沒有採用、流程不合適或資料品質太差，而未改善營運 KPI。反過來說，短期 KPI 好看也不代表系統可以忽略安全漏洞。因此企業應在提案中分開列出「交付門檻」與「導入後成效觀測」，並承認兩者需要不同證據。

用一張決策表處理驗收爭議

表中的狀態名稱只是管理建議，真正採用時要與既有專案系統和合約條款一致。更重要的是「哪一個版本的需求被驗收」，避免專案後期才擅自把新的想法當成既有義務。

合作與付款如何應用這套概念？

對涉及外部供應商的 AI 導入專案，可把交付範圍、測試方式、驗收角色、修改次數、例外處理與付款節點寫入明確契約；尤其要區分一次課程教學成果與正式營運系統交付。具法律效力的條款仍應由合約雙方及必要法律專業確認。Acceptance Criteria 是管理需求的工具，不能取代正式合約、法遵要求或真實測試證據。

參考資料

1. Atlassian：What is Acceptance Criteria。
2. Agile Alliance：Acceptance Test Driven Development。
3. GitHub：Understanding GitHub Actions。

圖片與素材說明

封面為原創驗收文件視覺化設計，所有欄位為教學示意，非真實企業簽核文件。