垂直切片示蹤彈

資料來源#

• Full Walkthrough: Workflow for AI Coding — Matt Pocock

摘要#

借鑑 The Pragmatic Programmer，並由 Matt Pocock 將其應用於代理任務分解：規劃功能時，應採用垂直切片（穿過每一層的薄路徑——schema → service → API → UI），而不是水平切片（先完成所有 schema，再完成所有 service，最後完成所有 UI）。垂直切片能在第一個切片完成後提供端到端回饋；水平切片則要到第三階段才延後取得回饋。代理可靠地會預設採用水平分層——對代理友善的規劃必須主動抵消這種偏誤。

「示蹤彈」意象#

夜間的防空砲手看不見子彈飛向何處。塗有磷光劑的曳光彈在飛行中發光，每六發一枚，讓砲手能看見天空中的軌跡並修正瞄準方向。垂直切片也是如此：每個切片都會從端到端產生可見訊號，讓開發者（以及代理）能夠修正方向。

為什麼代理偏好水平分層——而且不該如此#

接受 coding task 訓練的代理，會逐層建立工作模型：

• 階段 1：所有 schema migration
• 階段 2：所有 service
• 階段 3：所有 UI

這種方式容易理解，但直到第三階段才會產生整合後的回饋。如果原始假設有任何問題（資料形狀、service 邊界、UI 流程），代價會在最後才付出。對代理而言，這甚至比對人類更糟，因為代理沒有能在過程中捕捉不匹配的端到端心智模型。

同一個功能採用垂直切片後會是：

• 切片 1：一種事件類型的 schema + 寫入一個事件的 service + 顯示一個事件計數的 dashboard 磚塊
• 切片 2：第二種事件類型、更深入的邏輯、更完整的 UI
• 切片 3：回填、潤飾、邊界案例

每個切片都會合併到 main。每個切片都會讓使用者有東西可以進行 QA。每個切片都能在下一個切片依賴它之前先完成 QA。

Kanban 優於多階段計畫#

任務完成垂直切片後，Pocock 主張採用帶有阻塞邊的 Kanban，而不是編號階段清單：

• 多階段計畫 ⇒ 一個代理一次處理一項任務，依序進行。
• 帶有明確阻塞邊的 Kanban ⇒ 多個代理可以並行取得未被阻塞的 ticket。

Kanban 會以 issues/ 中的 markdown 檔案（或 GitHub issues）具體呈現，並在 frontmatter 中明確標示 blocked-by:。每次迭代，Ralph loop 都會挑選下一張帶有 AFK 標籤且未被阻塞的 ticket。Pocock 的 Sandcastle 函式庫會平行執行這項選擇：planner agent 挑選 N 張平行 ticket，分派給位於 N 個 git worktree 中的 N 個 implementer agent，再由 merger agent 彙整。

切片品質規則#

Pocock 的 prd-to-issues skill 強制執行垂直切片規則。當代理提出的切片其實是水平分層——例如單獨「建立 gamification service」——規則就會觸發：

「我尤其希望在第一個垂直切片中看到 schema 變更，或至少一些 schema 變更。我希望看到有新的 service 被建立，也希望看到它在前端的最小呈現。」

「好的」第一個切片 =「在 dashboard 上看見課程完成所獲得的點數」（涵蓋 schema、service、route、UI）。

為什麼這不是敏捷加上額外步驟#

這套實踐的形狀，和 agile/XP 時代的薄切片相同。它現在之所以重要，是因為代理特別容易預設採用水平分層——可能是因為訓練資料中的大多數 coding tutorial/task 都是以這種方式組織的。若沒有明確推動，即使是強大的模型也會產出分層的結果。

相關連結#

• Matt Pocock — 主要闡述者
• Agent Loop Pattern — 垂直切片填充 AFK loop 的待辦清單
• Design Concept Grilling — 切片清單源自 PRD，而 PRD 源自 grilling session
• Context Window Smart Zone — 小切片適合 smart zone；水平階段則不適合
• Deep Modules for Agents — 垂直切片與 deep modules 彼此強化：切片穿過 deep module 的介面，測試你原本就想要的測試邊界
• Agent Harness Engineering — 在規劃層重新表述為「強制執行不變量」：不變量就是「每個切片都會產生可見回饋」
• Claude Code Best Practices — 填充 Kanban 待辦清單的任務分解模式，由 loop primitive 消化
• Building Is Cheap, Arguing Is Expensive — 示蹤彈是「建造一個薄而真實的東西來學習」的直覺；兩者都偏好已建成的產物，而非抽象論證
• Narrow Wedge into a Legacy Market — Campfire 的「最適合一種狹窄輪廓」是作為 GTM 的垂直切片：完整解決一位客戶的需求，而不是水平功能層

開放問題#

• 告訴 planner agent 要採用垂直切片後，就能信任它完成切片嗎？還是需要一個會標記水平切片的 verifier？Pocock 的經驗是：需要 verifier，至少在 4.7 之前如此。
• 應如何調整切片粒度？太薄 = 許多 merge conflict；太厚 = 回到水平分層。

資料來源#

• Full Walkthrough: Workflow for AI Coding — Matt Pocock