一位工程師可以同時推動多條工作流。
平行工作階段(parallel session)是另一個完整的 Claude Code 實例,在自己的 Git worktree 中處理獨立的任務。每個獨立的工作階段對其他工作階段一無所知,唯一的共同點是操控它們的工程師。
子代理(subagent)(在新分頁中開啟)在單一工作階段內運作,作為一個範圍受限的輔助角色,擁有自己的上下文視窗與工具限制,適合處理在多個任務中重複出現的工作,例如驗證應用程式是否如預期運作。
平行工作階段提高了工程師同時進行中的任務數量,而子代理則讓每個工作階段專注於自己的任務。工程師的工作就是操控並審查所有這些工作。
有何改變
| 傳統方式 | AI 原生方式 |
|---|---|
| 一位工程師一次只處理一項任務,並將一天/一週中相當大的一部分時間花在建置、測試與審查上。在等待期間切換任務雖然可行,但情境切換(context switch)相當累人,因此很少有人會這麼做。 | 一位工程師同時執行多個 Claude 工作階段,每個工作階段都在自己的 worktree 中處理各自的任務。重複性的工作會變成子代理,擁有自己的上下文與工具限制。工程師的工作轉變為協調,最終則轉向建置與監控迴圈。 |
開始使用
- 先決條件:
CLAUDE.md,因為所有工作階段都會讀取此檔案。回饋迴圈(第 4 階段:測試)在此也有幫助,因為當工作階段能夠驗證自己的工作成果時,工程師所需的監督就會減少。 - 基礎設施:一個 Git 儲存庫,因為隔離性來自 worktree,以及經過調整的權限設定,讓工作階段不必為組織認定安全的指令等待核准提示。
如何執行
- 工程師將工作拆分為涉及不同檔案的任務,利用計畫模式玩法(第 3 階段:建置)中的計畫來判斷哪些工作是獨立的。共用檔案的任務則在單一工作階段中依序執行。
- 每個平行任務都有自己的 worktree,例如在一個終端機中執行
claude --worktree feature-auth,在另一個終端機中執行claude --worktree fix-rate-limit。worktree 是在自己分支上的獨立簽出(checkout),可避免工作階段在檔案上發生衝突。 - 兩到三個工作階段是合理的起點。實際上限取決於一個人能妥善審查多少條工作流,因此只有在審查跟得上的情況下才增加工作階段。
- 將重複性的工作轉變為子代理,定義於
.claude/agents/中的 Markdown 檔案裡,每個子代理都有名稱、使用時機的說明,以及它可以觸及的工具。範例包括:在主代理完成後去除不必要複雜性的程式碼簡化器、執行應用程式並檢查行為的驗證器,以及探索程式碼庫並回報結果而不會淹沒主要上下文的研究員。將這些定義提交到 Git 中,讓整個團隊共享。
實際樣貌
.claude/agents/verifier.md:
markdown
---
name: verifier
description: Runs the app and checks the change works before the session reports done
tools: Bash, Read
---
Start the app with make run. Exercise the changed behavior and the two
nearest neighboring flows. Report what you ran, what you saw, and any
behavior that does not match plan.md. Do not fix anything; report only.治理考量
更多工作階段意味著更多產出,因此控制措施必須來自儲存庫中的設定。其中的 hook 與權限設定適用於所有工作階段,而工作階段所做的事情會被記錄下來,並歸屬於執行該工作階段的工程師。
如何衡量
- 領先指標:在審查品質維持不變的情況下,每位工程師的並行工作階段數(從 OpenTelemetry 匯出資料中計算),以及一天中花在操控而非等待上的時間比例。
- 落後指標:每位工程師每週合併的變更數,並對照依 PR 歷史記錄所判定的重工率一併檢視。