前三天寫的是驗收、問需求、寫 issue、開 Master issue。這四件事都準備好了之後，下一個問題是：動工的時候，範圍要開多寬。

我以前的答案很自然：既然都規劃好了，就照計畫把它做完。一份功能有五個部分，就五個部分一起寫，寫完一起驗。聽起來效率最高。

實際發生的事是：一個改了五千行的 PR，agent 標榜做完、我看了半天看不出問題、合進去之後第一個會用到的人說這條路根本走不通。回頭看程式碼，資料結構的部分是對的，操作介面憑 agent 自己的想像蓋了出來，中間從來沒有被人走過一次。

把一件事拆直

後來我在動工規則裡寫進一條約束：第一刀要切的一定是垂直切片。也就是範圍很小，但從頭到尾走得通的一條路，而不是把整個功能的某一層先做完整。

用蓋房子說，是把一層樓先蓋出來給人走一趟，確認樓梯、門、管線都在對的位置，再往上疊。不是先蓋完整個地基、再一次蓋完全部五層。

對我手上這種一個人加多個 agent 的開法，垂直切片有一個額外的好處：切片過得去 review 迴圈，甚至過得去自動出貨。一個範圍兩百行的 PR，agent 能真正讀完；一個兩千行的 PR，reviewer 和我都是在猜。

一次實際的拆法

cyclone-agent-config issue #201 對應 PR #202，這次的工作是給我的開發流程加一支 opt-in skill。從一個真實日期開始規劃時，我先在 issue 裡把範圍和「這次不做的事」都寫死。

範圍是四行：skill 本文、驗證腳本、安裝到四個 agent、Dashboard 同步一張卡。一條從寫出來、驗證、裝到手上全部 agent、再證明裝好了的路。

非目標寫了五條，包括不改全體預設規則、不做跨機器自動派工、不把特定幾隻 agent 納入 coding 預設板。那些都是這個功能最終要面對的問題，但不是第一刀。切片切就是要這麼狠，明知道旁邊都是洞，這次就是只補這一格。

issue 的驗收清單裡有一項是這樣的：

check_plan.py --first-slice 缺欄、空殼驗收、未寫測試指令時退出碼非 0

就是說，我讓一個腳本去擋 plans：一份只想說「我打算做」的文件，如果第一刀切得不垂直、驗收寫得空、沒有寫怎麼測，腳本直接擋下來，不准開 issue。

和「一次做完」的成本差在哪

同樣的功能，水平做完再驗，會在很後面才出現第一個能跑的版本。所有問題排隊累積到那個時刻一起爆，而那個時刻的 diff 已經大到沒有人（也沒有任何 agent）讀得完，review 變成簽名儀式。

垂直切片的方式，第一刀做完就有一條可驗證的路。它可能很粗糙，上面還缺後面四層的所有東西，但它每一格都真的走過：issue 開過、PR 審過、裝到環境跑過、證據留下了。後面的每一刀，都是沿著一條已經通的路在加寬。

這也回頭改變了 Master issue 的樣子。三十天的系列裡我先把 issue 寫成可驗收的工作單，再沿著切片一段一段往前，每一段各自有 start 也有 Finish。追蹤頁上不會出現一整排做了一半的方塊，而是出現一格一格真的走完的路。

明天

切片的目的是讓每一刀都能被驗收，那驗收的人是誰？我沒有同事。從明天開始的六天，我要寫 Unit 2：我自己一個人，怎麼安排 AI 寫的程式拿去給另一隻 AI 審。