Vertical Slice Tracer Bullets

資料來源#

• Full Walkthrough: Workflow for AI Coding — Matt Pocock

摘要#

這個做法源自《The Pragmatic Programmer》，由 Matt Pocock 引入代理程式任務拆解：規劃功能時，應採用垂直切片（穿過每一層的一條精簡路徑：結構描述 → 服務 → API → UI），而不是水平切片（先完成所有結構描述，再完成所有服務，最後才做所有 UI）。垂直切片能在第一個切片完成後就提供端到端回饋；水平切片則要等到第三階段才有回饋。代理程式很容易預設採用水平分層，因此面向代理程式的規劃必須主動抵消這種傾向。

「曳光彈」的意象#

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

為什麼代理程式偏好水平分層——以及為什麼不該如此#

以程式設計任務訓練的代理程式，會逐層建模工作：

• 階段 1：完成所有結構描述遷移
• 階段 2：完成所有服務
• 階段 3：完成所有 UI

這種做法清楚易懂，但直到第三階段才會有整合後的回饋。如果最初的假設有任何問題（資料形狀、服務邊界、UI 流程），代價就得等到最後才付出。對代理程式來說，這比對人類更糟，因為代理程式沒有端到端的心智模型，無法在過程中察覺不匹配。

同一個功能若採垂直切片，會像這樣：

• 切片 1：一種事件類型的結構描述 + 寫入一筆事件的服務 + 顯示一種事件計數的儀表板圖塊
• 切片 2：第二種事件類型、更深入的邏輯、更完整的 UI
• 切片 3：回填、潤飾、邊界情況

每個切片都會合併到 main。每個切片都能交付可供使用者 QA 的內容。每個切片都能在下一個切片依賴它之前先接受 QA。

看板勝過多階段計畫#

任務垂直切片之後，Pocock 主張採用帶有阻擋關係的看板，而不是編號階段清單：

• 多階段計畫 ⇒ 一個代理程式一次只處理一項任務，依序進行。
• 明確標示阻擋關係的看板 ⇒ 多個代理程式可以並行領取未受阻擋的票項。

這個看板會以 issues/ 中的 Markdown 檔案（或 GitHub issues）具體呈現，並明確標示 blocked-by: frontmatter。Ralph loop 每次迭代會挑選下一個標記為 AFK 且未受阻擋的票項。Pocock 的 Sandcastle 函式庫會平行執行這項挑選：規劃代理程式選出 N 張可平行處理的票項，分派給 N 個實作者代理程式，各自在 N 個 Git worktree 中工作，最後由一個合併代理程式整合成果。

切片品質規則#

Pocock 的 prd-to-issues skill 會強制遵守垂直切片規則。當代理程式提出的切片實際上是水平分層（例如只說「建立遊戲化服務」）時，規則就會觸發：

「我特別希望在第一個垂直切片中看到結構描述變更，或至少一些結構描述變更。我希望看到建立的新服務，也希望在前端看到它的最精簡呈現。」

「好的」第一個切片 =「課程完成時授予點數，並在儀表板上顯示」（涵蓋結構描述、服務、路由、UI）。

為什麼這不是多此一舉的敏捷開發#

這種做法的形式與敏捷／XP 時代的精簡切片相同。它如今之所以重要，是因為代理程式特別容易預設採用水平分層——可能是因為訓練資料中的多數程式設計教學與任務都採用這種組織方式。若沒有明確要求，強大的模型也會產出分層成果。

相關連結#

• Spec-Driven Development as the New Waterfall — 從敏捷而非《The Pragmatic Programmer》的角度，得出同樣「逐步增量、隨即檢視」的解方，並以變更成本作為經濟層面的論據

• Matt Pocock — 主要倡議者

• Agent Loop Pattern — 垂直切片填入 AFK 迴圈的待辦清單

• Design Concept Grilling — 切片清單來自 PRD，而 PRD 則來自概念盤問環節

• Context Window Smart Zone — 小切片能放進 smart zone；水平階段則不行

• Deep Modules for Agents — 垂直切片與深模組彼此強化：切片穿過深模組的介面，運用你原本就想要的測試邊界

• Agent Harness Engineering — 在規劃層重述為「強制不變條件」：不變條件是「每個切片都會產生可見回饋」

• Claude Code Best Practices — 填滿看板待辦清單的任務拆解模式，再由迴圈原語逐項消化

• Building Is Cheap, Arguing Is Expensive — 曳光彈體現了「打造精簡的實物來學習」這種直覺；兩者都偏好已建成的產物，而非抽象論證

• Narrow Wedge into a Legacy Market — Campfire 的「最適合某個狹窄客群」是 GTM 層面的垂直切片：完整解決一位客戶的需求，而非打造一層水平功能

開放問題#

• 切片的粒度該如何調整？太薄會造成許多合併衝突；太厚則會退回水平分層。

已解決問題#

• 告知規劃代理程式要做垂直切片後，是否就能信任它做好切片？還是需要能標記水平切片的驗證器？Pocock 的經驗是：需要，至少到 4.7 為止。已解答：Verifying Without a Compiler: Cowork's Harness vs Claude Code's, and Why the Slice Verifier Stays — 需要驗證器是設計使然，不只是經驗上的結論：切片形狀是可機械檢查的不變條件（票項是否涵蓋結構描述 + 服務 + UI？），可檢查的不變條件就該放進確定性檢查器，不論你是否信任模型。在提示中寫「垂直切片」是行為要求——受到訓練先驗影響時不可靠，行為原生化後還會不斷累積偏差；驗證器則是約束：它不會累積偏差、成本幾乎為零，也能捕捉任一方向的偏移。隨著模型進步，正確的方向是：當消融實驗顯示提示中的指示句已成為原生能力時，就移除它；檢查器則繼續保留，就像模型學會撰寫正確程式碼後，測試仍然有用。

衍生文章#

• Verifying Without a Compiler: Cowork's Harness vs Claude Code's, and Why the Slice Verifier Stays — 說明為什麼切片驗證器是持久的 harness，而切片指示只是暫時的提示

資料來源#

• Full Walkthrough: Workflow for AI Coding — Matt Pocock