學習筆記

TL;DR

To-Tickets 是一款自動化工具，能將一份完整的軟體開發需求規格（spec）拆解成多張可獨立開工、易於驗收，並標示出依賴關係的最小工作單元（工單），大幅提升開發任務的執行效率與 Agent 的協作能力。

快速結論

直接將一份詳盡的需求規格（spec）交付給 AI Agent 進行開發，會面臨效率低落的問題。主要挑戰包括 Agent 的上下文視窗限制導致任務無法一次完成，造成半成品；缺乏明確的階段性節點使得驗收困難；以及無法同時處理多個獨立任務，導致平行作業受阻。這些限制突顯了 spec 雖然是完整想法的表達，但並非有效的「工作單元」。

To-Tickets 旨在解決上述問題，它作為工程鏈中的關鍵一環，負責將 spec 拆解成多張能獨立開工、具備驗收標準的工單，並清楚標示工單間的依賴關係，最終發布到任務管理系統。其核心是採用「按功能垂直切片」的 "Trace Bullet" 拆解方法，每張工單都像一顆穿透所有層（邏輯、測試、介面）的子彈，確保完成後能有肉眼可見的變化，便於立即驗收與追蹤進度。

在拆解任務之前，To-Tickets 會進行一個關鍵步驟：讀取現有代碼。這一步驟至關重要，因為 spec 表達的是意圖，而代碼才是真實的應用實現邏輯和軟體的實際情況。透過讀取代碼，To-Tickets 能夠發現 spec 中未捕捉到的現有問題或隱藏的實現細節，避免因誤解或資訊不足而產出無效工單，確保最終生成的工單是基於系統現實情況的有效任務。

To-Tickets 不僅拆解任務，還會標註工單間的「阻塞關係」，這張依賴圖並非僅供人看的進度表，而是給 Agent 用來調度任務的訊號。它能確保沒有依賴關係的工單得以立即平行開工，最大化效率。最終，這個過程會產生一份可供人審核的工單拆解方案，經確認後才發布，確保人機協作的準確性與任務執行的順暢。

這支影片在說什麼

這支影片介紹了工程鏈三件套中的第三個關鍵工具—— To-Tickets，其主要功能是將影片前期產出的軟體開發需求規格（spec）拆解成可執行的工作單元（工單）。它著重說明了為何直接將一份完整 spec 交給 AI Agent 會遭遇效率問題，以及 To-Tickets 如何透過獨特的任務拆解方式（Trace Bullet）、依賴關係標註和前期代碼分析等步驟，有效解決這些痛點，產出能穩定開工的工單。這支影片適合關注軟體開發自動化、AI Agent 應用或任務管理效率提升的讀者。

最重要的 3-5 個重點

1. 直接交付完整 spec 的限制：將一份包含多個任務的 spec 直接交給 Agent 會導致三個主要問題：
   • 上下文視窗滿溢：Agent 做到一半，記憶體（上下文）已滿，可能只改了一半頁面，前後未接上。
   • 難以驗收：Agent 完成任務後，沒有明確的階段性節點，使用者只能通讀代碼去猜，無法有效驗收。
   • 無法平行作業：多個不相干的任務因被綁定在同一份 spec 中，只能排隊一件一件來，嚴重影響效率。
2. To-Tickets 的核心拆解方法：「按功能，垂直切片」（Trace Bullet）：
   • To-Tickets 將 spec 拆解成多張獨立工單，每張都帶有自己的驗收標準並標示依賴關係。
   • 其拆解原則是「按功能，垂直切片」，而非傳統的按層級（如：改所有測試、改所有元件、改所有樣式）拆解。
   • 每張工單都是一個「Trace Bullet」，能穿透所有層（如：內容選擇邏輯、測試、介面顯示），完成後會產生肉眼可見的變化，做完就能驗收。
3. 讀取代碼的重要性：
   • To-Tickets 在拆解任務前會「讀取代碼」，這一步是可選但非常有效。
   • 目的是理解真實的應用實現邏輯（代碼），而非僅依賴 spec 描述的意圖。
   • 透過讀取代碼，能發現 spec 中未提及或誤判的真實系統情況（例如：過濾條件雖存在但因數據標記缺失而無效），避免產生空轉或無效的工單，確保工單基於實際情況。
4. 依賴關係標註與平行化：

• To-Tickets 會在工單之間掛上「阻塞關係」，表明某張工單必須在另一張完成後才能開始。
  • 這張依賴圖是給 Agent 用來調度任務的「訊號」，而不是給人看的進度表。
  • 它能識別出沒有依賴關係的工單，讓這些任務可以立即平行開工，大幅提升執行效率。標記依賴關係時需要只標記清晰真實存在的依賴，避免過多或過少造成衝突或效率低下。

5. 人機協作與確認機制：
   • To-Tickets 拆解任務後，並非直接發布，而是會將方案呈現出來，反過來詢問使用者三件事：拆解是否正確（太粗或太細）、依賴關係是否正確、是否有需要合併或再拆開的工單。
   • 這個人工確認環節是有必要的，因為機器能給出粗稿，但某些細節（如兩件看似獨立但實則為一件的任務，或虛假的依賴）仍需人工判斷。確認後才會發布到任務管理系統。

知識架構

• 工程鏈三件套 (Skills Project)
  • To-Me：將模糊意圖理解清楚
  • To-Spect：將理解內容寫成清晰的 spec
  • To-Tickets：將 spec 拆解成可開工的工單
    • 直接交付 spec 的問題
      • 上下文視窗限制 (做到一半)
      • 難以驗收 (無階段性節點)
      • 無法平行作業 (效率低下)
    • To-Tickets 解決方案
      • 核心方法：任務拆解
        • 非傳統層級拆解 (例如：測試 -> 元件 -> 樣式)
        • "Trace Bullet" (按功能，垂直切片)
          • 每張工單穿透所有層 (邏輯、測試、介面)
          • 完成後有肉眼可見變化，可立即驗收
      • 依賴關係標註
        • 設定「阻塞關係」 (Blocking Relationship)
        • 作為 Agent 的「調度訊號」，實現平行開工
        • 只標記清晰真實存在的依賴
      • 前期準備：讀取代碼 (可選但有效)
        • 理解真實應用實現邏輯 (代碼才是真實情況)
        • 發現 spec 未捕捉的真實問題 (避免空轉)
      • 發布方式
        • GitTicket (利用 GitHub 原生阻塞關係)
        • 本地文件模式 (適合單人快速推進)
      • 確認機制：人機協作
        • 發布前提出拆解方案，反問使用者確認
          • 拆解粒度 (太粗/太細)
          • 依賴關係正確性 (合併/再拆)

關鍵概念

• spec: 規格文件，由 To-Spect 產出，是想法的完整表達，但不是工作單元。

• Agent: 影片中指能夠自動執行開發任務的 AI 代理。

• 工單 (Ticket): 由 To-Tickets 拆解而來，是能單獨開工、單獨驗收的最小工作單元。

• 上下文窗口 (Context Window): AI 模型處理資訊的限制，當輸入過長時會超過容量。

• Trace Bullet: To-Tickets 的核心拆解方法，指按「功能」垂直切片，每張工單穿透所有層（邏輯、測試、介面），完成後有肉眼可見的變化。

• 阻塞關係 (Blocking Relationship): 工單之間的依賴關係，表示一張工單必須在另一張完成後才能開始，用於調度 Agent 平行作業。

• 工程鏈 (Engineering Chain): 從模糊想法到可執行代碼的自動化流程，包含 To-Me, To-Spect, To-Tickets 等技能。

重要例子與細節

• 不拆解 spec 的問題具體例子
  • 上下文滿溢：Agent 可能改了首頁前面幾個地方，後面沒動，中間也沒接上，只拿到一個改了一半的單頁。
  • 無法驗收：Agent 跑了 40 分鐘回報做完了，但沒有明確的階段性節點，你可能只能通讀一遍代碼去猜。
  • 無法平行：明明有三件互不相干的事情可以同時讓三個 Agent 平行處理，但因它們全擠在同一份 spec，只能排成一隊一件一件來。
• Trace Bullet 拆解範例：首頁大圖改造
  • 原 spec 需求：首頁大圖老是被每天一篇的「早朵日報」頂掉，需改成鎖定最新一篇非「早朵」的長篇文章。
  • To-Tickets 會將此拆成一張工單，它同時動了三層：「內容選擇邏輯」、一條「覆蓋邊界的測試」，以及「首頁上那張肉眼可見的大圖」。做完後，打開首頁就能知道任務是否完成。一張工單的完成代表「做成了一件事」，而非「改完了一層」。
• 垂直切片不適用場景及其替代方案
  • 當要給一個在 40 個地方被用到的介面（interface）改簽名時，這種改動天生是跨一層的橫向修改。若硬要拆成垂直切片只會更糟。
  • 替代採訪（interim strategy）：新增新的介面，讓新舊並存，再把調用方一批批地簽移過去，最後刪除舊的。這將拆成三張工單，每一步都能單獨合併，但代碼整體保持可用。
• 讀取代碼發現 spec 盲點的案例
  • spec 需求：「大圖選最新的非『早朵』長篇文章。」聽起來沒問題。
  • To-Tickets 讀取代碼後發現：這個過濾條件其實早就寫在代碼中，首頁一直在用。但為什麼大圖還會被早朵頂掉？
  • 原因：全部 57 篇早朵文章中，只有 2 篇真的帶著「非早朵」的類型標記，剩下 55 篇沒有。導致過濾形同虛設，早朵仍順利進入首頁。
  • 結論：若照著 spec 把那條規則再寫下去會完全空轉。To-Tickets 因此多拆出 3 張工單，包含：「讓早朵能被認出來」、「補齊標記」，以及「列表改成混排」，這些都是 spec 裡沒寫，但翻開代碼才看得見的真實問題。最終拆出來 9 張工單，而非 spec 裡表面數出的 6 張。
• 依賴關係標記的層次與影響
  • 標少了：可能造成「撞車」，兩個 Agent 同時修改同一塊代碼。
  • 標多了：影響效率，本來能夠並行的三件事被排成一條隊伍。
  • 原則：只標記清晰真實存在的依賴。
• 發布到 GitHub 的具體實現
  • To-Tickets 支援兩種模式：發布到 GitTicket 等任務管理系統，或本地文件模式。
  • 發布到 GitTicket 時，工單的依賴關係會利用 GitHub 原生的「阻塞關係」功能，而非只是正面寫一句「依賴某某」的文字約定。GitHub 會真的把被阻擋的工單標示出來。
• 人機協作的實例
  • To-Tickets 拆解後，會把方案擺出來，反問使用者三個問題：拆解是否正確（太粗還是太細）、依賴關係對不對、有沒有要合併或再拆開的。
  • 案例回答：「大方向可以，但第一張工單需再拆開。」
  • 原因：原始工單包含「改判斷邏輯」（改動小立即見效）和「補 55 篇文章的標記」（一次性批次數據整理）。兩件事性質完全不同，混在一起會讓執行者難判斷何時完成。
  • 拆開的好處：後續工單只依賴於「改邏輯」這張工單，而不依賴於「補數據」（因為補數據不改變任何行為，不應阻塞其他任務）。確認後才發布。

可學習的洞察

1. 區分「意圖」與「工作單元」：一份完整表達「想法」的 spec，不必然是可直接執行、驗收的「工作單元」。理解這兩者的差異，是有效任務拆解

的起點。 2. 擁抱「垂直切片」的任務拆解思維：相較於傳統按層級（例如前端、後端、資料庫）的水平分層拆解，To-Tickets 的 "Trace Bullet" 垂直切片方法，能確保每個完成的工單都有具體可見的成果，更易於追蹤與驗收，符合現代敏捷開發的快速回饋精神。 3. 程式碼是「真相」，spec 是「意圖」：在自動化開發流程中，不能只依賴 spec 的描述。主動「讀取代碼」以校準 spec 的意圖與系統的真實現況，是避免浪費工時、確保任務有效的關鍵一步。 4. 依賴關係是「調度指令」，而非「進度標記」：精確標註任務間的依賴關係，其核心價值在於為自動化系統提供清晰的平行作業調度訊號，而非僅僅供人參考的專案進度表。只標記真實且必要的依賴，才能最大化平行效率。 5. 自動化流程中的人機協作價值：即使高度自動化，在關鍵的決策點（例如任務拆解方案的確認），仍需引入人的判斷來校準機器的「粗稿」。人機協作能確保自動化系統產出的結果，既符合技術效率，也貼合人類實際的業務邏輯與細微認知。

可行動的整理

1. 檢視目前的任務拆解模式：我的團隊或個人在拆解任務時，是習慣按層級（如 UI、邏輯、資料庫）還是按功能/垂直切片（從需求到呈現）？可以嘗試在小任務中應用「Trace Bullet」的垂直切片模式。
2. 養成程式碼審閱習慣：在接受或開始開發新功能前，除了閱讀 spec，應主動檢查現有相關程式碼，確認 spec 中描述的邏輯是否與實際代碼實現相符，避免潛在的「空轉」任務。
3. 優化任務管理系統中的依賴關係標註：若使用的專案管理工具（如 GitHub Issues, Jira）支援，應善用其原生的依賴關係或阻塞關係功能，而非僅以文字描述，以提供更精確的任務調度資訊。
4. 思考 AI Agent 在開發流程中的更多應用：To-Tickets 展示了 AI Agent 在任務拆解中的潛力。可進一步探索 Agent 在需求澄清（To-Me）、spec 編寫（To-Spect）、甚至代碼實作和審查等其他開發環節中的應用。
5. 在團隊內部建立人機協作點：即便引進自動化工具，也要規劃明確的「人機協作」環節，例如在關鍵流程（如任務拆解、設計方案）中設定審核點，讓人介入提供最終判斷或微調。

複習問題

1. 將一份完整的 spec 直接交給 Agent 會遇到哪三個主要問題？
2. To-Tickets 解決這些問題的核心方法是什麼？它與傳統的任務拆解方式有何不同？
3. 什麼是 "Trace Bullet"？它如何體現在工單的內容上？請舉例說明。
4. To-Tickets 在拆解任務前，為何要「讀取代碼」？這一步有什麼實際案例可以說明其重要性？
5. To-Tickets 拆解出的工單依賴關係，其「阻塞關係」標註的主要用途是什麼？為什麼說它是「調度訊號」而非「進度表」？

待確認資訊

無明顯待確認資訊。