這篇寫給已經開始讓 AI 幫忙做事、但不確定怎麼確認它真的做對的人。內容是我帶著 AI 開發系統時用的驗收方法，從開工前一路講到宣告完成；最後講小功能怎麼走輕量流程，不必每件事都這麼重。這是「AI 助理實戰」系列第 6 篇。該不該用 AI 代理、要讓它自己做到什麼程度，看第 1 篇；這套方法用在哪些系統上，看AI 協作開發方法。
例子都改寫成一般情境。不寫程式的人，看第一段和最後的〈不寫程式也用得上〉就夠了。
「做完了」，常常只是其中一項過了
先講兩個詞。測試是用來檢查程式的程式：給一組輸入，確認輸出跟預期一樣，可以自動一直重跑。複核是請另一個人或另一個 AI，把做好的東西從頭檢查一次。
AI 回報「完成」時，常常只有一個訊號是好的。我在同一天碰過三次：
| 看起來 | 實際上 |
|---|---|
| 每天早上的自動檢查回報「成功」，沒有錯誤訊息 | 翻日誌才發現，連續四天都因為權限不足，從來沒有真的跑 |
| 測試結果是綠燈 | 細看是 1 個通過、7 個被跳過；綠的是「有跑」，還沒「跑完」 |
| 程式已經合併，就標成「驗收完成」 | 我們自己訂的五項條件裡，「人實際確認過行為」那一項從來沒做 |
第三件最尷尬：「五項缺一不可」寫在我們自己的文件上，卻沒套用在自己的進度表上。
所以我的做法是：完成的定義在開工前就寫好，完成時一項一項對。整套流程長這樣：
開工前：寫清楚要做什麼，也寫清楚不做什麼
開工前先寫一份短文件，我叫它「意圖凍結」。凍結的意思是寫好、確認後就不再改；真的要改，就明寫「意圖變更」，重新確認一次。
| 欄位 | 寫什麼 |
|---|---|
| 要解什麼問題 | 一兩句話 |
| 影響誰 | 哪些人會用到、工作會被改變 |
| 明確不做什麼 | 這一次刻意不碰的範圍 |
| 真正要取捨的地方 | 2～4 個，附上建議和理由 |
| 驗收劇本 | 3～8 條白話：「誰做什麼 → 系統應該怎樣」 |
「明確不做什麼」最重要。沒有這一欄，每一輪都可以很合理地多做一點，最後做出一個沒人要求的東西。就像裝潢前先講好「廚房這次不動」，師傅才不會順手把廚房也拆了。
驗收劇本是給不看程式的人用的，例如：「員工送出請假單 → 主管收到待辦 → 主管核准 → 申請人收到通知」。程式寫得對不對，我不一定判斷得了；做出來的是不是我要的東西，只有我判斷得了。劇本就是把這件事固定擺到我面前。
開工前哪些事要問人？我用一個問題分：答案會不會改變使用者看到的東西？
| 例子 | 會不會改變使用者看到的 | 誰決定 |
|---|---|---|
| 代理人可不可以核准高風險的表單 | 會，關係到誰有權簽什麼 | 問我 |
| 一個使用者看不到、由別的系統帶進來的技術參數 | 不會 | AI 之間討論決定，再用白話回報我 |
這條規則寫好六天後，我的 AI 還是拿第二種問題來問我。它覺得這題很重要，可是重要和該問是兩回事。不問我的技術決定也要回報，用三句話講：決定了什麼、為什麼、對我有什麼影響。
這份文件本身也要有「寫到哪裡算夠」。網站上提過，有一份意圖文件連跑了九輪獨立複核，必修項才從 23 降到 0。中間並不是一路往下，第二輪反而變成 28 項。到第六輪，負責寫的 AI 送複核時多問了一句：剩下的問題是作者沒清乾淨，還是這種寫法本身就收不了尾？複核的 AI 回答主因在寫法，而且每次修正都在製造新的問題。之後替這份文件補上「什麼時候算寫完」的條件，把純技術的細節移到下一階段去驗，後面幾輪才收斂到 0。
驗收條件先寫好：每條都要測得到、分得出對錯
驗收條件要在動手前寫好。寫的時候檢查兩件事。
第一，測得到。條件在那個情境下根本不可能出現，測試就永遠過不了，而且失敗的原因跟你要抓的錯無關。我叫它「假紅」。就像規定煙霧偵測器測試時要聽到「火災」兩個字，可是這台只會嗶嗶叫，它再靈也不會及格。我踩過的一次是：測試要求看到某個錯誤訊息，而產生那個訊息的檢查，正好是這次故意拿掉的東西。
第二，分得出對錯。看到了預期的結果，也要能排除「不管程式對不對都會這樣」，不然就是「假綠」。假綠比假紅難發現得多。我碰過一次：測試工具產生的名稱是大寫，系統裡用的是小寫，系統把它們當成兩個不同的名稱。於是測試設好的那道鎖，系統根本看不到；測試從頭到尾都很順，卻什麼也沒證明。好比在 A 門掛上「施工中，請勿進入」，想測試大家會不會被擋，結果大家走的都是 B 門。
寫每一條驗收條件時，我會問自己四題：
| 問題 | 為什麼要問 |
|---|---|
| 這個結果是誰產生的？ | 要指得出是哪段程式、哪條規定，不能只說「應該會」 |
| 依據是現在的程式，還是還沒做的新設計？ | 還沒做的要標明，不能跟現況混在一起寫 |
| 在這個情境下，真的走得到嗎？ | 避免假紅 |
| 就算看到了，分得出對錯嗎？ | 避免假綠；自己算出來再跟自己比，證明不了什麼 |
還有一個快速檢查：有沒有兩種相反的做法，都能通過這一條？有的話，這條寫得太寬。
換另一個模型，從頭複核
寫的人和驗收的人要分開。我會換一個 AI 來複核，而且開一個全新的對話，不給它看前面的討論，我叫它「冷啟動複核」。Anthropic 在 2026 年 8 月發表的 AI 原生開發指南也建議，把驗證交給一個在全新情境裡的 AI，判斷才不會被寫程式時的假設帶著走；寫程式的 AI 也不能核准自己的成果。指南裡做驗證的可以是同一個模型，我再多走一步，換成另一家的模型。
為什麼一定要換人？有一次的數字很清楚。同一組測試，負責寫的 AI 自己設計的「故意弄壞」全部被抓到；複核的 AI 設計了 25 個，有 6 個沒被抓到。自己出的考題，會不自覺地避開自己的盲點。網站上的案例也提過，換一個模型做冷啟動複核，找到前兩輪都沒碰到的 4 個設計缺口。
複核意見我請它分三級：必修（不修不能上線）、建議（最好改，但不擋）、小意見（個人偏好）。還有必修，就退回重做。
複核也會抓到我們這一方的錯。有一次重驗報告宣稱「每一項失敗都找得到原因」，複核的 AI 指出：有 9 項的紀錄只留了第一個失敗的測試名稱，排除不了是準備測試資料那一步先壞掉。我們先把這個說法收回，補齊完整紀錄重跑之後，結論才重新成立。
故意把程式弄壞，看測試抓不抓得到
測試全過，不代表測試有用。要知道它有沒有用，就故意把程式改壞一點，看測試會不會變紅。這叫突變測試，例如把「大於」改成「大於等於」，或拿掉一道檢查。改壞了測試還是全綠，就代表那個地方其實沒人在看。
我在簽核引擎最複雜的一片做過一整輪。程式裡有 31 道防線，也就是擋住不該發生的操作的檢查。做法是一道一道拿掉，每拿掉一道就把全部測試跑一遍，整輪將近 5 個小時。第一次跑完，27 道拿掉後有測試變紅，另外 4 道拿掉了，測試照樣全綠。補上測試再驗，31 道每一道拿掉都抓得到，全部測試也來到 874 個。
這次還學到一件事：那 4 道在六天前的一次檢查就被標出來過，當時標了 5 道，六天裡只補了 1 道，缺口清單上還把編號記錯了。照著記錯的清單補完，真正的缺口還是會留著。量出缺口，和處理好缺口，是兩件事。
突變測試也有自己的陷阱。有一次負責改壞程式的工具自己出錯，實際跑的是沒改過的舊版本，結果一個紅燈都沒有，看起來就像「測試完全沒用」。所以要先確認程式真的被改到了，再看結果。
還有一條我還沒做到。Anthropic 的指南提醒，修程式的 AI 不應該有辦法放寬檢查它的測試。9 月拿這份指南逐條對照時發現，我的流程還沒有機制能分辨：測試由紅轉綠，是因為程式修好了，還是測試被改鬆了。目前沒有證據顯示發生過，但確實還分辨不出來，這件事先列成待辦。
宣告完成時，逐項附證據
我借用一個開源 AI 角色設定的態度：預設答案是「還需要改進」，有證據才放行。宣告完成時，把當初訂的條件一項一項攤開，不能只寫一句「已完成」或打一個勾。任何一項沒過，整體就不能標完成。
| 項目 | 自動測試 | 獨立複核 | 自動建置檢查 | 人確認行為 | 合併主線 | 整體 |
|---|---|---|---|---|---|---|
| 狀態 | 通過 | 通過 | 通過 | 還沒做 | 已合併 | 未完成 |
自動建置檢查（CI）是每次把程式送上去，就在雲端自動把全部測試跑一次的機制。「已合併」「測試綠」「沒有錯誤訊息」都只是其中一項，不能拿來推說整件事完成了。
最後一關回到開工時的驗收劇本，逐條回答「這條現在跑得起來嗎」。報「874 個測試全過」回答不了這一題。我會把三件事並排：當初說要做什麼、劇本說應該長什麼樣、現在實際能做什麼。三欄都不用看程式，對不上就是做偏了。
小功能走輕量流程
上面這套很重，不是每件事都該這樣做。
我有一次替一個「預覽附件」的小功能也走了完整流程。功能大約半小時就做完，208 個測試和畫面檢查都過了。接著為它寫的驗收條件跑了兩輪冷啟動複核，用掉大約 48 萬個 token（AI 計算用量的單位）；第二輪挑出的 4 條必修，全是驗收文件和收集證據的工具本身的問題，沒有一條是功能的錯。修了文件，又多出新的文件可以挑，停不下來。我自己看了都覺得：不過是多一個預覽檔案的功能，怎麼搞這麼大陣仗。
所以現在先分級：
| 小功能：輕量流程 | 其他：完整流程 | |
|---|---|---|
| 條件 | 同時符合：不改資料表、不改權限、不碰外部系統、不改已經驗過的行為 | 左邊任何一項不符合 |
| 怎麼做 | 做功能，加自動測試和畫面檢查 → 放到測試環境給使用者試 → 他說沒問題才寫文件 | 意圖凍結、驗收條件、突變測試、冷啟動複核、逐項附證據 |
判斷不準時先走輕量流程，回報時寫明理由；使用者可以要求升級成完整流程。複核要花多少力氣，看錯了會傷到誰。小功能靠測試和使用者實際試用把關就夠了。
不寫程式也用得上
就算你只是請 AI 寫一份報告、整理一張表，也可以用同一套想法：
- 交辦時多寫三行：要做什麼、這次不做什麼、怎樣才算完成。
- 「怎樣才算完成」寫成看得到的結果，例如「每一筆都附原始出處」，不要只寫「要正確」。
- AI 說做完了，請它照那三行逐項對照，哪一項沒做到要直接說。
- 重要的東西，換另一個 AI 開新對話檢查一次，不給它看前面的討論。
- 故意塞一個錯進去，例如一筆沒有出處的資料，看負責檢查的 AI 抓不抓得到。
- 最後自己照實際用法走一遍。
參考資料
- Anthropic，〈The AI-native SDLC playbook〉，2026-08-21。https://claude.com/blog/the-ai-native-sdlc-playbook
- msitarzewski，〈agency-agents〉，GitHub。文中「預設還需要改進」的態度，借自其中 Reality Checker 這個角色設定。https://github.com/msitarzewski/agency-agents
- 英文維基百科〈Mutation testing〉。https://en.wikipedia.org/wiki/Mutation_testing
- 文中的數字來自我的開發紀錄，公開的部分見企業入口與簽核引擎與AI 協作開發方法。