從一個問題出發

試想這樣一張 Ticket：「實作 ISBNScannerService 的 15 個測試」。

15 個不同的測試目標，掃描啟動、停止、ISBN-10 驗證、ISBN-13 驗證、離線快取、批次模式……每一項失敗都讓整張 Ticket 無法完成。負責人要同時記住 15 個目標才能判斷自己有沒有做完。

這不是一張 Ticket，是一份工作清單。

一張 Ticket，最少應該是什麼？

答案：一個動詞 + 一個目標。

什麼是 Atomic Ticket

1Atomic Ticket = 動詞 + 單一目標

核心特徵：

• 單一職責：只有一個修改原因
• 獨立驗收：不需要等待其他任務
• 不可再拆分：硬拆會產生循環依賴，表示這些部分本來就是一體的

四個原子性檢查

語義檢查

「這個 Ticket 能用動詞加單一目標描述嗎？」

符合：「實作 startScan() 方法」、「修復 ISBN 驗證邏輯」。

不符合：描述裡有「和」或「並」——「實作掃描功能和離線支援」通常是兩張 Ticket 擠在一起。

修改原因檢查

「只有一個原因會導致這個 Ticket 需要修改嗎？」

「實作 startScan()」只受掃描 API 規格影響，單一原因。「實作掃描功能和離線支援」則是 API 變更或儲存格式變更都會觸發修改——兩個原因，應拆成兩張。

驗收條件一致性

「所有驗收條件都指向同一個目標嗎？」

如果驗收條件同時涵蓋 startScan()、stopScan() 和離線快取，其實在同時驗收三件事，應該拆開。

依賴獨立性檢查

「如果拆成兩張，它們之間有循環依賴嗎？」

「實作掃描啟動邏輯」和「實作掃描狀態管理」互相依賴，硬拆反而讓兩張都無法獨立完成——這種情況維持為單一 Ticket 才對。

反過來，「實作 startScan()」和「實作 stopScan()」是單向依賴，可以安全拆分。

什麼不是判斷原子性的依據

常見的錯誤標準：時間、程式碼行數、檔案數量、測試數量。

這些都是結果，不是原因。一個單一職責的任務可能只需要 10 行，也可能跨越多個檔案改 200 行。判斷的唯一依據是職責是否單一。

行為分離：開發、測試、調整各自追蹤

1開發 (IMP) → 測試 (TST) → 調整 (ADJ)
2                  |
3               發現問題
4                  |
5           分析 (ANA) → 調整 (ADJ)

開發完成不代表測試通過，測試完成可能衍生調整。把這三種行為混在同一張 Ticket，就失去了「問題在哪個環節發生」的追蹤能力。

完整的追蹤鏈讓我們能回答：「這個修復是從哪一次測試失敗衍生的？那次測試又是為了驗證哪個開發任務？」

Ticket 類型定義

七種類型區分不同性質的任務：

• IMP（Implementation）：開發新功能
• TST（Testing）：執行測試驗證
• ADJ（Adjustment）：調整或修復問題
• RES（Research）：探索未知領域
• ANA（Analysis）：理解現狀和問題
• INV（Investigation）：深入追蹤問題根因
• DOC（Documentation）：記錄和傳承經驗

Ticket 關聯追蹤

每張 Ticket 記錄三個關聯欄位：

• source_ticket：觸發此 Ticket 的來源
• spawned_tickets：此 Ticket 衍生的後續 Ticket
• dispatch_reason：派發原因和交接理由

1開發 Ticket (IMP) 完成
2    |
3    | 衍生
4    v
5測試 Ticket (TST)
6    |
7    | 測試失敗，衍生
8    v
9調整 Ticket (ADJ)，dispatch_reason: "UC-01 測試失敗，需修復 ImportService"

Ticket ID 命名規範

1根任務：{Version}-W{Wave}-{Seq}
2子任務：{根ID}.{n}[.{n}...]

Wave 代表執行批次的依賴層級：W1 無依賴可並行，W2 依賴 W1，以此類推。

0.15.16-W1-001 是 v0.15.16 的 Wave 1 第一個任務。0.31.0-W3-002.1 是 0.31.0-W3-002 的第一個子任務。單看 ID 就能判斷它在版本工作流中的位置。

5W1H 驅動的欄位設計

每張 Ticket 的 YAML 欄位對應 5W1H：

• Who：負責人與各 Phase 的歷史負責人
• What：任務目標（動詞加單一目標）
• When：觸發時機
• Where：架構層級與影響的檔案清單
• Why：需求依據
• How：任務類型與實作策略

欄位設計讓 Ticket 本身就能完整描述任務全貌，交接時不需要額外解釋背景。

拆分範例

把功能清單拆成原子任務

原始需求：「實作 ISBNScannerService 的 15 個測試」

拆分後：

10.15.16-W1-001: 實作 startScan() 方法
20.15.16-W1-002: 實作 stopScan() 方法
30.15.16-W1-003: 實作 validateIsbn10() 驗證邏輯
40.15.16-W1-004: 實作 validateIsbn13() 驗證邏輯
50.15.16-W2-005: 實作離線掃描支援（依賴 W1）
60.15.16-W2-006: 實作批次掃描模式（依賴 W1）

W1 任務可並行，W2 等 W1 完成後進行。

知道什麼時候不該拆

需求：「實作 BookRepository.save() 方法」

有人可能拆成：Ticket A 實作簽名、Ticket B 實作邏輯、Ticket C 實作驗證。

這是錯的。save() 的簽名、邏輯、驗證三者循環依賴，硬拆後每張都無法獨立完成。正確做法是維持為單一 Ticket。

建立 Ticket 前的四個問題

1. 能用「動詞 + 單一目標」描述嗎？
2. 只有一個修改原因嗎？
3. 所有驗收條件都指向同一個目標嗎？
4. 如果拆開，不會產生循環依賴嗎？

常見的違反模式：「實作 X 和 Y」（兩個目標）、「修復所有 X 測試」（多個目標）、「重構 X 並優化 Y」（兩個行動）、「建立 X 的完整功能」（目標模糊）。

驗收條件（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 完成」。

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

結語

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

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