AI 專案驗收時，客戶最在意的三件事

上個月協助一家物流公司驗收 AI 智慧調度系統。技術團隊準備了精美的 Demo：即時路徑最佳化、異常預警、自動派單，一氣呵成。客戶看了十分鐘，問了三個問題，導致專案卡關兩週。

這三個問題，與演算法精準度無關。

第一件事：出問題該找誰？

客戶原話：「系統半夜當機，我該打給誰？」

我們當時提供的是一個 LINE 群組，裡面有專案經理、後端工程師、演算法工程師。客戶覺得不夠——群組裡有人不回訊息，有人回了卻解決不了問題。

我們後續的做法：撰寫了一份單頁的《故障應變手冊》，清楚列出三類問題的處理流程。P0 級（系統無法使用）30 分鐘內電話回應，P1 級（功能異常）2 小時內回覆工單，P2 級（體驗問題）24 小時內處理。每個層級對應具體聯絡人與升級管道。

客戶看到這份文件，明顯鬆了一口氣。他要的不是「有人」，而是「有流程」。

客戶問：「如果 AI 指派了一條錯誤路線，導致司機多跑了 200 公里，這算誰的責任？」

這是責任歸屬的問題。我們最初的設計是 AI 全權決策，人類僅負責確認。但客戶擔心：若 AI 判斷失誤造成經濟損失，責任該如何劃分？

我們後續的做法：將系統從「AI 決策」改為「AI 建議 + 人工確認」。關鍵操作（如跨區調度、超時任務重新分配）必須經人工點擊確認才能執行。同時在系統中記錄每次 AI 建議與人工決策的差異，形成審計日誌。

這個改動讓技術團隊多花了三天時間，但驗收當天客戶當場簽字確認。

客戶問：「三個月後我想新增一個功能，例如依據司機偏好分配路線，你們還能修改嗎？還是得重新招標？」

這背後是對供應商綁架（Vendor Lock-in）與技術債的擔憂。許多 AI 專案交付後，客戶發現系統程式碼雜亂無章，只有原團隊能維護。

我們後續的做法：交付時額外提供了一份《系統架構說明》與《二次開發指南》。這不是那種幾十頁的空洞文件，而是真正實用的內容——包含 API 介面清單、資料庫表結構、核心演算法的輸入輸出格式，以及常見功能擴充的程式碼範例。

AI 專案驗收，技術只是入門券。客戶真正關心的是：出問題有人處理、責任歸屬有界線、新需求具備擴充性。

下次進行 AI 交付時，我會在這三件事於需求階段就討論清楚，而不是等到驗收時才補救。因為信任不是靠 Demo 建立的，而是靠流程建立的。