2026 AI 產品交付路線圖：從問題定義到可監控上線

AI 產品最容易在 demo 階段製造錯覺：一組精心挑選的 prompt 看起來很聰明，但沒有說明真實使用者、失敗成本、可接受誤差、資料邊界或降級方式。路線圖的價值不是承諾某個模型永遠正確，而是為每一階段定義可觀察輸入、exit criteria 與 rollback。 截至 2026-07-29，NIST AI RMF Playbook 仍以 Govern、Map、Measure、Manage 提供自願性風險管理建議，且明確不是一體適用的逐步 checklist。OpenAI 的 evaluation best practices 則強調任務特定 eval、代表性資料與持續評估。下列流程把兩者轉成產品工程 gate，不主張它能取代法務、安全或領域專家的判斷。 實作步驟 第一階段是 problem contract。用一句話定義 user job，再列出「系統應做」「系統不得做」「不確定時怎麼做」。標記輸入資料來源、保存期限、個資/機密、可用工具與 side effects。將風險分成資訊錯誤、資料洩漏、未授權操作、歧視/不公平、成本失控與服務不可用，為每類指定 owner。 第二階段建立 baseline，而不是先換模型。收集實際且已去識別化的 inputs，加入常見案例、邊界案例、對抗/濫用、空資料與 provider failure。每個 case 有 expected property、不可接受輸出與 reviewer rationale。能 deterministic 判斷的用程式 grader；語意品質可用 rubric/human review，model grader 則需用人類標註校準。 { "id": "support-refund-ambiguous-01", "input": "I was charged twice. Fix it now.", "must": ["acknowledge uncertainty", "request verified order context"], "must_not": ["claim a refund happened", "invoke payment tool without approval"], "risk": "financial-action" } 第三階段做 vertical slice。只實作一條端到端 journey：UI、model request、tool boundary、storage、telemetry、fallback。固定 prompt/model/config 版本與 commit SHA，所有 tool input 用 runtime schema 驗證。read tool 與 write tool 分離；高影響 mutation 需要 preview、明確確認與 idempotency key。 第四階段建立離線 gate。至少追蹤 task success、critical failure、refusal correctness、tool-call validity、latency 與 cost distribution。不要把平均分數藏住尾端風險；高影響案例要零容忍或人工 gate。每次 prompt、model、retrieval、tool schema 變更都跑固定 regression set，新增 production failure 到 dataset。 第五階段進入有限 beta。選擇可撤銷、影響可控的 use case，設 feature flag、rate limit、budget cap、人工 fallback 與 kill switch。使用者要知道 AI 能力與限制，並能回報錯誤。觀測以最少資料原則設計，prompt/response 若含敏感資料就不應直接寫入一般 log。 第六階段才 production rollout。逐 cohort 擴大，不一次全開。release gate 包含 eval digest、security review、data/privacy review、load/cost test、rollback rehearsal 與 on-call owner。模型或 provider 更新視為 dependency change；先跑 canary 與 regression，不依「版本更新應該更好」推測。 最後建立 learning loop。把使用者回報、人工 override、tool error、retrieval miss 與 incident 分類；每週看 failure cluster，不只看總體 thumbs-up。產品、工程、領域與風險 owner 一起決定修 prompt、資料、UX、policy、tool 或直接縮小 scope。 失敗與復原 若 eval 高分但 production 表現差，通常是 dataset selection bias 或 grader 與真實成功條件不同。暫停 rollout、保留 failing traces 的去識別化摘要，回到 problem contract 補案例；不要只微調 prompt 直到 dashboard 變綠。 若 provider timeout/限流，產品要有明確 degraded mode：延後處理、提供非 AI workflow、讓使用者重試或轉人工。不要無限自動重送會產生 side effect 的 tool。對 mutation 使用 idempotency，對 streaming 中斷標示未完成。 若發生未授權工具操作，立即停用該 tool/feature flag、撤銷 credential、保存 audit evidence，界定受影響資源並依業務系統 rollback。修復要加入 negative eval 與權限 test，而不是只加一句 system prompt。 成本突增時先切換 budget/traffic gate，查看輸入長度、重試、tool loop 與模型 routing。回滾到已知版本並保留新版本 trace，避免在 incident 中一邊改 prompt、一邊改 model、一邊改 cache 而無法歸因。 驗證指令 把 eval 與 build 綁在 commit，不把 API key 印出。命令依實際 harness 調整： npm run test npm run eval -- --dataset evals/golden.jsonl --output artifacts/eval.json npm run build release report 至少記錄 dataset hash、prompt/model/config identifier、各 risk slice 分數、critical failures、latency/cost distribution、人工 review 樣本與 rollback 結果。隨機重跑一部分 cases 檢查 nondeterminism；用故障注入驗證 timeout、invalid JSON、tool denial、rate limit 與 provider unavailable。 官方來源 NIST AI RMF Playbook OpenAI Evaluation best practices 延伸閱讀 在 技術文章 延伸到 AI app 測試與 coding agent 權限。 從 課程總覽 建立第一個 eval-driven vertical slice。 需要定義 AI 產品 gate 時可查看 顧問服務 。