這件事幾乎每週都在上演，而且出事的時候不會亮紅燈 —— 流程照樣跑完，只是有一件該做的事沒做。

大家應該都遇過 AI 產出不夠穩定的狀況：明明事先手動測試通過了，過兩天自己用的時候產出就不如預期，甚至上線之後，用戶和營運直接回報「這個 AI 很笨」。

舉個例子，公司有一個 AI chatbot 產品，可以將 AI chatbot 掛載在客戶的網站上。

用戶瀏覽網站時，chatbot 會詢問潛在用戶的姓名和電話號碼，這樣以後業務就可以聯絡用戶。

用戶在和 chatbot 對話中留了姓名和電話，AI chatbot 也確實回覆收到了，結果 AI 實際上根本沒有把資料儲存到 DB，所以業務也不知道有這個用戶對產品有興趣，公司的賺錢機會就流失了。

這還衍生出多種有問題的案例分支，像是有收集到用戶的資訊，但電話號碼是錯的：業務打給錯的人、被對方罵一頓，回頭再罵工程做的 AI 太爛。更糟的是打去詐騙集團或付費電話。

另一個案例是 AI 語音客服版本，這次是預約後要可以更新 google calendar，結果 AI 聽完 email 後有時沒確認，就發了 google meeting 邀請給其他路人。

第一個案例攤開來看是這樣的，每一個看得到的訊號都是綠的，只有一條該發生的沒發生：

那要怎麼檢驗 AI 行為呢？

一開始是改完 prompt 後自己手動測試系統，AI 有如預期收到了用戶的名稱和電話。

手動測很花時間，測過一兩次沒問題就交給 QA，而 QA 長期測下來也會麻木，不一定每次都有心力手動測完所有案例。

如果 QA 測出問題那還好，被真實用戶踩到就不只是尷尬 —— 那通電話會打到業務身上。

為什麼 prompt 修完，問題還是會復發？

有時候需求方想要改變 AI 行為或是增加功能，這時就會修改 prompt，但每改一次 prompt，就可能有某個流程或功能不如預期。

而偵測的位置一路往下游推，最後繞回原點：

因為 QA 對這種生成式 AI 不太可能 100% 都測到。上面那張圖的虛線就是沒測到的情境，這些情境會直接落在真實用戶身上；而且 QA 測過的情境也不保證一定正確。

所以問題落在怎麼檢驗：

• 測試案例怎麼挑選？ 如果是自己挑選案例，然後自己測就是球員兼裁判。
• 怎麼樣才能判斷是對的？ 判斷靠的是感覺，沒有一致的標準。
• 下次改動，測試怎麼涵蓋以前的案例？ 沒有涵蓋，「這次有沒有比上次好」就沒有基準可以比。

上面那兩個例子只是為了讓你認出這個場景：手動測過了、看起來很成功、然後在別人手上出事。

這 30 天會解說 AI eval 的概念，而要動手的換成另一隻 agent —— 一個負責釐清需求的 agent，把需求方丟過來的雜亂 ticket 整理成結構化的 ticket，並挑出有問題的驗收標準（AC，acceptance criteria）。

它跟上面那兩個例子壞的是同一種：卡片看起來整整齊齊、欄位都有填，但少判了一條 AC，而且沒有任何人被通知。挑它的另一個理由很實際 —— 寫程式的人天天在碰需求，而它的每一個欄位、每一個工具都檢查得到。

明天要講清楚這隻 agent 的三件事：輸入是什麼、它可以改動什麼、輸出該有哪些欄位。