多代理人並行開發：用 Claude Squad 同時跑三件事的工作流設計

理解了 worktree 隔離和 auto-accept 模式之後，這篇把它們組合起來——真正的多代理人並行開發工作流長什麼樣。

這不是理論，是可以直接套用的模式。

並行開發的核心前提

在開始之前，先確認一件事：你要並行的任務，彼此之間是否有依賴關係？

Claude Squad 的 worktree 隔離確保了並行不會在「執行中」互相干擾，但如果兩個任務最終都改了同一個地方，merge 的時候還是得解決衝突——這是 git 的正常流程，不是 Claude Squad 的問題。

最理想的並行場景：任務之間沒有程式碼層級的重疊。

假設你今天有三件事要讓代理人處理：

這三件事互相獨立，改的是不同的地方，完全可以並行。

cs -y

這些任務都是低風險的，文件和測試幾乎不會有破壞性的改動，auto-accept 合理。

按 N，輸入第一個任務的描述：

幫我補完 src/api/users.ts、src/api/posts.ts、src/api/comments.ts 裡所有 endpoint 的 JSDoc，
包含 @param、@returns、@throws。格式參考現有最完整的那個 endpoint。

建立完第一個之後，再按兩次 N，分別輸入：

幫我為 src/services/UserService.ts 寫 unit test，
用 Jest，目標覆蓋率 80%，測試檔案放在 src/__tests__/UserService.test.ts

把 src/ 裡所有直接讀取 process.env 的地方，
統一改成透過一個新建的 src/services/ConfigService.ts 來存取。
ConfigService 要有型別定義，缺少必要環境變數時要在啟動時拋出明確的錯誤訊息。

三個 session 都建立了，代理人都在跑——這時候你可以：

TUI 的左側清單會顯示每個 session 的狀態，你不需要盯著它。

過了一段時間，回到 Claude Squad，用 ↑/↓ 在 session 之間切換，看右側的輸出。

如果某個 session 卡住了（例如代理人在等一個你沒預期到的輸入），按 ↵ 附加進去補充說明，然後 ctrl-q 回到 TUI。

每個 session 跑完，按 tab 切到 diff 視圖：

這個審查步驟不能省——這是「代理人執行 + 人工確認」的分工界線。

每個 session 審查完、確認沒問題，按 s push 到 GitHub，然後開 PR。三個 PR 各自獨立，可以同時開出來，讓 CI 並行跑，你或 reviewer 各自 review。

同時跑 2-3 個任務：最容易管理，review 的認知負擔不會太重。

同時跑 4-5 個任務：可以，但你要確認每個任務都夠獨立，review 的時間也要抓夠。

超過 5 個：這時候你的瓶頸通常不是代理人的執行速度，而是你自己的 review 速度。堆太多任務，只是讓 diff 堆積——你最後還是得一個一個看。

並行開發的品質很大程度取決於「你怎麼拆任務」，而不只是工具用得好不好。

一個 session = 一個明確的邊界：「幫我把整個後端重構好」不是一個好的 session 任務。「把 UserController 裡的資料庫操作移到 UserRepository」才是。

給代理人足夠的上下文：提示詞裡說清楚要改哪些檔案、參考哪個現有實作、什麼情況算完成。代理人收到的資訊越具體，走偏的機率越低。

避免跨 session 的程式碼依賴：如果任務 A 要新增一個函式，任務 B 要呼叫那個函式——這兩個任務不適合同時跑，因為 B 的 worktree 裡還沒有 A 新增的函式。

掌握了並行工作流之後，下一步是讓 Claude Squad 記住你的工具偏好——設定 profiles，讓不同任務可以用不同的 AI 代理人。