Day 14 那天的 11 個任務，是我手動分類的：哪些是 bug、新功能、文字調整。後來這件任務寫進了指揮中心 /orchestrate，變成它收到任務檔之後、開始派工之前的動作。

指揮中心拿到一批需求，會先把每個任務解析一遍，再決定它要走哪條路。

• 指揮中心 /orchestrate 拿到一批需求，會先把每個任務解析一遍：判斷類型、抓異動檔案、看依賴。
• 規劃出三條路徑：純文字／bug fix 直接進實作；新功能走完整 8-Step，Plan 完成後停下等人；新建文件走精簡版。
• workflow 的成熟度，看它能不能照風險裁剪流程，而不是每件事都跑最重的那一套。

指揮中心先做的事：把每個任務解析一遍

指揮中心拿到任務檔，在派工之前會先把每個任務逐一讀過，抓出四件事：

• 這個任務是哪一類——新功能、Bug Fix、純文字調整、還是新建文件。
• 主要會動到哪些檔案。
• 有沒有依賴別的任務先完成。
• 誰負責。

這一步只認類型，不做分工。 誰做、怎麼排批次，是解析完之後的事。

三條路徑

認出類型之後，每個任務被送進對應的路徑：

六月底那天的 11 個任務，8 個任次走——文字改一改、預設值拿掉、確認頁顯示改一下，直接動手。剩下 3 個是真的要動邏輯的新功能和文件工作，走完整流程，在 Plan 那裡停下來讓我確認。

「任務」指的是任務檔裡的一個工作項目，例如「把某個欄位的文字改掉」或「新增一種表單模式」
「路徑」指的是這個任務要走完整 8-Step 裡的哪幾步

第二個維度：看檔案已經有什麼

類型不是唯一的判斷依據。還有一組跳步規則，看的是這個功能已經留下哪些檔案：

• spec.md 已經在了 → 從 Step 2 開始，不重寫 spec。
• plan.md 已經在了 → 從 Step 3 開始。
• tasks.md 已經在了 → 從 Step 4 開始。

已經做過、也確認過的部分不重做。 一個功能第二次被改的時候，通常不用再從「這功能要幹嘛」開始講。

分流之後停下來，讓人確認 human in the loop

分完流、排完批次，指揮中心會把整份分派計畫列成一張表——哪些任務直接做、哪些走完整流程、批次怎麼排——然後停下來，讓我看路由判斷對不對。這個確認很輕，看的是分類，不是程式。

真正需要我花時間的兩個關卡在後面，只有走完整流程的任務才會碰到：

• Plan 完成後：我確認這個做法符不符合我這次要開發的需求。
• 開發跟驗證都做完後：我做最後一次定版確認，才進到文件更新。

這兩個關卡從第三代一開始就有（Day 07 談過）。指揮中心沒有把它們拿掉，只是先幫我把「根本不需要走到這兩關」的任務篩掉了。

Anthropic 在〈Building effective agents〉裡把「先分類、再導向」這種做法叫 Routing，那篇文章開頭也講：先找最簡單能解決問題的做法，需要時才加複雜度。指揮中心的分流就是把這句話寫成規則。（Anthropic, Building effective agents）

今天可以做的：寫一張 change policy

先不用做成 skill。把你專案裡的變更分成幾類，每一類走什麼路、何時要升級、哪裡要人確認，寫成一張表：

# Change Policya

| 類型 | 判斷依據 | 走哪條路 | 停在哪 |
| --- | --- | --- | --- |
| 純文字／樣式 | 不動邏輯、不動資料 | 直接改、直接驗 | 做完給人看 diff |
| Bug fix | 有明確的錯誤行為 | 直接改，補一條回歸情境 | 做完給人看 |
| 新功能 | 動到資料、流程，或有新畫面 | 完整 spec → plan → … | plan 完成後停 |
| 升級條件 | 小改途中發現要動資料模型 | 退回走新功能那條 | 重新從 plan 確認 |

如果你已經知道是哪一個 spec、要從第幾步開始，用 /spec-workflow 那種單一流程就好；一批需求、範圍還不確定，才需要先分流。

小結：workflow 分流提高執行效率

把每件事都塞進完整的 8-Step，看起來嚴謹，實際上會讓小改動也要等 spec、等 plan。分流的價值是讓風險低的直接走、風險高的才慢下來，人的確認時間留給真的需要判斷的地方。

下一篇處理走完整流程的那幾個任務：它們能不能同時做，關鍵在會不會改到同一個檔案。

參考資料

• Anthropic. Building effective agents, 2024-12-19.