先問要改善哪個決策，不要先問要用哪個模型
許多 AI 專案從「想做一個企業助理」或「希望導入 RAG」開始，但這些是解法名稱，不是可實作的需求。工程團隊首先要找出使用者在什麼情境下採取什麼行動：客服人員要回覆客戶、業務要查詢訂單、採購要比對規格，還是主管要判讀異常？如果 AI 的輸出沒有連到一個明確決策、工作步驟或後續系統動作，就很難判斷資料是否足夠，也無法設計有效的驗收方式。
訪談時應要求團隊帶著實際畫面走一次現有流程，包括使用者從哪裡收到任務、查哪些系統、如何判斷、最後把結果寫到哪裡。接著追問目前最耗時或最容易出錯的環節，以及不用 AI、只調整流程或搜尋功能能否解決。這不是否定 AI，而是確認模型帶來的彈性是否值得額外的成本、延遲與不確定性。
- 觸發條件：誰在什麼事件發生後使用系統？是主動查詢、排程執行，還是由 LINE、ERP 或 CRM 事件觸發？
- 期望動作：系統只提供建議，還是可以建立工單、更新客戶資料、發送訊息或執行交易？
- 錯誤代價：答錯、漏答、答得太慢，各自會造成什麼影響？哪一種錯誤最不能接受？
- 人工介入：哪些結果必須經人員確認？覆核者需要看到來源、推理依據或資料版本嗎？
- 成功基準：要優於目前的人工作業、既有搜尋，還是某套規則系統？比較基準必須先定義。
把「我們有資料」拆成可驗證的工程條件
資料存在，不代表資料能被 AI 系統可靠使用。需求訪談要確認資料格式、品質、權限、更新頻率與責任人。文件可能散落在檔案伺服器、Google Drive、SharePoint、資料庫與個人電腦；同一份規範也可能有多個版本。若沒有明確的權威來源，RAG 即使檢索成功，也可能引用已失效的內容。工程團隊應詢問誰能判定資料正確、誰負責更新，以及舊資料是否需要保留、隔離或標示有效期間。
還要用真實樣本檢查資料，而不是只看檔案清單。掃描 PDF 是否能正確辨識？表格、圖片與附件是否包含關鍵內容？中英文術語是否一致？文件權限能否映射到每位使用者？若使用紀錄包含個資、商業機密或客戶資料，則需先定義哪些內容可以送往外部模型、哪些必須遮罩，以及日誌可以保存到什麼程度。
- 資料來源：哪些系統是正式來源？發生衝突時，以哪一份資料為準？
- 新鮮度：資料更新後，AI 最晚多久必須看到新版本？需要即時同步、事件更新或定期批次即可？
- 存取控制：AI 是否必須沿用原系統的部門、角色、客戶或專案權限？
- 可追溯性：回答是否必須附來源與版本？若資料被刪除，既有對話與稽核紀錄如何處理？
- 測試資料：是否能整理一組具代表性的問題、正確答案、可接受變體與不應回答的案例？
在流程圖上確認整合邊界與失敗模式
企業 AI 的主要難度通常不只在模型，而在身分驗證、資料同步、既有 API 與例外處理。訪談時應畫出從使用者介面到模型、知識庫與企業系統的完整資料流。對每一條連線都要確認 API 是否存在、由誰維護、是否有測試環境、速率限制如何，以及內網、防火牆、VPN 或單一登入會不會限制部署方式。若 ERP 只有批次匯出，需求就不能假設即時庫存；若 CRM 欄位缺少穩定識別碼，AI 也不應直接自動寫回。
整合還要區分讀取、建議與執行三種權限。查詢訂單與修改訂單的風險完全不同；在 LINE 回覆草稿與直接送出訊息也需要不同的審核機制。工程團隊應逐項詢問逾時、資料缺漏、模型無法判斷或外部服務中斷時要怎麼辦。可靠的系統不能只描述成功路徑，還必須有降級方案，例如改用關鍵字搜尋、保留待處理佇列、轉交人工，或禁止高風險寫入。
- 延遲與容量：使用者能等待多久？尖峰同時使用量、批次量與模型成本上限是什麼？
- 一致性：快取、向量索引與來源系統不同步時，系統要顯示警告、阻擋操作，還是容許短暫差異？
- 可觀測性：是否記錄提示詞版本、檢索內容、工具呼叫、模型回應、人工修改與最終動作？
- 復原方式：自動操作失敗或寫入錯誤時，能否安全重試、撤回或由人工接手？
在開發前寫出可執行的驗收與上線條件
「回答要準」不是工程驗收標準。不同任務應採用不同判準：知識問答要看來源是否正確、是否忠於文件、遇到未知問題能否拒答；分類或抽取要看關鍵欄位是否完整；代理型流程則要檢查工具選擇、參數、權限與最終系統狀態。訪談時要蒐集正常案例、邊界案例、權限案例與失敗案例，並由真正負責流程的人確認預期結果。先建立小型但具代表性的測試集，比等到展示前憑感覺評分更可靠。
上線條件還應包含回應時間、可用性、成本預算、安全稽核、資料保留與人工支援。模型、提示詞、知識內容或整合 API 更新後，哪些測試必須重新執行？誰有權發布版本？遇到品質退化時如何回滾？專案也要指定上線後的內容負責人、系統負責人與業務決策者，否則知識過期或流程改變時，問題很容易被誤認為單純的模型故障。
一次有效的需求訪談，最後應產出清楚的使用情境、資料盤點、整合圖、風險清單、測試案例與分階段範圍。第一階段通常適合先限制資料來源、使用者與可執行動作，觀察真實使用紀錄後再擴大自動化。若由整合團隊參與，最有價值的工作不是先承諾某個模型，而是協助企業把上述邊界轉成可以估算、測試與維運的系統設計。