AI 產品從 demo 到上線，中間還有哪些工作？

AI 客服亂答一句，公司被判要照賠。

加拿大航空的客服機器人告訴乘客，喪親優惠可以事後補申請，實際規定根本不行。航空公司主張機器人要自己負責，法院沒有接受。這類問題在 demo 裡很難看出來，以下用一個物流 AI 客服的例子，整理我覺得從 demo 到上線需要確認的六件事。

1. 先確認 AI 可以處理哪些任務

查包裹、問運費、修改地址、申請理賠，都是客服會接到的需求，但背後需要的資料、權限和承擔的責任不同。查詢進度是讀取資訊，修改地址會改變訂單，理賠則涉及責任判定與賠付承諾，因此需要先決定 AI 可以處理到哪一步。

我會把這個範圍當成產品規格的一部分。團隊需要知道哪些操作可以交給 AI、哪些需要使用者確認，以及哪些必須由有權限的人決定，後續才有依據設計流程。

如果沒有先定清楚，AI 可能在身分未確認時修改資料，或像開頭的加拿大航空那樣，做出超過授權範圍的承諾。另一種情況是所有任務都要求人工確認，使用者多經過一輪對話，最後仍要走原本的流程，AI 也就沒有減少處理工作。

做法是把客服任務分成自動執行、需要確認、轉交人工三類，再逐項寫出條件。例如查包裹進度可以呼叫物流 API；修改地址要驗證身分、檢查包裹是否還能修改，並請使用者確認新地址。理賠中的資料蒐集與進度查詢可以評估交給 AI，責任判定和賠付則依業務規則與授權處理。最後再和現有查詢頁面、規則系統比較，確認加入 AI 能改善哪些使用上的問題。

2. 把模型放進業務流程，再比較表現

模型能回答物流問題，不代表它知道某筆訂單的最新狀態。使用者要查包裹，還需要系統取得運單號、驗證資料並呼叫物流 API。模型的表現會受到資料和工具執行結果影響，所以選型需要連同業務流程一起考慮。

我比較在意的是，這個方案放進客服流程之後，能不能完成使用者的需求。模型的回答品質、回應時間與成本都需要評估，但也要看它能否取得需要的資料，以及操作失敗後如何處理。

如果只用幾段順利的對話選模型，上線後才可能發現包裹資訊查不到、計價結果沒有依據，或 API 逾時後無法接續。這些問題有些出在資料與流程，換模型也未必能解決，團隊卻可能把時間花在反覆調整回答方式。

比較時，用同一批客服任務測試不同方案，記錄回答準確度、工具執行結果、回應時間與完整成本，也納入部署方式和資料要求。查即時物流就接物流 API；查運費規則與保價條款，可以透過 RAG 取得審核過的內容；計算某筆訂單的費用，則交給計價 API 或規則系統。每一步都要交代需要的資料、操作條件，以及失敗後如何接續。

3. 選模型之前，先寫好驗收標準

AI 的回答可以有不同寫法，任務是否完成卻需要共同的判斷依據。以修改地址為例，使用者看到「修改成功」，就會期待包裹寄往新地址；團隊驗收的結果，也應該對應這個期待。

我覺得驗收標準要在選模型之前寫好。它讓產品、業務和工程團隊對要交付的結果有共識，也讓模型比較有依據，避免各自憑回答是否順暢來判斷。

如果沒有這份標準，團隊可能接受了成功的回覆，卻沒有檢查訂單是否更新。之後更換模型或調整 Prompt，也缺少固定案例確認原本的功能有沒有受影響。改版檢查也可能依賴零散的人工試用，問題等到使用者反映才被發現。

做法是先寫出任務完成的條件。修改地址要確認使用者權限、新地址的確認紀錄、API 執行結果，以及後台訂單狀態。評測案例可以從去識別化的客服對話整理，包含正常需求、缺少運單號、表達不清楚、中途更改需求和 API 錯誤。每個案例記錄應查詢的資料、應執行的操作、承諾範圍與轉人工條件。

更換模型、調整 Prompt 或修改流程後，都用這批案例重新評測。如果問題需要透過模型微調處理，再準備訓練資料，並與評測資料分開，避免用模型學過的內容判斷成效。

4. 技術指標與使用者的問題，要一起看

系統有成功回應、工具有執行，還需要確認使用者的需求是否被處理。技術指標可以說明哪個環節運作正常，業務指標則幫助團隊判斷這套服務帶來了什麼結果。

我看 AI 客服的成效，會先回到使用者是否得到解決。技術指標適合用來找原因，但不能只憑一個數字，就決定服務有沒有改善。

例如轉人工率下降，可能是 AI 解決了更多問題，也可能是使用者沒有得到答案就離開。如果沒有把這兩種情況分開，團隊就可能把使用者放棄當成成功，繼續調整一個看似有效、卻讓人更難取得協助的流程。

因此需要同時記錄兩組指標。技術上看需求判斷、知識查詢、回答依據、工具執行與回應時間；業務上看問題解決率、重複詢問、處理時間、滿意度與人工交接情況。把「沒有轉人工」和「問題已解決」分開統計，再用技術紀錄查出需要改善的環節。

5. 順著執行流程，查出問題發生的位置

AI 說地址改好了，後台卻沒有更新，表面上是同一種失敗，原因卻可能不同：沒有呼叫 API、參數有誤、API 執行失敗，或系統只收到修改申請，還沒完成變更。需要查出是哪一步出問題，才能決定如何修正。

我覺得這類問題要先查執行紀錄，再判斷需要調整模型、工具或流程。回答內容也要和執行結果對得上，讓使用者知道訂單目前處於什麼狀態。

如果只修改 Prompt，讓回答聽起來更謹慎，沒有處理造成失敗的原因，同類請求仍可能出錯。使用者以為地址已經更新，就可能停止追蹤這件事，直到包裹送往原地址才發現。若修正後沒有留下評測案例，後續改版也可能再次出現相同問題。

處理時，沿著身分驗證、資料取得、工具參數、API 回應和後台狀態查執行紀錄。完成修改才能回覆成功；只送出申請，就說明申請已送出。接著確認受影響的請求與使用者，依風險決定是否先暫停功能、轉人工或安排後續處理。修正完成後，把失敗案例加入評測資料，之後改版也要檢查。

6. 最後回到這項投入是否值得

假設 AI 客服一天處理八千次對話，這個數字還需要和成本、服務結果一起看。一段對話可能呼叫模型數次，也會用到知識檢索、業務 API 和伺服器，後續還有維護與人工接手的成本。

如果使用者與 AI 對話之後，仍要找真人，從頭說明一次問題，即使模型費用低，整體處理成本也可能增加。評估投入時，要確認節省了多少人工處理時間、使用者等候時間有沒有縮短，以及問題解決率有沒有改善。

我在意的是，團隊能不能說清楚這項產品要解決什麼問題，以及用什麼結果判斷它值得繼續投入。產品負責人需要把業務目標、任務範圍、技術方案和驗收標準接起來，協調各個環節的判斷與交接。

demo 可以讓團隊看到一個方案的可能性。準備上線時，還需要把資料不足、操作失敗和人工接手的情況安排好。這些工作的價值，會出現在使用者能否完成任務，以及團隊能否持續提供這項服務上。