AI 說「做完了」，但不懂程式碼的人沒辦法查證那句話是真是假。這篇整理我在 Nailora 專案（美甲情報 App，見 Nailora 美甲情報 App 複盤）裡怎麼解決這個問題：用一套五段式流程，把驗收從「相信 AI 的自我陳述」換成「機械比對一份事先寫好的契約」。
適合正在用 coding agent 開發、任務量大到需要固定流程的人讀。不需要會寫程式，但要看得懂 git diff 與 grep 這兩個詞。讀完能做到的事：替一個任務寫出一份別人可以逐條打勾的驗收契約，並判斷哪些任務根本不值得走這套流程。
以下是 2026-07 當時的做法。這套流程之後還在演進，這篇沒有回頭逐條更新，數字與條款都停在那個時間點。
重點先講在前面：所有開發入口——開新任務、臨時修正、規範化、Sprint——都走同一條流水線；契約必須含至少一條可觀察的行為驗收，純動作清單一律判不合格；契約裡要求 AI 自己否決一個更簡單的方案；流程重量分四級，小事不走全套；這個做法跟業界的 spec-driven 開發方向一致，差別在驗收單位是「可簽收的行為」而不是「規格文件」。
五個關卡把驗收從相信AI換成機械比對契約
我把交付拆成五個關卡，編號 P0 到 P4，是我自己定的代號：
| 階段 | 名稱 | 做什麼 |
|---|---|---|
| P0 | 前哨 | 判斷任務等級、讀取相關規範、檢查交棒文件的診斷狀態 |
| P1 | 契約 | 產出含可量化驗收契約的計畫，經審查後交我核准 |
| P2 | 執行 | 依計畫實作，每個步驟都標出檔案與行號 |
| P3 | Evaluator | 委派一個獨立的驗證員逐條比對契約，執行者不能自證通過，修復循環最多三輪 |
| P4 | Commit | 我確認後提交，驗收證據寫進 commit message |
關鍵在 P3。執行任務的 AI 不能自己說「我做完了、都通過了」，必須換一個角色——我稱它為 Evaluator，驗證員——拿契約逐條核對，跟審計要獨立於被審對象是同一個道理。
契約至少要有一條看得見的行為才算通過形狀檢查
契約裡的每一條驗收項目都要貼一個標籤，總共三種：
[SYMPTOM]：修好之前先讓我親眼看到它壞掉的那種條款。修 bug 時先復現症狀，完成後由我在真機上確認症狀消失。這是我不懂程式、唯一能親自簽收的證據形式。[EQUIVALENCE]：行為等價證明。重構、規範化這類任務改用「改動前後輸出 diff 為 0」或「grep 命中數從 N 變成 1」這種機械比對，不用實機驗證。[ACTION]：純動作，像是「改了某檔」「加了某函式」。只有 ACTION 的契約無效——契約必須含至少一條 SYMPTOM 或 EQUIVALENCE，否則驗證員直接回報CONTRACT_SHAPE_FAIL，連逐項檢查都不用進去。
契約可以精細到這種程度：「git grep 結果恰為 1 行，位於某檔第 94 行；改動前基準為 5 行。」完全機械可驗，沒有主觀空間。
契約要先否決一個更簡單的方案並且不准留模糊字眼
單靠「行為可驗證」還不夠，AI 還是可能把簡單任務做成複雜工程。我加了兩道閘門：
第一道，每份契約必須寫一條「被否決的更簡單方案，加一句否決理由」，少了就判 SIMPLICITY_GAP_FAIL。這逼 AI 在動手前先證明沒有更簡單的做法，而不是先做完再說服我這是必要的。
第二道，契約與驗收結論裡不准出現「應該、建議、儘量、考慮、可能、通常、盡量」這類字眼，用 grep 機械檢查，零容忍。模糊字眼是 AI 留後路的訊號——「應該沒問題」跟「已經驗證沒問題」完全是兩件事，契約裡只能寫後者。
任務大小決定流程重量多數小事不用走完整五關
三行以內的微改如果硬套完整的 P1 到 P3 流程，燒掉的 context 比任務本身還多。所以流程分四級，小任務可以跳過大部分關卡：
| 級別 | 條件 | 計畫文件 | 驗證員 |
|---|---|---|---|
| TRIVIAL | 三行 diff 以內，且不觸規範層、不觸資料真相源，三個條件同時成立 | 無 | 免 |
| S | 三個檔案以內，純 UI／文字／樣式，無架構影響 | 無，輕量口頭契約 | 輕量 |
| M | 標準路線圖任務，範圍明確 | 精簡版 plan | 完整 |
| L | 架構變更、跨模組、新資料流 | 完整版 plan 加耦合分析 | 完整 |
判級預設 M，符合條件可自動降級；執行中發現改動範圍超過原本判級，可以就地升級，不需要重新核准。流程本身也要通得過「最小解」檢驗，這也是為什麼會有 TRIVIAL 這個逃生門。
技術細節：臨時修正（hotfix）另有三分流
三個檔案以內，由主 AI 自己產出契約；三到五個檔案，委派給規劃員；超過五個檔案、違反既有決策、或影響三個以上待開發任務，硬性拒絕，要求升級進路線圖走正式流程。這一段是為了防止「臨時修一下」滾成失控的大改。
跟主流spec-driven方向一致差別在驗收單位是行為不是文件
主流做法像是 GitHub Spec Kit 的 Spec 到 Plan 到 Tasks 到 Implement，或是 AWS Kiro 的 requirements.md 到 design.md 到 tasks.md，跟五段式方向一致：規格前置，降低 AI 對任務意圖的理解漂移。差異有三點。
驗收單位不同：spec-driven 的產物是規格文件，業界公認的痛點是 spec 跟 code 日久脫鉤，沒有自動同步機制；五段式的產物是可簽收的行為契約，驗收就是比對契約，不存在文件與程式碼各走各的問題。
分級制內建：業界對 spec-driven 的主要批評是小修 bug 不值得這套開銷，Kiro 也被批評流程僵化，2026 年的修正方向正是把開銷分級。五段式內建 TRIVIAL 跟 S 這兩個逃生門。
驗收有獨立裁判：spec-driven 流派多半還是同一個 agent 自己審自己；五段式強制委派獨立的 Evaluator，細節見 AI 協作開發：多 Agent 對抗管線。
契約形狀檢查目前還是靠人工不是靠腳本
驗證員判斷契約有沒有 SYMPTOM 或 EQUIVALENCE、有沒有模糊字眼，目前靠的是驗證員自己執行 grep，屬於自律行為，還沒有寫成確定性的腳本檢查。這部分尚未驗證能不能完全腳本化，也是目前流程裡最脆弱的一環——如果驗證員自己也偷懶，這道防線就會失效。
相關連結
AI協作開發-MOC AI 協作開發：多 Agent 對抗管線 AI 協作開發：Context 節流與錨點術 AI 協作開發：非技術 PM 的驗收閘門 Nailora 美甲情報 App 複盤