上週產品會議有人問我，AI 功能到底什麼時候可以上線？我盯著投影幕，腦中第一個浮現的不是模型準確率，而是上線後每天誰要幫忙判斷它答得對不對。

我們當時做的是一個協助客服整理回覆草稿的功能。工程師示範時很順，丟進一段客戶訊息，AI 很快就整理出三個重點，還附上建議回覆。我這個非技術背景的 PM 看完也覺得太酷了吧，感覺客服同事每天可以省很多時間。結果到了第二輪測試，問題開始冒出來。有一筆客戶其實是在問退款期限，AI 把前一封關於付款方式的內容也抓進來，句子看起來很完整，方向卻歪掉。另一筆則是把公司還沒核准的補償方案寫得像既定政策。

那天我們花了兩個小時討論要不要加規則，最後卻沒有人能回答一個更麻煩的問題：這種錯誤要測到什麼程度，才算可以交給客服使用？

後來我看到平台上「開發者用 AI agent，真正管理的是驗證成本」這張卡，裡面的數字讓我停了一下。研究跟著 11 位專業開發者觀察約 15 小時，記錄了 255 個 prompts，平均有 33.4% 的觀察時間花在寫 prompt 或檢查 AI 回應，task switching 每小時甚至可以從 0 到 101.6 次。對我來說，最有感的不是數字很驚人，而是它把我原本模糊的焦慮講清楚了。AI 功能的工作量，不只是在開發和測試階段產生，驗證本身就是工作本體。

我以前排 AI 功能時，會把驗證寫成一張卡，名稱通常是「確認結果正確」，估工半天，然後就往下一個 sprint 走。現在回頭看，這個寫法根本沒有辦法溝通。誰確認？確認哪些案例？遇到模稜兩可的答案要怎麼處理？通過一次之後，模型或資料變了要不要重跑？全部被塞在一句話裡，難怪到了上線前才發現大家想像的完成條件不一樣。

我最近改用三層來拆。

第一層是可以交給測試、型別或固定範例處理的部分。像是輸出格式要符合 JSON，必填欄位不能空白，金額不能出現負數，客服分類至少要落在既定選項。這些我不懂怎麼寫程式，但我可以跟工程師一起把規則列成例子，也能請測試同事確認結果是不是穩定。這一層的完成條件相對清楚，失敗時也比較知道找誰。

第二層是需要人看過的判斷。客服語氣是否合適，摘要有沒有漏掉客戶真正想問的事，建議回覆是否會讓客戶誤會。這些不能只看格式正不正確。我們後來先整理 30 筆匿名案例，請兩位資深客服各自評分，再把意見不一致的 8 筆拿出來討論。結果發現，大家對「有幫助」的標準差很多。這個數字很重要，因為它告訴我們現在缺的不是更多漂亮的 demo，而是一份可以拿來校準的判斷原則。

第三層則是決策和風險承擔。退款、客訴升級、法規相關內容，不能因為 AI 的句子很像人寫的，就讓它自己決定。我會把這些情境標成需要人工確認，並在流程圖上放進實際的停留點。這樣跟老闆溝通時，我可以說目前功能能處理一般資訊整理，但涉及退款承諾時仍需要客服按確認，不用只用「AI 還不夠準」這種很空的說法。

這個拆法也讓排程比較誠實。我現在會把一個 AI 功能拆成資料準備、固定規則驗證、人工案例驗證、例外處理和上線後抽查，而不是只估一段開發時間。以剛剛那個客服功能為例，第一版我們原本預估 5 天，後來加上 30 筆案例和兩輪人工評分，排成 8 天。表面上變慢了，實際上少掉了上線前大家互相丟責任的混亂。

我還踩過一個坑，就是把「人要看」誤寫成「人工介入」。前者只是提醒有人檢查，後者應該要有明確時機、角色和處理方式。誰在 10 分鐘內看？看出問題後要退回 prompt、修改知識庫，還是直接改回覆？如果這些沒有寫出來，驗證負擔最後會落到最靠近使用者的那個人身上，通常就是客服，然後 PM 再收到一句「這功能很雷」。

現在有人問我 AI 功能何時能上線，我會先問回去，我們要驗證的是什麼，哪些可以自動檢查，哪些需要人做判斷，哪些情況要把決定權留在人手上。這幾個問題聽起來沒有很炫，卻比追一個漂亮的準確率更能幫團隊前進。

我還在學 AI，很多技術細節仍然看不懂。但我開始覺得 PM 不需要假裝自己會調模型，至少要有能力把「大家覺得不安」拆成可排程、可分工、可回報的流程。驗證不是產品完成後才補上的安全網，它本來就應該跟功能一起被設計進去。