AI 需求規格怎麼寫？用途、資料、人工關卡與驗收的 PRD 清單
一般軟體需求常描述功能與畫面，AI 需求還要處理輸出不確定、資料版本、無答案、人工判斷、模型更新與風險門檻。若 PRD 只寫「使用 AI 自動回答」，開發者無法知道什麼叫正確，也無法設計失敗時的行為。
第一段先寫問題與非目標
描述誰在什麼工作遇到什麼問題，附目前件數、時間、等待、錯誤與返工基準。再寫這一版不處理什麼，例如不提供法律結論、不自動付款、不存取個人績效、不對外發布。
先用AI 使用情境一頁簡報完成共識。AI 不一定是正確解法，規則、自動化、搜尋改善或流程刪除也要列為替代方案。
使用者、受影響者與情境
列出直接使用者、管理員、內容 owner、人工接手者與可能受影響但不操作系統的人。每個 user story 都補上正常、資料缺漏、無權限、無答案、外部服務中斷與惡意輸入情境。
例如「客服查詢退款規則」不能只寫成功回答；還要寫文件過期時拒答、不同產品規則衝突時轉人工、低權限角色不能取得主管文件。
資料需求要能追溯
每個資料來源記錄 owner、用途、生效、版本、權限、保存、刪除與更新。若含個資、機密或受契約限制資料，交由適任人員審查。不要只寫「連公司資料庫」，應列出欄位、最小範圍與哪些資料明確禁止進提示或日誌。
NIST AI RMF Playbook 的文件建議涵蓋業務理由、用途、風險、假設、資料、測試、依賴、部署、監控與變更；官方也明示 Playbook 是自願性建議，不是所有項目都要照順序完成。
功能需求寫輸入、輸出與控制
對每項功能描述允許輸入、預期輸出格式、來源呈現、拒答條件、人工批准、可撤回方式與權限。Agent 類功能還要限制可呼叫工具、參數、每次與每日量、金額、速率與沙盒，不能只寫「可幫使用者完成任務」。
可先用AI 風險初篩工具確認哪些需求需要更強的控制，再把結果交由專業審查，而不是把初篩分數當安全認證。
非功能需求不能省略
- 品質：正確、引用、完整、拒答與人工修正門檻。
- 安全：身分、最小權限、提示注入、秘密與外部動作。
- 隱私：最小化、保存、刪除、日誌遮罩與使用者告知。
- 效能：延遲、容量、逾時、重試與降級。
- 成本：預算、用量、單位成果、警戒與停止門檻。
- 營運：監控、事件、回復、支援、版本與退場。
驗收要包含失敗
建立代表性測試集，保存預期結果與判定者。每次模型、提示、資料或工具變更時重跑，特別檢查高風險錯誤與退化。可用AI PoC 計畫書記錄門檻；RAG 專案用RAG 評測紀錄表逐題保存引用與權限結果。
上線條件應有通過、警戒、停止三層，而不是只寫平均正確率。任何跨權限資料、不可撤回高影響動作或重大敏感資料外洩，都應依組織規則觸發停用與事件處理。
最後補上變更與責任
每項需求指定 owner、版本、證據位置與下次複查日。模型供應商更新、用途擴張、資料增加或人工關卡移除，都可能是重大變更，需重新評估而不是默認沿用舊驗收。