驗收條件（Acceptance Criteria）這個詞不陌生，但在實際流程中，它往往淪為形式：「功能實作完成」、「測試通過」、「文件更新」——三條模糊的描述，沒有人能在執行後說出「這確實通過了」的具體理由。

驗收條件是一份契約

核心定義：驗收條件是用戶和執行者之間的明確約定，雙方都能清楚判斷任務是否完成。

關鍵在「雙方都能清楚判斷」。不是執行者自己說「差不多了」，而是在撰寫驗收條件的當下，就預先定義好「怎樣算完成」的標準。

這延伸出 4V 原則：

可驗證（Verifiable）：每一條都要有具體的確認方法。執行什麼命令？看什麼輸出？要寫明。

可量化（Quantifiable）：「所有測試通過」不夠，要說「77/77 個測試通過」。量化讓驗收可以被計算，不是被感覺。

可追溯（Traceable）：每一條都應該引用來源——哪個設計文件的哪一行、哪個規格的哪個章節。來源讓驗收有根據。

可記錄（Documented）：驗收結果必須能寫入文件，留下狀態標記。三個月後翻開 Ticket，能看到每一條是否通過、通過的證據是什麼。

四種情境，四種確認方式

不同性質的驗收項目需要不同的確認方式，混在一起只會讓「怎麼確認」這件事也變模糊。

功能驗收：程式功能是否正確實作。確認方式是執行命令、看輸出是否符合預期。

流程驗收：開發流程品質關卡——測試全綠、靜態分析無錯誤。確認方式是執行測試套件和工具輸出狀態。

文件驗收：文件是否正確更新。確認方式是檢查特定檔案存在、特定內容在正確位置。

建議驗收：Ticket 執行過程中收到的建議，每一條都需要有明確的處置（採納、拒絕或延後），不能讓建議懸在半空中。

證據，不是感覺

每一條驗收項目通過後，要留下對應的紀錄：命令輸出留命令和輸出文字、測試通過留「77/77 tests passed」、靜態分析留「dart analyze: 0 issues」。

這看起來繁瑣，但意義在於：三個月後翻開這個 Ticket 的人，不需要重跑所有確認，就能看到當初怎麼通過的。

模糊詞彙是驗收條件的天敵

幾個最常出現的危險詞彙：

「完成」沒有說完成的標準是什麼。換成「某子命令可執行並顯示預期的樹狀結構」。

「正常」沒有定義什麼叫正常。換成「輸入無效 ID 時顯示特定錯誤訊息」。

「適當」最危險，因為每個人的感受不同。引用具體標準文件，說「符合品質基線文件的測試覆蓋率要求」。

「符合規範」不說是哪個規範。要把規範文件寫出來。

最低成本陷阱：一個真實的故事

我們曾遇到這樣的驗收條件：「SKILL.md 只列已實作指令，或實作缺失指令」。

這個「或」讓執行者面對兩個選項：刪除文件裡還沒實作的指令描述（省力），或去實作缺失的功能（耗時）。在沒有明確業務意圖的情況下，執行者幾乎必然選第一個。

結果是技術上正確、業務上損失慘重——那些「未實作的指令」其實是規劃中的功能，刪掉等於丟失了產品藍圖。

從那以後我們立下一條規則：驗收條件不可以用「或」連接不同方案，不可以讓執行者自行選擇最低成本的方向。

正確做法是在撰寫驗收條件前先確認業務意圖：這個任務要解決什麼問題？根本原因是什麼？理想結果是什麼？什麼結果不可接受？回答這四個問題後，方向才能確定，而且只有一個方向。

業務意圖的三個宣告

每個 Ticket 的驗收條件要包含三個業務層面的說明：業務目標（要達成什麼）、期望結果（完成後應該是什麼狀態）、禁止結果（完成後不應該是什麼狀態）。

「禁止結果」最常被忽略，但它往往是防止最低成本陷阱最有效的護欄。明確寫下「不可損失規劃中的功能」，執行者就沒辦法假裝「刪除文件」是合理的選擇。

類似地，當文件和實作不一致時，不能用「修正不一致」帶過。要先判斷這個不一致的性質：規劃中的功能（保留並建立實作 Ticket）、錯誤記錄（移除）、過時功能（標記 deprecated）、重命名移動（更新引用）——四種情況對應四種處理方式，一條模糊的驗收條件無法涵蓋。

格式的選擇

三種格式對應不同複雜度：

簡單任務（五條以下）用清單，粗體標記項目，括號標記來源，後面說明確認方法。

中型任務用表格，有編號、項目描述、來源引用、確認方法、完成狀態，按功能/流程/文件分類。

複雜任務用分類格式，每個類別獨立表格，加上驗收摘要區段：「功能驗收 0/N 完成」、「流程驗收 0/N 完成」。

選格式的關鍵是任務是否跨越多個類別。只要同時涵蓋功能實作、測試品質、文件更新，就應該用分類格式。

結語

驗收條件的本質是「事先定義完成的樣子」。這個過程強迫我們在任務開始前就把終點想清楚，而不是結束後才爭論「算不算完成」。

我們從這套方法論得到最大的收穫是一種心態的轉變：當你開始認真設計驗收條件，你其實是在認真思考這個任務究竟要達成什麼。