六月底的一天，我開始陸續調整畫面，那次在一份需求文件上一次列了11個要調整的地方項目。多數是文字調整或小 bug：欄位文字要改、某個預設值該拿掉、確認頁該顯示姓名而不是人數。但裡面也夾了兩個真的要動邏輯的新功能，和一個要幫好幾個頁面補文件連結的工作。

11個需求，同一份文件，這只是我目前列出來要調整的冰山一角。距離 7 月 31 日上線，只剩一個多月。

• 11個任務混在一份文件裡，每項功能範圍有大有小。要先分類，才知道哪些能直接做、哪些要先討論後才做。
• 加開幾個 Agent 不會自動解決問題；因為同時放下去執行，工作會撞到同一塊地方，這件事得先被看見，才能決定合併還是排隊。
• 這一天最後分成三個批次處理，其中只有三件事走了完整的 Spec → Plan → 實作；其餘八件直接動手。這條分類與排批次的做法，後來就成立了指揮中心 /orchestrate。

一條流程，一次只針對一個功能

Day 06 到 Day 13，我把一個功能的開發走成一條完整、能交接的路：Spec 先講清楚要改什麼，Plan 讓 AI 把怎麼改攤開來，Task 拆成看得到、驗得到的工作，接著實作、寫 Scenario、資安審查、更新文件，一路做下去。

第三代開發初期，我幾乎都是這樣做：一個 Agent，照順序把 Spec、Plan、Task、實作到驗證跑完，大概 7 個步驟。需求一個一個來的時候，這條路走得很順——前一個做完、驗完、文件也更新了，才輪到下一個。

六月底那一天，這套就不管用了。11 件事同時躺在待辦上，如果還是照原本的節奏，一個做完才換下一個，我肯定沒辦法在時間內做完。

問題不是 AI 做得不夠快，是這條流程本來就是設計來一次服務一個功能的，現在同時來了 11 個。

先分類，不是先分工

11 個任務擠在同一份文件裡，我第一件事不是去想「要開幾個 Agent」，而是先搞清楚它們的範圍大小根本不一樣：

• 大部分是文字調整或小 bug：欄位說明要改、一個不該出現的預設值要拿掉、確認頁要顯示姓名不是人數。這種東西現況很清楚，不用討論，直接動手改就好。
• 有兩個是真的要動邏輯的新功能：一個是幫某個申請流程加一種新的填寫模式，一個是要依身分控制選單顯示什麼。這兩個要先講清楚範圍、會動到哪裡，也就是得走 Spec、Plan。
• 還有一個是文件工作：幫好幾個頁面補上說明文件的連結。

先分類，我才知道哪些能直接跳進 Step 5 動手，哪些要先停下來討論。說穿了這就是 Day 06 到 Day 09 那條「入口判斷」的邏輯，只是這次不是判斷一件事，是同時判斷 11 件。

再看誰會撞到誰

分完類還不能直接開工。我接著檢查這 11 件事會不會動到同一個地方，結果抓出 3 處：

• 一個所有申請都會經過的確認頁，被 4 項工作同時碰到。
• 系統共用的主要導覽框架，被 2 項工作同時碰到。
• 一個申請表單，被 3 項工作同時碰到。

如果沒先辨識出來，直接把 11 項功能分給 11 個 Agent 各做各的，很可能各自送出一份看起來沒問題、卻互相蓋掉對方的修改。

我的處理方式很直接：會撞到、但都只是小改文字的，合併給同一個 Agent 一次做完；會撞到新功能邏輯的，就讓新功能排到後面的批次，等前面的文字調整先做完、底稿穩了，才動手改邏輯。

真正要先處理的，從來不是「要開幾個 Agent」，是這 11 件事彼此的關係：哪些完全獨立、可以各做各的；哪些會撞在一起，要合併或排順序；哪些做完後，另一件才能安全開始。這件事沒先做，Agent 開再多，也只是把原本一個人要扛的混亂，同時複製成好幾份。

這正是 Day 07 提過的那個六月底

那 11 件事裡，有 3 件是真的要走完整 Spec → Plan 流程的新功能跟文件工作，我在 Day 07 已經從「Plan 怎麼成為平行實作的共同輸入」的角度講過一次：各自產出 Spec 跟 Plan 後，我先確認資料欄位路徑、固定值、必填條件這些技術問題，才讓範圍不重疊的 3 個實作分開進行，最後再彙整。

今天想換個角度，回頭看同一天：Day 07 講的是走完整流程的任務；同一天其實還有另外 8 件比較單純的調整，走的是完全不同的路——不用 Spec、不用 Plan，分完類、避開衝突就直接動手。

不是我當時想找機會試試多 Agent 能怎麼協作，是 11 件事同時到，總得先決定誰先誰後、誰會撞到誰，才輪得到談要不要走 Plan。

這套「先分類、再看衝突、需要討論的才停下來確認」的做法，後來被我寫成一套更完整的協調規則——就是接下來幾篇要談的指揮中心 /orchestrate。今天先不展開它怎麼分流、怎麼排批次，記住這個順序就好。

今天可以做的：先盤點，不要先開 Agent

今天不用建 Agent，也不用寫 /orchestrate 這種協調工具。挑你最近（或下週）同時在做、彼此可能會互相影響的 2–3 件工作，先寫一張最小的盤點表。

# 同時進行盤點

| 工作 | 目標 | 目前卡在哪一步 | 會讀／寫哪些檔案 |
| --- | --- | --- | --- |
| A |  |  |  |
| B |  |  |  |
| C |  |  |  |

- 哪兩件會碰到同一個檔案：
- 哪件做完，另一件才能開始：
- 哪件現在其實沒有人明確負責下一步：

如果你已經在用 Claude Code，可以先請它幫忙盤點，不要讓它動手：

請讀取這幾個功能相關的檔案，列出它們之間的重疊與相依：
哪些檔案會被多個工作改到、哪些工作有先後關係、哪些可以獨立進行。
只輸出分析，不要修改程式碼，也不要建立任何 Agent 或流程檔。

看完這張表，你至少會知道：這幾件事現在能不能一起做，還是得先講好順序。

小結：協調不是第 9 步，是另一層要設計的工作

六月底那一天讓我很清楚看到一件事：8-Step 沒有錯，它只是沒回答「同時很多個功能怎麼辦」。

能讓這 11 件事平行進行的，不是我多開了幾個 Agent，是我先把它們的關係理清楚——哪些能各做各的、哪些會撞在一起要合併或排順序、哪些需要人確認。

這是我在 Part 3 學到的第一件事：協調是一種要設計的工作，不是開多個 Agent 就可以完成的事。

下一篇要接著問：如果以後常態性都要面對這種同時進來的需求，Frontend、API、QA、Security、Documentation 這些反覆出現的工作，要怎麼變成可以交接、可以檢查的角色，而不是每次臨時再分工一次？

參考資料

• Anthropic. Building effective agents, 2024-12-19.
• Anthropic. Effective context engineering for AI agents, 2025-09-29.