本模組沿用模擬情境：某市政府（虛構）委外建置「陳情案件分類 AI」，由 AI 讀取陳情內容、建議分類與承辦單位，承辦人員核可後才派案。需求寫不清楚，驗收時就只能憑印象與展示效果判斷。
「系統應具備智慧化分類功能，提升行政效率。」沒有範圍、沒有數字、沒有人能判斷做到了沒有。
資訊
需求書寫著「系統回應應合理且準確」。下列哪一個修改最能讓它變得可驗收？
把前面模組的產出轉成需求，不必從零想像。以下類別正好對應你已完成的工作；每一類至少要有一條可驗證的需求。
| 需求類別 | 承接的前序產出 | 可驗證需求範例 |
|---|---|---|
| 資料需求 | 資料與工具權限表 | 僅可使用機關核定的陳情資料來源；輸入前須完成去識別化；不得將原始陳情送往未經核可的外部服務。 |
| 權限需求 | 資料與工具權限表 | AI 帳號僅有陳情資料唯讀權限；任何寫入或派案動作須經承辦人員核可。 |
| 人工核准需求 | 含人工關卡的流程圖 | 低信心、涉及個資或高影響案件必須進入人工審核，系統不得自動結案。 |
| 紀錄需求 | 治理與控制檢核表 | 每筆建議須留存輸入摘要、輸出、來源、核可人員與時間，保存期限依機關規定。 |
| 維運需求 | 三類測試案例 | 模型或知識內容更新前須重跑回歸測試並提交報告；異常事件於約定時限內通知維運人員。 |
注意
驗收不能只看展示。完整驗收表有 14 個維度，每一個都要找得到對應證據；講課時我們聚焦在本案例最容易出現缺口的幾項。
| 維度 | 要問的問題 | 常見證據 |
|---|---|---|
| 功能 | 核心任務是否做到？ | 功能測試報告 |
| Workflow | 流程與人工關卡是否照設計運作？ | 流程測試紀錄 |
| Accuracy / Quality | 輸出品質是否達標？ | 樣本測試結果與標準答案比對 |
| Knowledge / RAG | 引用的資料是否有來源、版本與時效？ | 來源清單、版本紀錄 |
| Permission | 權限是否最小化？ | 權限設定畫面或設定檔 |
| Security / Privacy | 敏感資料與注入攻擊是否受控？ | 資安檢測、去識別化紀錄 |
| Tool Use | 工具呼叫是否在授權範圍內？ | 工具呼叫紀錄 |
| Human Approval | 高影響動作是否經人工核准？ | 核准紀錄樣本 |
| Logging / Traceability | 事後能否還原誰做了什麼？ | 日誌樣本、追溯演練 |
| Error Handling | 異常時是否有 fallback？ | 失敗案例測試結果 |
| Reliability | 重複執行是否穩定？ | 多次測試結果 |
| Version Control | 版本變更是否可管理？ | 版本與變更紀錄 |
| Regression Test | 更新後是否重新驗證？ | 回歸測試報告 |
| Operations & Maintenance | 上線後誰維運、如何處理事件？ | 維運手冊、通報流程 |
驗收小組只檢查「功能」與「Accuracy / Quality」就簽核通過。主要問題是什麼？
廠商交付：功能測試報告（分類一致率達約定門檻）、50 筆邊界案例結果、權限設定畫面（AI 帳號唯讀）、日誌樣本。缺少：低信心案件轉人工的失敗案例測試、模型更新後的回歸測試報告、維運與事件通報流程文件。
| 維度 | 證據狀況 | 判斷 |
|---|---|---|
| 功能 | 報告完整且可複核 | 達標 |
| Permission | 設定畫面顯示唯讀 | 達標 |
| Error Handling | 沒有失敗案例測試結果 | 缺證據 |
| Regression Test | 沒有回歸測試報告 | 缺證據 |
| Operations & Maintenance | 沒有維運與通報文件 | 缺證據 |
注意
廠商展示流暢，主管當場希望「今天就驗收通過」。哪一個做法最正確？
本實作產出整合型 Canvas 的「採購需求」與「驗收決策」兩欄，沿用前面模組已填入的案例資料。所有內容請使用模擬或去識別化資料，不要輸入機密、真實個資或未經授權的敏感資訊。
資訊
寫驗收決策時，下列哪一項最不應該出現在理由欄？
