Claude Squad 實戰場景：三種開發任務類型的最佳使用策略

前九篇把工具的每個角落都說清楚了——這篇是收尾，把它們組合成真實可用的工作模式。

三種最常見的開發任務類型，每種有各自的特性，也各自有最適合的 Claude Squad 使用策略。

任務類型一：功能開發

特徵：範圍清楚、有新增的程式碼、通常需要多個步驟（設計 → 實作 → 測試）

建議策略：

這種任務最適合用 Claude Squad 的多 session 分工模式。

不要把「幫我做完整個功能」丟給一個代理人——把它拆成獨立的部分：

Session 1：設計並實作 UserNotificationService
- 建立 service class
- 定義介面和方法簽名
- 實作核心邏輯

Session 2：寫 UserNotificationService 的 unit tests
- 等 Session 1 跑完後再開，這樣 Session 2 的 worktree 裡已經有 Service 的實作

Session 3：更新相關的 API endpoint
- PUT /users/:id/notifications/preferences

這三個 session 有先後關係（2 需要 1 的結果），所以不是真的完全並行——但你可以先開 1 和 3，等 1 跑完之後再開 2。

Auto-accept：功能開發建議不要開。代理人在設計決策的關鍵點可能需要你的確認，特別是涉及資料模型或架構選擇的時候。

Review 重點：檢查新增的抽象層是否合理、函式命名是否清楚、有沒有引入不必要的複雜度。

任務類型二：Bug 修復

特徵：目標明確（讓 X 停止發生）、範圍通常比功能開發小、有時候需要偵探式的排查

建議策略：

Bug 修復最適合單一 session + auto-accept 的模式。

提示詞要把症狀和已知線索都說清楚：

有使用者回報登入之後立即被登出的問題。
重現步驟：
1. 用 Google OAuth 登入
2. 重新整理頁面
3. 發現已登出

相關檔案：
- src/auth/GoogleOAuthHandler.ts
- src/middleware/SessionMiddleware.ts
- src/services/UserSessionService.ts

請先排查這三個檔案，找出問題根源，修復後寫一個 regression test 確認問題不再發生。

信息越完整，代理人走偏的機率越低。

Auto-accept：通常可以開，Bug 修復的範圍通常比較有限，代理人不太會改到意料之外的地方——但如果 bug 的根源可能涉及多個模組，建議不要開，讓代理人在關鍵確認點停下來跟你報告。

Review 重點：除了確認 bug 修掉了，更重要的是確認修法沒有引入新的問題。新增的 regression test 跑過了嗎？修改的邏輯有沒有改到其他地方的行為？

任務類型三：程式碼重構

特徵：範圍廣、改動多但預期不改變行為、最容易出現意外的副作用

建議策略：

重構是 Claude Squad 三種任務類型裡最需要謹慎的一種。

分批次進行，不要一次重構太多：

# 第一批：只重構 utils/ 目錄下的 helper functions
Session 1：把 utils/dateUtils.ts 裡的函式都加上型別標注
Session 2：把 utils/stringUtils.ts 裡重複的邏輯合併

# 第二批：等第一批 review 通過之後
Session 3：把呼叫這些 utils 的地方更新到新的函式簽名

Auto-accept：重構強烈建議不要開。重構涉及的改動範圍廣，代理人自動跑過去的決策可能在你不注意的地方埋下問題。重構的每個關鍵決策點，你都應該在場確認。

Review 重點：行為有沒有改變（測試有沒有過）、改動的範圍是否在預期內、有沒有意外改到不相關的地方。

三種類型的速查表

任務類型	Auto-accept	Session 數量	最重要的 Review 重點
功能開發	不建議	2-3 個（分工）	架構決策、命名
Bug 修復	通常可以	1 個（集中）	修法的副作用
程式碼重構	不建議	1-2 個（分批）	行為是否改變

一個完整工作日的 Claude Squad 使用流程

早上進公司，今天的任務板上有四件事：

新功能：加入 email 通知設定
Bug：修復 iOS Safari 的 CSS 問題
重構：把 AuthService 裡的 JWT 邏輯整理乾淨
文件：更新 API 文件

# 開 Claude Squad
cs -y   # 文件任務可以用 auto-accept

安排：

Session 1：email 通知設定的 Service layer（功能，不開 auto-accept）
Session 2：iOS Safari CSS 修復（Bug，可以開 auto-accept）
Session 3：API 文件更新（文件，低風險，auto-accept 合理）

AuthService 重構先不開——等有比較完整的時間段，慢慢審查比較安心。

三個 session 跑著的時候，你去開今天的 stand-up meeting，回來看 diff，審查，push PR。

這就是 Claude Squad 設計要達到的工作模式：你是決策者和審查者，代理人是執行者。你的時間花在判斷和決策上，不是在重複性的打字上。

系列回顧

如果你是按順序讀到這裡，你現在有：

Claude Squad 的完整心智模型（篇 1）
可以動的環境（篇 2）
TUI 操作技能（篇 3）
對 worktree 隔離的理解（篇 4）
Auto-accept 的使用判斷（篇 5）
並行工作流的設計方法（篇 6）
設定多個 AI 工具的能力（篇 7）
完整的 review 流程（篇 8）

把這些組合起來，然後在真實的任務上試幾次。工具的邊界感只有實際用過才會有。

上一篇：Review、Commit、Push：代理人跑完之後的完整審查流程 回到系列起點：Claude Squad 入門指南：系列導覽