測驗：多代理協作與完整工作流

共 5 題，點選答案後會立即顯示結果

1. 在編排者模式（Orchestrator Pattern）中，使用 `/orchestrate feature` 開發新功能時，Agent 的執行順序是什麼？

A. architect -> tdd-guide -> security-reviewer -> code-reviewer
B. explorer -> tdd-guide -> code-reviewer
C. planner -> tdd-guide -> code-reviewer -> security-reviewer
D. security-reviewer -> code-reviewer -> architect

2. Git Worktrees 的核心功能是什麼？

A. 把一個大型倉庫拆分成多個獨立的 Git 倉庫
B. 讓一個 Git 倉庫擁有多個工作目錄，每個在不同的分支上
C. 自動合併多個分支的程式碼變更
D. 把遠端倉庫的所有分支都下載到本地

3. 在 Context 切換中，`dev.md`、`review.md`、`research.md` 分別對應什麼行為模式？

A. dev 先研究再開發；review 快速修改；research 深度分析
B. dev 寫文件；review 跑測試；research 搜尋資料
C. dev 慢工出細活；review 自動修復問題；research 只讀不改
D. dev 衝刺速度先求有再求好；review 嚴格挑剔檢查品質；research 先理解再行動

4. `/multi-plan` 命令執行後會產出什麼？為什麼這個設計很重要？

A. 直接產出前後端的程式碼，因為自動化就是要快
B. 產出一份唯讀計畫文件，等你確認後才執行，因為計畫需要人類 review
C. 自動建立 Git 分支和 Worktrees，因為並行開發需要先準備環境
D. 產出測試案例，因為 TDD 流程要求先有測試

5. 以下是一個完整工作流的步驟，請問哪個排列順序是正確的？

A. /code-review（品質審查）
B. /plan（規劃架構）
C. /multi-plan（拆分前後端任務）
D. /verify（最終驗證）
E. /multi-backend + /multi-frontend（並行開發）

A. B -> E -> A -> C -> D
B. C -> B -> E -> D -> A
C. B -> C -> E -> A -> D
D. B -> C -> A -> E -> D

一句話說明

把前四篇學到的 CLAUDE.md、Agents、Commands、Hooks 全部串起來，讓多個 Claude 實例分工合作，自動完成從規劃到部署的整個開發流程。

為什麼你需要知道這個

前四篇你已經學會了所有零件：CLAUDE.md 設定規矩、Agents 分工專精、Commands 定義流程、Hooks 自動觸發。但這些零件各自運作，你還是得一步一步手動操作。

這篇要教你怎麼把它們組裝起來。就像一個工廠的生產線：原料進去、成品出來，中間的每個工序都有專人負責，自動銜接。

具體來說，你會學到：

編排者模式：一個主代理自動指揮多個子代理，依序完成「規劃 -> 開發 -> 審查 -> 驗證」
管線模式：前端和後端同時開發，各自有專屬的代理流程
Git Worktrees：讓多個代理同時在不同分支工作，互不干擾
完整工作流：從一個需求開始，全自動走完整個開發流程

多代理協作的兩種模式

Claude Code 的多代理協作有兩種主要設計模式。你不需要從頭寫程式來實現它們，everything-claude-code 倉庫已經提供了現成的 Slash Command 可以直接使用。

模式一：編排者模式（Orchestrator Pattern）

一個主代理（編排者）負責協調，多個子代理依序執行各自的任務。

你（人類）
  |
  v
/orchestrate feature "實作使用者登入功能"
  |
  v
主代理（編排者）
  |
  |-- (1) --> planner Agent         規劃架構
  |-- (2) --> tdd-guide Agent       寫測試 + 實作
  |-- (3) --> code-reviewer Agent   程式碼審查
  |-- (4) --> security-reviewer Agent  安全檢查
  |
  v
最終報告：SHIP / NEEDS WORK / BLOCKED
Code language: JavaScript (javascript)

翻譯：「你只要下一道命令，編排者就會自動叫不同的專家依序處理，最後給你一份完整的報告。」

最小範例：使用 /orchestrate

在 Claude Code 中輸入：

/orchestrate feature "新增使用者註冊功能，需要 email 驗證"
Code language: JavaScript (javascript)

這一行會觸發以下自動流程：

[Phase 1] planner Agent
  分析需求，設計 API 端點、資料庫 schema、前端頁面

[Phase 2] tdd-guide Agent
  根據計畫寫測試，再寫實作，確保測試通過

[Phase 3] code-reviewer Agent
  審查程式碼品質、邏輯錯誤、效能問題

[Phase 4] security-reviewer Agent
  檢查安全漏洞：SQL injection、XSS、密碼儲存方式
Code language: CSS (css)

逐行翻譯：/orchestrate 命令

讓我們拆解 /orchestrate 的使用方式：

/orchestrate feature "新增購物車功能"
#           ^^^^^^^ ^^^^^^^^^^^^^^^^^
#           |       |
#           |       任務描述（你要做什麼）
#           |
#           工作流類型（決定哪些 Agent 參與）
Code language: PHP (php)

可用的工作流類型：

類型	Agent 順序	適用場景
`feature`	planner -> tdd-guide -> code-reviewer -> security-reviewer	開發新功能
`bugfix`	explorer -> tdd-guide -> code-reviewer	修 bug
`refactor`	architect -> code-reviewer -> tdd-guide	重構程式碼
`security`	security-reviewer -> code-reviewer -> architect	安全審計
`custom`	你自己指定	特殊需求

自訂 Agent 順序的寫法：

/orchestrate custom "architect,tdd-guide,code-reviewer" "重新設計認證模組"
#                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#                    用逗號分隔你要的 Agent 順序
Code language: PHP (php)

翻譯：「我要自己決定誰先誰後：先讓架構師設計，再讓 TDD 專家實作，最後讓審查者檢查。」

Agent 之間怎麼傳遞資訊？

每個 Agent 完成工作後，會產生一份「交接文件」給下一個 Agent：

## 交接文件（Handoff Document）

### Context Summary（背景摘要）
使用者要求新增 email 驗證的註冊功能

### Key Findings（重要發現）
- 現有的 User model 需要新增 emailVerified 欄位
- 需要新的 /api/auth/verify-email 端點

### Modified Files（修改了哪些檔案）
- src/models/user.ts
- src/routes/auth.ts

### Open Questions（待確認問題）
- 驗證 email 的有效期要多長？

### Recommendations（建議）
- 使用 JWT 做驗證 token
- 加入 rate limiting 防止濫用
Code language: PHP (php)

這在幹嘛：確保每個 Agent 都知道前面的人做了什麼、發現了什麼，不用從頭開始理解整個專案。

最終報告長什麼樣？

所有 Agent 跑完後，編排者會生成一份綜合報告：

## Orchestration Report

### Summary
完成使用者註冊功能，包含 email 驗證流程。

### Agent Outputs
- planner: 設計了 3 個 API 端點、2 個資料庫遷移
- tdd-guide: 寫了 12 個測試，全部通過
- code-reviewer: 發現 2 個建議改進的地方（已修復）
- security-reviewer: 無安全漏洞

### Files Changed
- src/models/user.ts (modified)
- src/routes/auth.ts (new)
- src/services/email.ts (new)
- tests/auth.test.ts (new)

### Test Results: 12/12 passed
### Security Audit: CLEAN
### Recommendation: SHIP
Code language: PHP (php)

翻譯：「所有專家都檢查完了，沒問題，可以上線。」

模式二：管線模式（Pipeline Pattern）

前端和後端同時開發，各自有獨立的代理流程，最後合併。

你（人類）
  |
  v
/multi-plan "實作使用者儀表板"
  |
  +--> /multi-backend "建立 API"    +--> /multi-frontend "建立 UI"
  |      |                           |      |
  |      v                           |      v
  |    研究 -> 設計 -> 實作           |    研究 -> 設計 -> 實作
  |      -> 優化 -> 審查              |      -> 優化 -> 審查
  |                                  |
  +----------------------------------+
  |
  v
合併結果，整合測試
Code language: JavaScript (javascript)

翻譯：「先統一規劃，再兵分兩路同時開發前後端，最後合在一起。」

/multi-plan：統一規劃

/multi-plan "實作使用者儀表板，需要即時數據更新"
Code language: JavaScript (javascript)

這個命令會：

蒐集需求：分析你的描述，補充遺漏的細節
多模型分析：分別用不同的模型分析前端和後端需求
產出計畫：存成 .claude/plan/<feature-name>.md
等你確認：不會自動執行，等你 review 後才動手

重點：計畫是唯讀的。/multi-plan 不會改任何程式碼，只會產出一份計畫文件讓你確認。

/multi-backend：後端開發管線

/multi-backend "實作儀表板 API"
Code language: JavaScript (javascript)

這會依序走過六個階段：

[Phase 1: Research]  蒐集需求，評估完整度（需達 7/10 分以上）
[Phase 2: Ideation]  產出至少 2 個解決方案，評估風險
[Phase 3: Planning]  設計檔案結構、函式介面、依賴關係
[Phase 4: Execute]   實際寫程式碼
[Phase 5: Optimize]  檢查安全、效能、錯誤處理
[Phase 6: Review]    對照計畫做最終驗證

/multi-frontend：前端開發管線

/multi-frontend "實作儀表板 UI"
Code language: JavaScript (javascript)

流程跟 /multi-backend 類似，但關注點不同：前端注重元件設計、使用者體驗和互動邏輯。

兩種模式怎麼選？

情境	推薦模式	原因
修一個 bug	編排者模式 `/orchestrate bugfix`	單線任務，不需要並行
開發新功能（前後端都要改）	管線模式 `/multi-plan` + 並行	前後端可以同時進行
重構程式碼	編排者模式 `/orchestrate refactor`	需要全局視角，不適合拆分
安全審計	編排者模式 `/orchestrate security`	需要依序深入檢查
大型功能（多個服務）	管線模式 + 多個 worktrees	充分利用並行能力

Git Worktrees：讓多個代理同時工作

到目前為止，所有的代理都在同一個工作目錄裡。如果你想讓多個代理真正「同時」工作在不同的功能上，需要 Git Worktrees。

什麼是 Git Worktrees？

簡單說：一個 Git 倉庫，多個工作目錄，每個目錄在不同的分支上。

正常情況下，你的專案長這樣：

my-project/          <- 只有一個工作目錄，一次只能在一個分支上
  .git/
  src/
  package.json

用了 worktrees 之後：

my-project/              <- 主工作目錄（main 分支）
  .git/
  src/
  package.json

../my-project-feature-a/ <- worktree 1（feature-a 分支）
  src/
  package.json

../my-project-feature-b/ <- worktree 2（feature-b 分支）
  src/
  package.json

翻譯：「複製了多份工作目錄，每份在不同的分支上，但共用同一個 Git 歷史。改 feature-a 不會影響 feature-b。」

最小範例：建立 Worktrees

# 在專案根目錄執行
git worktree add ../project-feature-a feature-a
#                ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^
#                |                      |
#                新的工作目錄路徑         分支名稱

git worktree add ../project-feature-b feature-b
git worktree add ../project-refactor refactor-branch
Code language: PHP (php)

逐行翻譯

git worktree add ../project-feature-a feature-a
# 在上一層目錄建立一個叫 project-feature-a 的資料夾
# 裡面的程式碼是 feature-a 分支的版本
# 如果 feature-a 分支不存在，會自動建立

git worktree list
# 列出所有 worktrees，看看目前有哪些正在使用

git worktree remove ../project-feature-a
# 用完了，刪掉這個 worktree（不會刪分支，只是移除工作目錄）
Code language: PHP (php)

搭配 Claude Code 使用

每個 worktree 開一個 Claude Code 實例：

# 終端機 1：主代理在 feature-a 分支工作
cd ../project-feature-a && claude

# 終端機 2：另一個代理在 feature-b 分支工作
cd ../project-feature-b && claude

# 終端機 3：第三個代理在做重構
cd ../project-refactor && claude
Code language: PHP (php)

重要提醒：

# 進入 worktree 後，用 /rename 標記這個代理在做什麼
/rename feature-a-auth
Code language: PHP (php)

翻譯：「每個 Claude 實例都有自己的名字，這樣你開三四個終端機時不會搞混誰是誰。」

Worktrees 使用注意事項

做：
  - 每個 worktree 專注一個獨立功能
  - 用 /rename 標記每個實例
  - 確保 worktrees 之間的改動不重疊

不要做：
  - 兩個 worktree 改同一個檔案（會造成合併衝突）
  - 開太多 worktree（3-4 個是上限，再多你管不過來）
  - 忘記刪不用的 worktree（用 git worktree list 定期檢查）
Code language: PHP (php)

Cascade Method：管理多個實例的技巧

當你同時跑多個 Claude 實例時，用「瀑布法」管理：

終端機排列（從左到右）：

[最舊的任務] [較新的任務] [最新的任務]
     |              |            |
     v              v            v
  快完成了      進行中        剛開始

工作流程：
1. 新任務開在最右邊的終端機
2. 從左邊開始處理（最舊的先完成）
3. 完成一個就關掉，空出位置
4. 同時維持 3-4 個任務就好

翻譯：「像工廠流水線一樣，最老的任務在最左邊先處理完，新任務從右邊進來。」

Contexts：根據工作階段切換 AI 行為

前面提過 CLAUDE.md 是「通用規矩」。但不同的工作階段需要不同的行為模式。Contexts 就是讓你快速切換 Claude 的「工作模式」。

三種內建上下文

everything-claude-code 提供三個上下文檔案，分別對應三種工作模式：

dev.md — 開發模式

# Development Context

核心原則：
- 先寫程式，再解釋
- 能跑的方案優先，完美的方案其次
- 改完就跑測試
- 保持 commit 小而精

優先順序：
1. 先讓它跑起來（Get it working）
2. 再讓它正確（Get it right）
3. 最後讓它漂亮（Get it clean）
Code language: PHP (php)

翻譯：「開發模式下，Claude 會衝刺速度，先求有再求好。」

review.md — 審查模式

# Review Context

核心原則：
- 徹底檢查再給意見
- 按風險排序：嚴重 > 重要 > 一般 > 建議
- 提供修復方案，不只是批評
- 主動掃描安全漏洞

檢查清單：
- 邏輯錯誤
- 邊界情況
- 錯誤處理
- 安全漏洞（注入、認證、洩漏）
- 效能問題
- 程式碼可讀性
- 測試覆蓋率
Code language: PHP (php)

翻譯：「審查模式下，Claude 會變得挑剔，像一個嚴格的 code reviewer。」

research.md — 研究模式

# Research Context

核心原則：
- 先理解，再行動
- 先廣泛探索，再深入細節
- 多問問題，確認假設
- 記錄發現，延後實作

研究流程：
1. 理解問題
2. 搜尋相關文件和程式碼
3. 建立假設
4. 用證據驗證假設
5. 綜合結論
Code language: PHP (php)

翻譯：「研究模式下，Claude 不會急著寫程式，而是先把事情搞清楚。」

怎麼切換上下文？

透過 shell alias 快速啟動不同模式的 Claude：

# 在你的 ~/.bashrc 或 ~/.zshrc 加入這些 alias
alias claude-dev='claude --system-prompt "$(cat ~/.claude/contexts/dev.md)"'
alias claude-review='claude --system-prompt "$(cat ~/.claude/contexts/review.md)"'
alias claude-research='claude --system-prompt "$(cat ~/.claude/contexts/research.md)"'
Code language: PHP (php)

逐行翻譯

alias claude-dev='claude --system-prompt "$(cat ~/.claude/contexts/dev.md)"'
# alias claude-dev=     建立一個叫 claude-dev 的快捷指令
# claude                 啟動 Claude Code
# --system-prompt        指定系統提示詞（覆蓋預設行為）
# "$(cat ...dev.md)"     把 dev.md 的內容讀出來當作系統提示詞
Code language: PHP (php)

實際使用場景

# 場景 1：要開始寫新功能
claude-dev
> /orchestrate feature "新增購物車"

# 場景 2：功能寫完了，要審查
claude-review
> /code-review src/cart/

# 場景 3：遇到一個不熟悉的 codebase，要先研究
claude-research
> 這個認證模組是怎麼運作的？幫我畫出流程圖
Code language: PHP (php)

會話管理與檢查點

長時間的開發過程中，你需要能夠「存檔」和「讀檔」。Claude Code 提供了兩個關鍵命令來管理這件事。

/checkpoint：工作進度存檔

/checkpoint create "完成-API-端點"
Code language: JavaScript (javascript)

這在幹嘛：在目前的程式碼狀態建立一個存檔點，記錄時間戳、Git commit SHA、修改了哪些檔案。

逐行翻譯

/checkpoint create "完成-API-端點"
# 建立一個叫「完成-API-端點」的存檔點
# 背後會做 git stash 或 git commit 來保存狀態
# 把時間、名稱、SHA 記錄到 .claude/checkpoints.log

/checkpoint verify "完成-API-端點"
# 比對現在的狀態和之前的存檔點
# 會告訴你：改了什麼檔案、測試是否通過、覆蓋率變化

/checkpoint list
# 列出所有存檔點，包含時間和 Git SHA

/checkpoint clear
# 清掉舊的存檔點（保留最近 5 個）
Code language: PHP (php)

典型使用流程

# 開始開發
/checkpoint create "feature-start"

# 完成 API 端點
/checkpoint create "api-done"

# 完成測試
/checkpoint create "tests-done"

# 重構後，確認沒有退步
/checkpoint verify "tests-done"
# -> 比對顯示：12 個測試仍然通過，覆蓋率從 78% 升到 85%

# 準備發 PR，回顧所有變化
/checkpoint verify "feature-start"
# -> 顯示從開始到現在的所有改動
Code language: PHP (php)

翻譯：「就像遊戲存檔。每完成一個階段存一次，出問題可以比對甚至回到之前的狀態。」

/sessions：工作階段管理

/sessions list           # 列出所有過去的工作階段
/sessions load abc123    # 載入特定階段的記錄
/sessions alias abc123 "auth-feature"   # 給階段取個好記的名字
/sessions info abc123    # 查看階段的詳細統計
Code language: PHP (php)

這在幹嘛：管理你跟 Claude Code 的歷史對話記錄。每次啟動 Claude Code 都是一個新的 session，/sessions 讓你回顧和管理這些記錄。

記憶持久化：讓 Claude 「記住」上次做了什麼

Claude Code 透過 Hooks 實現自動記憶（這是第四篇 Hooks 的應用）：

會話生命週期：

[SessionStart Hook]
  自動載入上次的上下文和進度
    |
    v
[工作中...]
  學到新東西、發現新模式
    |
    v
[PreCompact Hook]
  Token 快用完前，保存重要狀態
    |
    v
[Stop Hook / SessionEnd Hook]
  保存這次學到的東西，供下次使用

翻譯：「每次開始自動讀取上次的筆記，結束時自動寫筆記。下次來就不用從頭開始。」

Token 優化策略

長時間工作會消耗大量 Token。以下是 everything-claude-code 推薦的優化方式：

策略	做法	節省效果
子代理分工	把任務交給子代理，主代理只保留摘要	大幅減少主代理的上下文長度
模型分級	簡單任務用 Haiku，一般任務用 Sonnet，複雜任務用 Opus	降低成本
CLI 取代 MCP	用 `gh pr create` 取代 GitHub MCP 持續佔用上下文	減少常駐 Token 消耗
模組化程式碼	每個檔案 200-400 行，不要寫大檔案	Claude 讀取更精準，Token 更少
PreCompact Hook	Token 快滿前自動保存狀態	避免丟失重要上下文

完整工作流實戰：從需求到部署

現在把前四篇的所有零件 + 這篇的多代理協作串起來，看一個完整的開發流程。

全景圖

需求 ──> /plan ──> /multi-plan ──> /multi-backend ──> /code-review ──> /verify ──> Hook 自動部署
  |        |          |               |                   |              |            |
  |     architect   拆分任務      TDD 開發         security-reviewer   最終驗證     PostToolUse
  |     Agent       前後端         Agent               Agent          Agent         Hook
  |
  |  [第1篇]     [第3篇]       [第2篇]            [第2篇]         [第3篇]       [第4篇]
  |  CLAUDE.md   Commands      Agents             Agents          Commands      Hooks
  |  Rules

步驟拆解

步驟 1：規劃（/plan）

claude-research
> /plan "實作使用者儀表板，顯示即時訂單狀態、銷售圖表、庫存警告"
Code language: PHP (php)

使用 research 上下文（先理解再行動）
architect Agent 會分析需求，產出架構設計
輸出：技術方案文件，包含 API 設計、資料庫 schema、前端元件規劃

步驟 2：拆分任務（/multi-plan）

> /multi-plan "根據架構設計，拆分前後端任務"
Code language: PHP (php)

分析步驟 1 的架構文件
產出前端任務清單和後端任務清單
存成 .claude/plan/dashboard.md
等你確認後才繼續

步驟 3：並行開發

用 Git Worktrees 建立並行環境：

# 建立 worktrees
git worktree add ../project-dashboard-api dashboard-api
git worktree add ../project-dashboard-ui dashboard-ui
Code language: PHP (php)

開兩個 Claude 實例：

# 終端機 1：後端
cd ../project-dashboard-api && claude-dev
> /rename dashboard-api
> /multi-backend "實作儀表板 API：訂單查詢、銷售統計、庫存監控端點"

# 終端機 2：前端
cd ../project-dashboard-ui && claude-dev
> /rename dashboard-ui
> /multi-frontend "實作儀表板 UI：訂單列表、銷售圖表、庫存警告元件"
Code language: PHP (php)

兩個代理同時工作，互不干擾。

步驟 4：TDD 開發（在步驟 3 中自動進行）

/multi-backend 和 /multi-frontend 內部都會走 TDD 流程：

寫測試（RED）-> 跑測試確認失敗 -> 寫實作（GREEN）-> 跑測試確認通過 -> 重構

這是第二篇 Agents 中 tdd-guide Agent 的工作。

步驟 5：品質把關（/code-review）

開發完成後，切換到審查模式：

claude-review
> /code-review src/api/dashboard/
> /code-review src/components/dashboard/
Code language: JavaScript (javascript)

code-reviewer Agent 檢查程式碼品質
security-reviewer Agent 檢查安全漏洞
按嚴重程度排序回報問題

步驟 6：最終驗證（/verify）

> /verify

跑所有測試
檢查建構是否成功
對照最初的 checkpoint 確認所有需求都有實作
產出 pass/fail 報告

步驟 7：Hooks 自動觸發

如果你在第四篇設定了相關的 Hooks：

[PostToolUse Hook: git push]
  自動提醒你 review 變更

[PostToolUse Hook: gh pr create]
  自動記錄 PR URL，建議下一步操作

[Stop Hook]
  保存這次的工作記錄，供下次參考
Code language: CSS (css)

完整流程時間軸

0 min   [研究模式] /plan 規劃架構
        architect Agent 產出技術方案
          |
15 min  [研究模式] /multi-plan 拆分任務
        產出前後端任務清單，等你確認
          |
20 min  [確認計畫] 你 review 計畫，OK 繼續
          |
25 min  [開發模式] 建立 worktrees，開兩個 Claude 實例
        /multi-backend 和 /multi-frontend 並行開發
          |
90 min  [開發完成] 兩邊都做完了
          |
95 min  [審查模式] /code-review + security review
          |
110 min [驗證] /verify 最終確認
          |
115 min [完成] 發 PR，Hooks 自動記錄

如何從 everything-claude-code 開始

如果你想直接使用這些功能，everything-claude-code 倉庫提供了完整的配置，可以快速導入。

快速導入步驟

# 1. Clone 倉庫
git clone https://github.com/affaan-m/everything-claude-code.git

# 2. 看一下有什麼
ls everything-claude-code/
# agents/     13 個專用 Agent
# commands/   31 個 Slash Command
# contexts/   3 個上下文檔案
# hooks/      自動化 Hook 設定
# rules/      語言分層規則
# skills/     16 個工作流技能
# scripts/    跨平台工具腳本

# 3. 複製你需要的配置到你的專案
cp -r everything-claude-code/agents/ my-project/.claude/agents/
cp -r everything-claude-code/commands/ my-project/.claude/commands/
cp -r everything-claude-code/contexts/ ~/.claude/contexts/
cp -r everything-claude-code/rules/ my-project/.claude/rules/
cp everything-claude-code/hooks/hooks.json my-project/.claude/hooks.json
Code language: PHP (php)

逐行翻譯

cp -r everything-claude-code/agents/ my-project/.claude/agents/
# 把所有 Agent 定義檔複製到你的專案
# 這樣你就能用 /orchestrate 叫它們幫你工作

cp -r everything-claude-code/commands/ my-project/.claude/commands/
# 把所有 Slash Command 複製過去
# 這樣你就能用 /plan, /tdd, /code-review 等命令

cp -r everything-claude-code/contexts/ ~/.claude/contexts/
# 上下文檔案放在全域目錄，所有專案都能用
# 搭配 alias 快速切換工作模式

cp -r everything-claude-code/rules/ my-project/.claude/rules/
# 複製語言分層規則
# common/ 通用規則 + 語言專用規則

cp everything-claude-code/hooks/hooks.json my-project/.claude/hooks.json
# 複製 Hook 設定
# 自動格式化、型別檢查、記憶持久化等
Code language: PHP (php)

導入後要做的事

1. 修改 CLAUDE.md
   加入你自己的專案資訊和常用指令

2. 調整 Rules
   刪掉不需要的語言規則，修改符合你團隊的規範

3. 設定 Contexts alias
   在 ~/.bashrc 加入 claude-dev、claude-review、claude-research

4. 測試基本流程
   試跑一次 /plan -> /tdd -> /code-review -> /verify

5. 根據需要微調
   每個 Agent 和 Command 都是 Markdown 文件，直接編輯就好

必看懂 vs 知道就好

必看懂（會一直用到）

編排者模式：/orchestrate 一個命令觸發多個 Agent 依序工作
工作流類型：feature、bugfix、refactor、security 四種預設流程
Git Worktrees：一個倉庫多個工作目錄，讓多個代理同時工作
Context 切換：dev.md（衝刺）、review.md（挑剔）、research.md（研究）三種模式
/checkpoint：工作進度存檔，隨時可以比對或回溯
交接文件：Agent 之間用結構化文件傳遞資訊，確保接手者有足夠上下文

知道就好（遇到再查）

管線模式：/multi-plan + /multi-backend + /multi-frontend 的並行開發流程，大型專案才需要
Cascade Method：管理多個終端機的技巧（左舊右新），開很多實例時再用
Token 優化：模型分級（Haiku/Sonnet/Opus）、CLI 取代 MCP，成本敏感時再研究
pass@k / pass^k 指標：驗證品質的度量方式，做自動化測試評估時再深入
自訂工作流：/orchestrate custom 自訂 Agent 順序，熟練後再自己設計

Vibe Coder 檢查點

當你在建立多代理工作流時，確認以下事項：

[ ] 每個 Agent 的職責是否明確？（一個 Agent 做一件事，不要混在一起）
[ ] Agent 之間的交接資訊是否足夠？（下一個 Agent 能不能看懂上一個的產出）
[ ] Git Worktrees 的任務範圍是否不重疊？（兩個代理不要改同一個檔案）
[ ] 是否有用 /checkpoint 定期存檔？（方便出問題時回溯）
[ ] Context 是否符合當前的工作階段？（開發時用 dev，審查時用 review）
[ ] 是否在跑完整流程前先用小功能測試一次？（不要第一次就用在大專案上）

常見問題

Q：多代理協作真的比一個 Claude 做完所有事更好嗎？ A：看任務複雜度。簡單的修改，一個 Claude 就夠了。但大型功能開發時，多代理有兩個優勢：每個 Agent 的上下文更聚焦（不會被無關資訊干擾），以及可以用 Worktrees 並行加速。

Q：/orchestrate 跑到一半失敗了怎麼辦？ A：這就是 /checkpoint 的價值。在 /orchestrate 之前建立存檔點，失敗了可以回溯。另外，每個 Agent 的交接文件會留下記錄，你可以看到失敗在哪個階段、原因是什麼。

Q：Context 切換會影響 CLAUDE.md 的規則嗎？ A：不會。--system-prompt 是額外的指示，CLAUDE.md 和 Rules 仍然會正常載入。Context 是「在現有規矩之上，增加工作模式的引導」。

Q：Git Worktrees 需要額外安裝什麼嗎？ A：不需要。Worktrees 是 Git 的內建功能，任何版本的 Git 都支援。只要你會用 git branch，就能用 git worktree。

Q：這麼多配置檔，會不會很難維護？ A：所有配置都是 Markdown 文件，直接用文字編輯器就能改。建議的做法是先用 everything-claude-code 的預設配置開始，遇到不合適的再調整，而不是一開始就客製化所有東西。

系列總回顧：五篇串起來的全貌

第 1 篇：CLAUDE.md & Rules
  告訴 Claude「你的規矩是什麼」
  -> 每次對話自動載入，統一行為
    |
    v
第 2 篇：Agents
  定義「誰負責什麼」
  -> 專用子代理各司其職
    |
    v
第 3 篇：Commands
  定義「怎麼做」
  -> Slash Command 一鍵觸發工作流程
    |
    v
第 4 篇：Hooks
  定義「什麼時候自動做」
  -> 事件觸發的自動化
    |
    v
第 5 篇（本篇）：多代理協作
  把以上全部「串起來」
  -> 多個代理分工合作，完整自動化

五篇加起來，你就有了一個完整的 Claude Code 進階配置體系。從規矩、到分工、到流程、到自動化、到協作，層層遞進。

本篇重點回顧

編排者模式（/orchestrate）：一個主代理依序指揮多個子代理，適合大部分場景
管線模式（/multi-plan + 並行）：前後端同時開發，適合大型功能
Git Worktrees：一個倉庫多個工作目錄，讓多個代理真正同時工作
Context 切換：dev / review / research 三種模式，透過 alias 快速切換
/checkpoint：工作進度存檔，定期建立可以回溯和比對
完整工作流：plan -> multi-plan -> 並行開發 -> code-review -> verify -> 自動部署
快速開始：clone everything-claude-code，複製需要的配置到你的專案

進階測驗：多代理協作與完整工作流

測驗目標：驗證你是否能在實際情境中應用所學。
共 5 題，包含情境題與錯誤診斷題。

1. 你的團隊需要開發一個新的「訂單管理」功能，涉及後端 API 和前端介面。你希望盡可能加速開發。以下哪種做法最適合？情境題

A. 用 /orchestrate feature 讓所有 Agent 依序處理完整功能
B. 直接開兩個 Claude Code 在同一個目錄，一個做前端一個做後端
C. 先用 /multi-plan 拆分任務，再用 Git Worktrees 建立兩個工作目錄，分別跑 /multi-backend 和 /multi-frontend
D. 用 /orchestrate custom 自訂一個同時包含前後端 Agent 的流程

2. 你接手了一個不熟悉的專案，需要先理解認證模組的運作方式，然後重構它。你應該如何搭配 Context 來完成這個任務？情境題

A. 全程使用 claude-dev，因為最終目標是重構程式碼
B. 先用 claude-research 理解現有架構，再切換到 claude-dev 進行重構，最後用 claude-review 檢查品質
C. 用 claude-review 審查現有程式碼就能理解架構，然後直接重構
D. 不需要切換 Context，直接用預設的 Claude Code 就好，Context 只是錦上添花

3. 你正在用 `/orchestrate feature` 開發一個支付功能，跑到 code-reviewer Agent 時發現了嚴重的架構問題。你應該怎麼處理？情境題

A. 忽略架構問題，讓流程繼續跑完，之後再單獨修
B. 直接手動修改程式碼，然後重新跑 /verify
C. 刪掉所有改動，從頭重新跑一次 /orchestrate
D. 用 /checkpoint verify 比對之前的存檔點，確認問題範圍後，用 /orchestrate refactor 針對架構問題重新走一輪

4. 小明想要讓兩個 Claude Code 實例並行開發，但他的做法出了問題。請找出錯誤所在。錯誤診斷

# 小明的操作步驟：

# 步驟 1：建立 worktrees
git worktree add ../project-auth feature-auth
git worktree add ../project-cart feature-cart

# 步驟 2：開兩個 Claude 實例
cd ../project-auth && claude-dev
cd ../project-cart && claude-dev

# 步驟 3：兩邊都開始工作
# 終端機 1 (auth)：修改 src/middleware/auth.ts 和 src/utils/token.ts
# 終端機 2 (cart)：修改 src/middleware/auth.ts 和 src/routes/cart.ts

# 結果：合併時出現大量衝突

A. 錯在步驟 1：worktree 的路徑不應該用 .. 前綴
B. 錯在步驟 2：應該用 claude-research 而不是 claude-dev
C. 錯在步驟 3：兩個 worktree 都修改了 src/middleware/auth.ts，任務範圍重疊導致合併衝突
D. 錯在步驟 2：沒有用 /rename 標記實例名稱，導致 Claude 分不清哪個是哪個

5. 小華在長時間開發中遇到了問題。她的工作流程如下，但結果不如預期。請診斷最關鍵的問題是什麼。錯誤診斷

# 小華的工作流程：

# 09:00 開始開發新功能
claude-dev
> /orchestrate feature “實作通知系統”
# 持續開發了 3 小時…

# 12:00 Token 快用完了，Claude 做了上下文壓縮（compact）
# 壓縮後，Claude 忘記了之前的架構決策和已完成的測試

# 12:05 小華嘗試繼續工作，但 Claude 開始重複做已經完成的事情
# 最後不得不重新開始

A. 問題出在沒有用 claude-research 模式，開發模式消耗 Token 太快
B. 問題出在沒有設定 PreCompact Hook 和沒有用 /checkpoint 定期存檔，導致上下文壓縮時丟失了重要狀態
C. 問題出在 /orchestrate 不適合長時間任務，應該用 /multi-plan 拆分成小任務
D. 問題出在沒有用 Git Worktrees，單一工作目錄無法處理大型功能

測驗：多代理協作與完整工作流

1. 在編排者模式（Orchestrator Pattern）中，使用 /orchestrate feature 開發新功能時，Agent 的執行順序是什麼？

2. Git Worktrees 的核心功能是什麼？

3. 在 Context 切換中，dev.md、review.md、research.md 分別對應什麼行為模式？

4. /multi-plan 命令執行後會產出什麼？為什麼這個設計很重要？

5. 以下是一個完整工作流的步驟，請問哪個排列順序是正確的？

一句話說明

為什麼你需要知道這個

多代理協作的兩種模式

模式一：編排者模式（Orchestrator Pattern）

最小範例：使用 /orchestrate

逐行翻譯：/orchestrate 命令

Agent 之間怎麼傳遞資訊？

最終報告長什麼樣？

模式二：管線模式（Pipeline Pattern）

/multi-plan：統一規劃

/multi-backend：後端開發管線

/multi-frontend：前端開發管線

兩種模式怎麼選？

Git Worktrees：讓多個代理同時工作

什麼是 Git Worktrees？

最小範例：建立 Worktrees

逐行翻譯

搭配 Claude Code 使用

Worktrees 使用注意事項

Cascade Method：管理多個實例的技巧

Contexts：根據工作階段切換 AI 行為

三種內建上下文

dev.md — 開發模式

review.md — 審查模式

research.md — 研究模式

怎麼切換上下文？

逐行翻譯

實際使用場景

會話管理與檢查點

/checkpoint：工作進度存檔

逐行翻譯

典型使用流程

/sessions：工作階段管理

記憶持久化：讓 Claude 「記住」上次做了什麼

Token 優化策略

完整工作流實戰：從需求到部署

全景圖

步驟拆解

步驟 1：規劃（/plan）

步驟 2：拆分任務（/multi-plan）

步驟 3：並行開發

步驟 4：TDD 開發（在步驟 3 中自動進行）

步驟 5：品質把關（/code-review）

步驟 6：最終驗證（/verify）

步驟 7：Hooks 自動觸發

完整流程時間軸

如何從 everything-claude-code 開始

快速導入步驟

逐行翻譯

導入後要做的事

必看懂 vs 知道就好

必看懂（會一直用到）

知道就好（遇到再查）

Vibe Coder 檢查點

常見問題

系列總回顧：五篇串起來的全貌

本篇重點回顧

進階測驗：多代理協作與完整工作流

1. 你的團隊需要開發一個新的「訂單管理」功能，涉及後端 API 和前端介面。你希望盡可能加速開發。以下哪種做法最適合？ 情境題

2. 你接手了一個不熟悉的專案，需要先理解認證模組的運作方式，然後重構它。你應該如何搭配 Context 來完成這個任務？ 情境題

3. 你正在用 /orchestrate feature 開發一個支付功能，跑到 code-reviewer Agent 時發現了嚴重的架構問題。你應該怎麼處理？ 情境題

4. 小明想要讓兩個 Claude Code 實例並行開發，但他的做法出了問題。請找出錯誤所在。 錯誤診斷

5. 小華在長時間開發中遇到了問題。她的工作流程如下，但結果不如預期。請診斷最關鍵的問題是什麼。 錯誤診斷

相關文章

【Claude Code 進階配置】#04 Hooks 與 MCP：事件驅動自動化與外部服務整合

【Claude Code 進階配置】#03 Agents 特化代理：讓 AI 扮演不同角色

【Claude Code 進階配置】#02 Commands 自訂斜線命令：打造你的開發快捷鍵

發佈留言取消回覆

1. 在編排者模式（Orchestrator Pattern）中，使用 `/orchestrate feature` 開發新功能時，Agent 的執行順序是什麼？

3. 在 Context 切換中，`dev.md`、`review.md`、`research.md` 分別對應什麼行為模式？

4. `/multi-plan` 命令執行後會產出什麼？為什麼這個設計很重要？

1. 你的團隊需要開發一個新的「訂單管理」功能，涉及後端 API 和前端介面。你希望盡可能加速開發。以下哪種做法最適合？情境題

2. 你接手了一個不熟悉的專案，需要先理解認證模組的運作方式，然後重構它。你應該如何搭配 Context 來完成這個任務？情境題

3. 你正在用 `/orchestrate feature` 開發一個支付功能，跑到 code-reviewer Agent 時發現了嚴重的架構問題。你應該怎麼處理？情境題

4. 小明想要讓兩個 Claude Code 實例並行開發，但他的做法出了問題。請找出錯誤所在。錯誤診斷

5. 小華在長時間開發中遇到了問題。她的工作流程如下，但結果不如預期。請診斷最關鍵的問題是什麼。錯誤診斷