這篇在解決什麼問題：解決 AI 協作開發時，AI 宣告「完成」卻因看不懂程式碼而無法驗證、難以驗收的問題。 適合誰讀：正在使用 AI Coding Agent 進行中大型專案開發、需要建立標準協作流程的開發者。你需要理解 git diff 與 grep 的基本概念。 讀完能做到什麼：能替開發任務寫出一份可由機械式比對、非技術人員也能逐項打勾驗收的「行為契約」，並能準確評估哪些輕量任務可以避開繁重流程。
注意：以下是 2026-07 當時的做法。這套流程之後還在演進，這篇沒有回頭逐條更新，數字與條款都停在那個時間點。
當「看不懂程式碼」遇上「宣稱做完的 AI」
Nailora 專案，一個由我這個不懂技術的人主導、全權交由 AI 撰寫程式碼的美甲情報 App，見 Nailora 美甲情報 App 複盤。這個開發模式的核心風險在於：AI 宣稱的「完成」往往不可信，而我缺乏讀碼能力，無法親自驗證程式碼的品質。
為了解決這個信任痛點，我不能依賴主觀敘述，必須將驗收標準轉化為機械可比對的契約。
想像你請水電工來修理漏水的天花板，你看不懂複雜的水管線路，但你只要在維修後打開水龍頭，親眼看天花板有沒有繼續滴水即可。這種「不看內部構造，只看外部特徵」的驗證方式，就是行為驗收。在 Nailora 專案中，我將這種思維落實為「行為契約」，把開發任務轉化為非技術人員也能靠肉眼或簡單工具驗收的指標。
五段式流水線
所有開發入口，不論是新任務、臨時修正、規範化整理，還是 Sprint 排程，都必須走完這條流水線：
graph TD P0[P0 前哨：判級與診斷] --> P1[P1 契約：制定計畫與指標] P1 --> P2[P2 執行：分步實作] P2 --> P3[P3 Evaluator：獨立驗收比對] P3 --> P4[P4 Commit：確認提交與存證]
- P0 前哨：進行任務判級（區分為 TRIVIAL/S/M/L 四個等級），讀取相關的規範錨點，並檢查交棒文件以診斷當前系統狀態。
- P1 契約：產出包含可量化驗收契約的實作計畫，這份契約必須經過獨立審查，最後交由我核准。
- P2 執行：依據核准的計畫進行實作，採取 bite-size 的小步驟，每一步都要清楚標記修改的檔案與行號。
- P3 Evaluator：Evaluator，也就是專門負責執行驗收比對的獨立 AI 驗證員，會逐條比對 P1 契約。我嚴格禁止執行任務的 AI 自證通過，且修復循環最多以 3 輪為限。
- P4 Commit：由我做最後確認並提交，並將實際的驗收證據直接寫入 git commit message 中。
契約形狀：三種驗收標籤
一份合格的契約必須具備明確的「形狀」，我使用三種標籤來定義驗收標準：
[SYMPTOM]（症狀驗收）：實機可觀察的症狀。在修復 bug 時，必須在修復前復現此症狀，修復後由我在真機上確認該症狀已消失。這是不懂程式碼的我，唯一能親自簽收的證據形式。[EQUIVALENCE]（行為等價）：重構或規範化類任務的驗收方式。改動前後的輸出 diff 必須為 0，或者某個關鍵字的 grep 命中數必須從 N 次精準降到 1 次。這類檢驗完全交由機械比對代替實機驗證。[ACTION]（純動作）：代表單純的執行動作，例如改了某個檔案、新增了某個函式。
注意，只有 ACTION 標籤的契約是無效的。契約中必須包含至少 1 條 SYMPTOM 或 EQUIVALENCE，否則驗證員會直接回傳 CONTRACT_SHAPE_FAIL，拒絕進行後續的逐項檢查。
透過這種限制，契約可以精細到這種程度：「執行 git grep 後，結果必須恰好為 1 行，且位於某檔案的第 94 行；改動前的基準則為 5 行」。這讓驗收過程完全機械化，沒有任何主觀妥協的空間。
兩道防過度工程閘門
AI 常常會寫出超出需求的複雜程式碼，為了防止這種現象，流程中設有兩道閘門：
第一道是最小解自檢。這就像你去修車時，技師提議要拆掉整台引擎換新，這時你要求他必須在估價單上寫明「為什麼不能只換火星塞，以及這樣做會出什麼問題」。每份 P1 契約都必須包含 1 條「被否決的更簡單方案」以及「一句話的否決理由」。如果缺少這項自檢，驗證員會直接判定 SIMPLICITY_GAP_FAIL，強迫 AI 在動手前證明沒有更簡單的做法。
第二道是模糊字眼禁令。在契約與驗收結論中，嚴格禁止出現「應該、建議、儘量、考慮、可能、通常、盡量」等字眼。我會透過腳本或 AI 進行機械檢查，因為模糊字眼往往是 AI 試圖為未完成的工作留退路的訊號。
分級制：流程重量匹配任務規模
為了避免小任務被繁重的流程拖垮，我設計了分級制度。
| 級別 | 條件 | 計畫文件 | 驗證員 |
|---|---|---|---|
| TRIVIAL | 3 行 diff 以內，且不觸碰規範層、不觸碰資料真相源（三條件必須同時成立） | 無 | 免 |
| S | 3 個檔案以內、純 UI 或文字與樣式修改、無架構影響 | 無（使用輕量口頭契約） | 輕量 |
| M | 標準路線圖任務、範圍明確 | 精簡版計畫（Plan） | 完整 |
| L | 架構變更、跨模組、新資料流 | 完整版計畫 + 耦合分析 | 完整 |
TRIVIAL 級別是實際運作後的自省產物。專案初期曾發生過僅僅 3 行程式碼的微調任務，卻跑了完整的 Planner 與 Evaluator 流程，白白燒掉大量 context 額度。這讓我意識到，流程本身也需要接受「最小解」的檢驗，因而開闢了這道逃生門。
系統預設任務為 M 級，符合條件時可自動降級。在執行過程中，如果發現變更範圍（diff）超出預期，AI 可以就地升級任務級別，不需重新請求人工核准。
技術細節：熱修復三分流規則與合約格式審查
在主線流程之外，臨時修正（hotfix）有其獨立的三分流機制：
- 變更在 3 個檔案以內：由主開發 AI 自產契約並執行。
- 變更介於 3 到 5 個檔案：委派獨立的規劃員 AI 產出契約。
- 超過 5 個檔案、違反既有決策，或影響 3 個以上待開發任務：硬性拒絕（REJECT），要求將任務升級進路線圖，走標準的 M 或 L 級流程。這是為了防止「臨時修一下」滾雪球成失控的大改動。
此外，在 P1 階段，合約形狀檢查會透過以下正則表達式（Regex）進行初步篩選，確保不含模糊詞彙：
(?i)(should|suggest|try|consider|maybe|normally|probably|hopefully|盡量|應該|建議|可能)若匹配成功，直接退回重寫。
與主流 Spec-driven 流派的異同
當前業界主流的規格驅動開發，例如 GitHub Spec Kit（走 Spec → Plan → Tasks → Implement 流程）或 AWS Kiro（走 requirements.md → design.md → tasks.md 流程），其核心方向與我的五段式流程一致：強調規格前置，以降低開發過程中的意圖漂移。
然而，五段式流程在實作細節上有以下三點本質上的差異：
- 驗收單位不同：Spec-driven 的產物是「規格文件」，業界公認的痛點是規格與程式碼容易隨著時間脫鉤。而五段式的產物是「可簽收的行為契約」，驗收即是比對行為，因此不存在規格脫鉤的問題。
- 內建分級機制：業界對 Spec-driven 的主要批評是「小修 bug 不值得如此高的流程開銷」。五段式從設計之初就內建了 TRIVIAL 與 S 級的逃生門。
- 獨立的裁判機制：Spec-driven 流派多半仍由同一個 agent 進行自查；五段式則強制委派獨立的 Evaluator 進行對抗驗證，詳見 AI 協作開發：多 Agent 對抗管線。
相關的主題實踐可以參考 AI協作開發-MOC、AI 協作開發：Context 節流與錨點術 以及 AI 協作開發：非技術 PM 的驗收閘門。
待辦事項
- 待辦：目前契約形狀檢查仍仰賴驗證員自律使用 grep，後續應將此步驟腳本化，改為確定性的程式檢查。