01用一件真實的工作驗，不用測試案例驗
交付前，我們一起挑一件您同仁每天真的在做的事：一張真的報價單、一筆真的訂單、一位真的客人的提問。用它驗收，不用我準備的範例。
- 範例是做系統的人準備的，會不自覺避開自己知道的弱點。
- 真實工作帶著真實的條件：時間、資料、人的習慣。系統在那些條件下能跑，才算能跑。
知識 / 你說做好了，我怎麼確認？
測試全過。
儀表板全綠。
東西是壞的。
這種事會發生，而且發生的時候每一個檢查都是綠的。 所以驗收不看「測試過了」，看下面三個約定：每一個都是您看得到、可以自己核對的。
三個約定
驗收不看「測試過了」，看這三件事
02每一次「檢查通過」，都附一次故意弄壞的紀錄
一個檢查如果在東西壞掉時也會通過，它就不是檢查，是安慰劑。所以每一道檢查在交付前都會被故意違規一次，確認它真的會亮紅燈。
- 您會看到的是一份清單：故意弄壞了什麼、哪一道檢查抓到、幾點。
- 沒有這份清單的「全部通過」，我自己也不採信。
03做的人和打分的人分開
驗收時由您的同仁操作，我在旁邊看，不碰鍵盤。做系統的人自己驗自己的系統，會用自己知道的方式去用它，那不是驗收。
- 同仁卡住的地方，就是系統還沒做完的地方，當場記下來。
- 交付的定義：同仁在沒有人在旁邊時，用它完成一件實際的工作。
三則案例
當時看起來完全正常
三件真的發生過的事。共通點是：每一個檢查都是綠的，而東西是壞的，或者反過來。上面三個約定就是從這類事情裡長出來的。
晚上八點半測試，一封訊息都沒送出
當時看起來：一套自動發送訊息的系統，晚上測試，紅燈，訊息寫著「一則都沒送出」。看起來就是壞了，而且白天測明明是好的。
其實那套系統的規則是只在上班時間發送，晚上八點半一則都不送，是它做對了。同一份系統，答案會隨時間變，測試的時間就是條件的一部分。
後來怎麼擋約定 01：在真實條件下驗。驗收的時間、資料、操作的人，都要是真的會用它的那個時候與那個人。
每則訊息的成本算對了，卻低估了 3.8 倍
當時看起來：一套 AI 客服，量出每則回覆的成本，數字可以重現、也真的量到了，寫進報告當月費的依據。
其實量的時候是幾百則連續打完，AI 服務的快取一直是熱的；真實流量是零星的，快取早就過期。同一個系統，實際每則貴 3.8 倍。數字沒錯，只是它回答的是另一個問題。
後來怎麼擋報價與成本一律連量測條件一起講：在什麼情況下量的、真實使用會不會是那個情況。差幾倍會翻掉結論的數字，用真實條件再量一次。
搜尋工具說「沒有」，因為它自己壞了
當時看起來：要確認某段東西有沒有進到上線的版本，用工具搜了四個關鍵字，全部零筆，於是報告「沒有」。還特地搜了一個確定不存在的字，也是零筆，看起來很嚴謹。
其實搜尋指令本身被引號弄壞了，搜什麼都是零筆。東西一直都在。「搜不存在的字也是零」只證明它不會亂報，沒有證明它看得見。
後來怎麼擋約定 02：每個「找不到問題」的結論旁邊，都要有一個「找得到」的證據。所以交付前要故意弄壞一次，確認檢查真的會抓到。
您會拿到什麼
約定要能被核對，不然跟沒約一樣
交付時一起交的三份紀錄
- 驗收紀錄：用哪一件真實工作驗的、誰操作、什麼時候、卡在哪裡、後來怎麼解。
- 故意弄壞清單：弄壞了什麼、哪一道檢查抓到、哪一道沒抓到而補了什麼。
- 報告裡每一個結論都標明是「實測」還是「推論」：實測的附怎麼測、在什麼條件下測；推論的標出來，讓您知道哪些還沒被證明。
這頁刻意不放的
- 檢查怎麼設計、判斷的規則本身：那是做系統的人的工具，不是您需要記的東西。
- 您要記的只有一句：「測試過了」不是證據，「在真實條件下有人用它做完一件事」才是。
給工程師的版本
完整的失敗模式庫在 GitHub
上面三則案例來自一份持續累積的清單：目前 20 型，每一型都是 AI agent 動手時真的踩到、由它自己寫下來的假綠燈，附上該反問的問題。那份清單是給工程師和 agent 用的，寫法也是給他們看的，所以放在 GitHub，不放在這裡。
它同時是一個可以裝進 AI agent 的工具：在 agent 宣稱「完成／已驗證」之前，用這些問題反問它。不呼叫模型、不連網、沒有相依套件。
如果您手上已經有一套「測試都過了」的系統，想知道它在真實條件下站不站得住，三十分鐘可以先看出來。