獨自駕馭 8 個工作階段！Claude Code 編排完整指南

「我在用 Claude Code，但規模一大，上下文就會溢出，精準度也跟著下降。」

「到頭來，我自己動手給 AI 下修正指令，反而成了最大的瓶頸。」

很多人大概都卡在這個階段。我一開始也是這樣，把程式碼、測試和設計討論全都塞進同一個對話，眼看著 Claude 的精準度隨著歷史記錄膨脹而下降。

我最近才發現，Claude Code 官方本身就提供了三種讓多個對話並行運作的機制。

而且這三種機制雖然相似，但其實各不相同；搞混它們可能會出問題。反過來說，如果能依照角色功能劃分，你甚至可以連一行程式碼都不用寫，就直接站上「指揮」的位置。

今天，我會一邊查證官方文件的主要資訊，一邊整理這三種機制，以及正確固定角色邊界的方法。

具體來說，我會拆解成一個配置，讓 8 個對話分別放在「指揮」、「實作」和「品質」這三個層級。

作為 bonus，我也會用主要資訊來說明，為什麼常見的解釋，例如「在 CLAUDE.md 寫角色 ID 來切換」或「用 SQLite 共享記憶」，跟官方機制有點落差。

我是 tatsuki（@nobel_824）。

我協助中小企業運用 AI，幫助他們在業務中導入 Claude / Codex，同時自己也整天在使用 Claude Code。並行運作是我在工作與個人專案中每天都會接觸的領域。

https://note.com/nobel/n/n8192ec07d689

1. 為什麼「把所有東西塞進一個對話」行不通

第一個陷阱，就是把太多資訊塞進單一個對話。無論 Claude 的模型再怎麼聰明，都會碰上結構上的限制。

具體來說，你會遇到這三個問題：

上下文污染：當實作程式碼、測試、除錯歷史和設計討論混在同一個上下文裡，推理的基礎會變得模糊，精準度就會下降。
指令衝突：如果「以速度優先實作」和「嚴格把關安全性」同時存在同一個地方，判斷就會變得模稜兩可。
Token 膨脹：每次都要載入龐大的歷史記錄，無論在時間還是成本上都很浪費。

解決方案是「讓自己成為單一指揮官，並安排一群專業化的 Claude」。這有點像 CTO 底下有 Tech Lead 和 Backend Lead，但重點不是感覺對了就好，而是要正確運用官方提供的 Claude Code 機制。

你今天可以採取的一個行動：想想你目前的對話，檢查是不是「實作」、「研究」和「審查」都共存於同一個上下文裡。如果是，那就是你開始拆分它們的起點。

2. 釐清官方提供的「三種並行機制」

這是這篇文章的核心。Claude Code 提供了三種實現並行的機制，各自的適用範圍不同。

第一種是 subagent（子代理，一個在獨立於主對話的上下文中運行的輔助 AI）。它使用自己的上下文視窗、專屬的系統提示詞和有限的工具權限來執行研究或審查等次要任務，並只將結果的摘要回傳給主對話。關鍵在於，subagent 在同一對話內運行，只向主對話回報，而且 subagent 之間不會互相溝通（官方文件）。

第二種是 agent teams（代理團隊，一個讓多個 Claude Code 對話以團隊形式協作的機制）。其中一個對話會成為團隊領導，並生成團隊成員，透過共享的任務清單和信箱來協作。與 subagent 不同的是，團隊成員之間可以直接互相傳送訊息。這是一個實驗性功能，預設是關閉的。你需要設定 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1，並使用 Claude Code v2.1.32 或更新版本（官方文件）。

第三種是 git worktree（一個 Git 功能，允許從同一個儲存庫建立多個工作目錄）。透過執行 claude --worktree feature-auth，Claude 會在不同的分支/目錄下的隔離環境中啟動。如果你在另一個終端機執行另一個實例，它們可以並行運行，不會互相干擾對方的檔案（官方文件）。在使用桌面版應用程式時，每個新對話都會自動建立一個 worktree。

以下是這三種機制的比較表格：

只要記住 worktree 負責檔案隔離，而 subagent 和 agent teams 負責工作本身的協調，就不會搞混了。

你今天可以採取的一個行動：先試著輸入 claude --worktree bugfix-test，感受一下啟動一個隔離對話的感覺。當你修改完畢並結束時，它會詢問你要保留還是刪除這個 worktree。

3. 實戰：在「3 層結構」中部署 8 個對話

這三種機制要如何轉化為 8 個對話？我使用的佈局是區分為「指揮」、「執行」和「品質」三個層級。

指揮/設計層（2 個對話）

對話 1 PM（專案經理）：負責整體進度管理、任務拆解、向人類回報。
對話 2 Architect（架構師）：決定技術一致性和目錄結構。需要計劃審批才能產出設計，而不會直接寫程式碼。

執行/實作層（4 個對話）

對話 3 Frontend（前端）：負責元件建立、UI 調整。
對話 4 Backend（後端）：負責端點實作、查詢最佳化。
對話 5 Infra/DevOps（基礎設施/開發維運）：負責 Docker、CI/CD 維護。
對話 6 Security（安全）：負責漏洞檢查、強化驗證機制。

品質/維護層（2 個對話）

對話 7 QA/Reviewer（品管/審查員）：負責 PR 審查、指出邊界案例。
對話 8 Technical Writer（技術寫手）：負責 README、API 文件維護。

這個佈局有三個訣竅：用 worktree 隔離執行層的四個對話，讓它們不會互相覆蓋檔案。將品質層的角色固定為 subagent 定義或 agent team 的團隊成員。並讓每個對話透過共用的 Markdown 檔案（例如設計筆記或審查結果）來傳遞資訊。Architect 更新設計，執行層根據設計進行開發，Reviewer 再將結果寫回檔案。人類只需要在這些檔案更新時，對各個對話下達指令即可。

需要注意：官方建議一個 agent team 的人數是 3 到 5 人，所以不要一次把全部 8 個對話塞進一個團隊裡（官方文件）。比較安全的做法是，結合 worktree 隔離的對話、一個 3 到 5 人的 agent team，以及視需求使用的 subagent，來達到總共 8 個工人的規模。

你今天可以採取的一個行動：從上面 8 個角色中，選兩個你覺得在你的專案中比較容易拆分出來的角色。在許多情況下，Architect 和 Reviewer 是首要的拆分點。

4. 用「Subagent 定義」固定角色邊界，而不是「CLAUDE.md」

讓我先澄清一個關於並行運作的常見誤解。你可能看過類似「在 CLAUDE.md 裡寫角色 (ID: arch, ID: dev-main...)，啟動時切換人格」的說明，但實際上並沒有這個機制。

CLAUDE.md 是一個 Claude Code 啟動時會讀取的共享指令檔案。然而，官方文件清楚說明，CLAUDE.md 是「上下文，而非強制設定」。因為它是在系統提示詞之後，以使用者訊息的形式傳遞，所以無法保證嚴格遵守。如果你有絕對想阻止的事情，應該使用 hooks（官方文件）。把它想成是一個強烈的建議，而不是絕對的「憲法」。

那麼，要在哪裡固定角色呢？答案是 subagent 定義。在 .claude/agents/ 目錄下建立一個檔案，並在 frontmatter 中指定名稱、描述、可使用的工具和模型，你就完成了一個可重複使用的專家。這是一個最小範例：

name: security-reviewer

description: 從驗證、輸入驗證和工作階段管理的角度，批判性地審查程式碼。

tools: Read, Grep, Bash

model: sonnet

你是一位資深安全審查員。專注於 token 處理、

工作階段管理和輸入驗證，並根據嚴重程度報告發現的問題。

此外，這些定義可以在 agent teams 中以名稱被呼叫為團隊成員。如果你要求「建立一個 security-reviewer 代理類型的團隊成員，來審查 auth 模組」，它就會成為一個繼承了該定義中工具和模型的成員（官方文件）。這種設計讓你可以將角色定義一次為 subagent 定義，然後同時作為 subagent 和團隊成員重複使用。

可以嘗試的提示詞範例（讓 Claude 建立角色定義）：

請建立一個要放在 .claude/agents/ 目錄下的 subagent 定義。

角色是「一位在實作程式碼中指出效能問題和 N+1 查詢的審查員」。

請在 frontmatter 中包含 name / description / tools / model，

並以資深工程師的角色來撰寫內文。

5. 用 Agent Teams 建立「Architect-Reviewer」團隊，提升精準度

在並行運作中非常有效的配置，就是分別設置一個「創造者」和一個「質疑者」。這不只是理論，官方文件也提供了實際範例。

在官方的「並行程式碼審查」範例中，針對一個 PR，設置了三個團隊成員分別負責安全性、效能和測試覆蓋率，各自從不同角度檢視，同時由領導整合結果。此外，在「競爭性假設」範例中，針對一個 bug，指派了五位團隊成員不同的假設，讓他們互相辯論並反駁對方的理論，將最後存活的理論視為根本原因（官方文件）。由於單一調查者容易偏向最初提出的理論，這種方法刻意製造衝突來提升精準度。

你也可以利用官方功能，讓 Architect「沒有寫程式碼的權限」。透過要求團隊成員的計劃必須經過審批，這個團隊成員會保持在唯讀的計劃模式，在領導批准之前只會產出設計。批准條件可以寫在領導的提示詞中，例如「只批准包含測試覆蓋率的計劃」。

可以嘗試的提示詞範例（一次性建立衝突結構）：

建立一個 agent team 來審查 PR #142。設置三個團隊成員：

一個負責安全性、一個負責效能、一個負責測試覆蓋率。

讓他們獨立審查，並根據嚴重程度輸出發現的問題，最後再整合結果。

有兩種顯示模式：in-process（所有團隊成員在同一個終端機運行，用 Shift+Down 循環切換）和 split panes（每個團隊成員在單獨的面板中；需要 tmux 或 iTerm2）。建議先從 in-process 開始，因為不需要額外設定。

6. 透過官方 Auto Memory（Markdown）共享記憶，而不是「SQLite」

當你運行多個對話時，下一個難關是「跨對話共享記憶」。雖然有時會介紹一些進階技巧，像是「將帶有標籤的記憶儲存在 SQLite 中，並動態注入」，但這並不是 Claude Code 的標準功能。透過 MCP（Model Context Protocol）建立資料庫是可行的，但你應該將它與官方提供的記憶機制區分開來。

官方的 auto memory 是使用 markdown 檔案運作的。在 ~/.claude/projects/<專案>/memory/ 目錄中，會放置像 MEMORY.md（索引）以及主題特定的檔案，例如 debugging.md，而 Claude 會在工作過程中寫入這些檔案。載入規則很明確：每個對話只會讀取 MEMORY.md 的前 200 行或 25KB，而 Claude 只會在必要時才會去讀取主題特定的檔案。這個功能從 Claude Code v2.1.59 開始提供，會根據每個儲存庫保存（所以在 worktree 之間共享），並且儲存在本地端（官方文件）。

這種設計的巧妙之處在於，透過「總是載入索引，只在需要時才擷取詳細資訊」，可以有效保持上下文視窗的整潔。即使有數千條小型規則，只要索引本身不膨脹，每次載入時上下文也不會受到污染。

在順序上，建議先充分利用官方的基於 markdown 的 auto memory，再考慮建立自訂的 SQLite 方案。

你今天可以採取的一個行動：在對話中輸入 /memory 會顯示目前載入的 CLAUDE.md 和 auto memory 檔案清單。先看看你的記憶體在哪裡、有多少。

7. 並行運作的三個陷阱（成本、資料庫、權限）

現在你已經了解了機制，這裡有三個操作上需要注意的重點。

首先是 Token 成本。官方文件指出，由於 agent team 中的每個團隊成員都有獨立的上下文，因此 token 使用量會與人數成比例增加。對於例行任務使用 5 個人，會導致成本上的損失。這就是為什麼官方建議是 3 到 5 人，並指出「三個專注的成員往往勝過五個分心的成員」（官方文件）。

第二是 worktree 的隔離範圍。Worktree 只是 Git 的一個檔案分離機制；資料庫、環境變數和正在運行的服務仍然是共享的。如果兩個對話對同一個本地資料庫執行遷移，就會出問題。官方文件警告要「記得在每個 worktree 中初始化開發環境（安裝依賴項、設定虛擬環境）」，如果任務會觸及資料庫，就需要分離 schema、Docker 容器或 .env 檔案（官方文件）。

第三是權限。團隊成員在被生成時，會繼承領導的權限設定。如果你用 --dangerously-skip-permissions 來運行領導，那麼所有團隊成員也會處於同樣的免確認狀態。由於事故的影響會以並行方式擴散，所以在領導端限制權限會比較安全。

8. 中階用戶 FAQ：人數、擴展與品質把關

最後，補充回答一些常見問題。

Q. 實際上執行多少個對話比較合理？

一個好的指導方針是之前提到的 3 層、8 個對話的結構。關鍵不是把 8 個人塞進一個 agent team，而是以一個 3 到 5 人的團隊為核心，並搭配 worktree 對話或 subagent。這與官方的建議一致（每個團隊 3 到 5 人，每個團隊成員 5 到 6 個任務）。最終的限制在於你能夠監控和引導的範圍。如果你把數量增加到超出你的指揮能力，效率就會下降。

Q. 如果 subagent 和 agent teams 都不夠用了怎麼辦？

如果你想從一個地方監控大量的獨立對話，官方的 subagent 頁面提到了一種稱為 background agents（背景代理） 的機制。你可以把它們視為不同層級：subagent 用於對話內的協助，agent teams 用於對話式的並行團隊，而 background agents 則用於管理大量獨立的對話。

Q. 如何保證品質？

CLAUDE.md 中的建議只是「容易遵循的指示」。對於你絕對想執行的檢查，請使用 hooks 來強制執行。Agent teams 提供了像 TeammateIdle、TaskCreated 和 TaskCompleted 這類 hooks；回傳結束代碼 2 會發送回饋並強制工作繼續進行（官方文件）。這意味著你可以透過程式化方式來強制執行規則，例如「在測試通過之前，不允許完成」。

總結：從監控者到設計者/授權者

Claude Code 的價值，比起單純加速寫程式碼，更在於讓一個人能夠控制多個專業化的 Claude。以下是重點摘要：

不要搞混三種機制：subagent 回傳結果，agent teams 是對話式團隊，worktree 則負責隔離檔案。將 8 個對話分為指揮、實作和品質三個層級；用 worktree 隔離實作，並用 subagent 定義或 agent teams 固定品質角色。在 subagent 定義而不是 CLAUDE.md 中固定角色邊界，並用 hooks 強制執行絕對規則。優先整理官方的基於 markdown 的 auto memory，再考慮建立自訂的 SQLite 方案。目標是每個團隊 3 到 5 人，並透過增加層級來達到 8 個工人的規模。

從今天開始可以嘗試的 3 個步驟：