從 Demo 到正式系統
- Demo 可以展示
- 功能可以執行
- 真實資料可以運作
- 異常情境可以處理
- 權限可以控制
- 行為可以追蹤
- 結果可以驗證
- 系統可以維運
注意
一套系統能「展示」給長官看，不代表它已經可以上線；中間還有六個階段需要逐一確認，缺一不可。
自我檢測
某系統已經通過「功能可以執行」與「真實資料可以運作」兩個階段，但尚未確認「異常情境可以處理」。這代表什麼？
學習目標
- 說明從「Demo 可以展示」到「系統可以維運」的驗收進程。
- 列出 14 個驗收維度並能逐一檢核。
- 把 Use Case、Workflow、Data、Governance、Procurement Requirement、Test Case 串接成完整的驗收脈絡。
- 依證據做出 Accept／Accept with conditions／Reject 的驗收決定，並完成整合型實作成果。
Accept：從 Demo 到正式系統
14 個驗收維度
14 個驗收維度
| 維度 |
|---|
| 功能 |
| Workflow |
| Accuracy / Quality |
| Knowledge / RAG |
| Permission |
| Security / Privacy |
| Tool Use |
| Human Approval |
| Logging / Traceability |
| Error Handling |
| Reliability |
| Version Control |
| Regression Test |
| Operations & Maintenance |
- 前 4 個維度（功能、Workflow、Accuracy/Quality、Knowledge/RAG）檢核系統「做得對不對」，分別對應模組 1-3 的設計。
- 中間 4 個維度（Permission、Security/Privacy、Tool Use、Human Approval）檢核系統「有沒有被控制好」，對應模組 4-5 的治理設計。
- 後 6 個維度（Logging/Traceability、Error Handling、Reliability、Version Control、Regression Test、Operations & Maintenance）檢核系統「出事之後怎麼辦、能不能長期維運」，對應模組 6 的測試與評測。
自我檢測
驗收小組只檢查了「功能」與「Accuracy / Quality」兩個維度就做出驗收決定。這樣做的主要問題是什麼？
總結情境：串接前七個模組
總結情境：把前七個模組串起來
驗收不是模組 8 才開始的新工作，而是把前七個模組的產出串接起來，檢視它們是否彼此一致、有沒有缺口。
- 業務需求
- Use Case（模組 1）
- Workflow（模組 2）
- Data（模組 3）
- Governance（模組 5）
- Procurement Requirement（模組 7）
- Test Case（模組 6）
- Acceptance Criteria（模組 8）
資訊
如果驗收時發現某個維度缺乏證據，往往可以回頭發現：是模組 3 的 Context 設計沒做完整、還是模組 5 的治理設計漏了一個關卡、或是模組 7 的需求沒有寫清楚驗證方法。驗收是檢驗整條鍊子，不是檢驗模組 8 本身。
自我檢測
驗收時發現「Security / Privacy」維度缺乏證據，追查後發現是因為模組 3 的 Context & Data Canvas 沒有標明敏感資料的處理方式。這說明了什麼？
驗收決定與證據
驗收決定：Accept、Accept with conditions、Reject
情境：地方政府 AI Agent 專案驗收
某地方政府委外開發陳情分類 AI Agent，廠商以一次成功的 Demo 要求驗收。驗收小組依 14 個維度逐一檢核後發現：異常情境處理（遇到無法分類的陳情時沒有妥善的 fallback）與 Regression Test（沒有留存測試案例以供未來版本更新時重新驗證）兩項未達標。驗收決定為「Accept with conditions」：功能、權限、Human Approval 等多數維度達標，但要求廠商在正式上線前補齊異常情境處理與 Regression Test 機制，並提供對應證據後才能解除附加條件。
- Accept：所有關鍵維度皆有證據支持，可以上線。
- Accept with conditions：多數維度達標，少數項目需限期補正，附帶條件通過。
- Reject／要求改善：關鍵維度（例如權限控制、人工核准機制）缺失，不能上線，需退回改善。
資訊
驗收決定必須引用具體證據（測試結果、日誌、權限設定紀錄等），不能只憑印象或廠商口頭保證。
自我檢測
廠商展示的 Demo 表現流暢，長官當場滿意並要求「馬上驗收通過，趕快上線」。下列哪一個判斷最正確？
實作與應用
實作：Would You Accept This System?
活動 8 是整門課的整合型實作：依 14 個驗收維度檢核一個模擬的驗收證據包或廠商 Demo，做出驗收決定，並完成 Government AI Procurement & Acceptance Checklist。
- 彙整前七個模組的產出
Use Case、Workflow、Context、工具權限、治理、測試、採購需求。 - 逐一檢核 14 個驗收維度
針對每個維度找出對應證據。 - 做出驗收決定
Accept／Accept with conditions／Reject，並寫明理由。 - 完成整合型實作成果
提交 Government AI Governance & Acceptance Canvas。
- Government AI Procurement & Acceptance Checklist 最少維度：Business Requirement、Functional Requirement、Workflow、Data、Knowledge / RAG、Model、Tool、Permissions、Security、Privacy、Human Approval、Logging、Traceability、Reliability、Failure Recovery、Testing、Version Control、Regression、Operations。
自我檢測
完成活動 8 之後，你手上應該已經累積了哪些完整的實作成果？