任務被標記為完成、而每個看到它的人對「完成」的認定不一樣時，缺的是驗收條件。主功能跑得起來算完成、測試全綠才算完成、文件同步更新才算完成——這三種認定同時存在，任務的狀態就不再承載資訊。

驗收條件（Acceptance Criteria）這個詞不陌生，而它在實際流程中常常淪為形式：「功能實作完成」、「測試通過」、「文件更新」——三條描述都無法在執行後被指認通過與否。

驗收條件是一份契約

核心定義：驗收條件是需求方與執行者之間的明確約定，雙方都能各自判斷任務是否完成。

關鍵在「雙方都能各自判斷」。判定的依據不是執行者事後說「差不多了」，而是在撰寫驗收條件的當下，就先把「怎樣算完成」定義好。

這延伸出四個性質：

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

可量化（Quantifiable）：「所有測試通過」不夠，要寫「77 個測試全數通過」這種可以核對的形式。量化讓驗收可以被計算。

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

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

四種情境，四種確認方式

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

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

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

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

建議驗收：執行過程中收到的建議，每一條都要有明確的處置（採納、拒絕或延後）。沒有處置的建議會停在半空中，下一次翻開這張 Ticket 的人無從判斷它算不算數。

證據，不是感覺

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

這看起來繁瑣，而它換到的是：三個月後翻開這張 Ticket 的人不需要重跑所有確認，就能看到當初怎麼通過的。

模糊詞彙讓驗收條件失效

幾個最常出現在驗收條件裡、而無法被確認的詞：

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

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

「適當」的判定住在每個人各自的感受裡。引用具體標準文件，寫「符合品質基線文件的測試覆蓋率要求」。

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

最低成本陷阱：用「或」連接的驗收條件

一條這樣寫的驗收條件：「SKILL.md 只列已實作指令，或實作缺失指令」。

這個「或」讓執行者面對兩個選項：刪除文件裡還沒實作的指令描述（省力），或去實作缺失的功能（耗時）。業務意圖沒有明說的情況下，執行者幾乎必然選第一個——而且選完之後，驗收條件會判定他通過。

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

由此得到一條規則：驗收條件不用「或」連接不同方案，不讓執行者自行選擇最低成本的方向。

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

業務意圖的三個宣告

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

「禁止結果」最常被省略，而它往往是防止最低成本陷阱最有效的護欄。明確寫下「不可損失規劃中的功能」，「刪除文件」這個選項就不再落在合格範圍內。

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

格式的選擇

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

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

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

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

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

驗收條件的本質是事先定義完成的樣子——這個動作把「這個任務究竟要達成什麼」的思考從結束後移到開始前。

Ticket 本身該怎麼切、切到什麼粒度才驗收得起來，走 Atomic Ticket 方法論；驗收條件在 Ticket 的哪個狀態被檢查、由誰檢查，走 Ticket 生命週期管理。