模組 4：精通 1 / 6
進階 Session 19 Multi-CLI Workflows

多 CLI 工作流

編排平行終端會話，最大化開發生產力。

2026年3月20日 20 分鐘閱讀

你將學到什麼

當任務規模超出單一 Claude Code 會話能有效處理的範圍時，最強大的模式就是同時運行多個終端會話 --- 每個都有自己完整的上下文視窗、自己的角色，以及自己的專注領域。

完成後，你將了解：

  • 為什麼多終端比單一會話更適合大型任務
  • 如何為每個終端指派角色
  • 終端如何透過檔案系統進行通訊
  • 用於協調工作的協調者模式
  • 何時使用多 CLI 與單一 CLI 搭配子代理

問題是什麼

單一 Claude Code 會話只有一個上下文視窗。當你實作的功能涉及資料庫結構、API 層、前端和測試套件時，單一會話必須不斷地將資訊換入換出。當一個會話在執行測試時，你只能乾等。當它深入重構時，你無法要求它規劃下一步。

根本限制：一個會話、一個焦點、一個上下文。

如何運作

多終端模式

┌──────────────────────────────────────────────────┐
│                  你的螢幕                          │
│                                                   │
│  ┌─────────────────┐  ┌─────────────────┐        │
│  │  Terminal 1      │  │  Terminal 2      │       │
│  │  ORCHESTRATOR    │  │  IMPLEMENTER     │       │
│  │  規劃工作        │  │  撰寫程式碼      │       │
│  │  審查結果        │  │  遵循計畫        │       │
│  └─────────────────┘  └─────────────────┘        │
│  ┌─────────────────┐  ┌─────────────────┐        │
│  │  Terminal 3      │  │  Terminal 4      │       │
│  │  VALIDATOR       │  │  FIXER           │       │
│  │  執行測試        │  │  讀取錯誤        │       │
│  │  回報問題        │  │  套用修復        │       │
│  └─────────────────┘  └─────────────────┘        │
│                                                   │
└──────────────────────────────────────────────────┘

每個終端運行自己的 Claude Code 實例，擁有完整的上下文視窗，專注於其專門角色。

透過檔案系統通訊

終端之間不會直接通訊。它們透過所有終端都能存取的東西來共享資訊：檔案系統。

project/
├── .tasks/
│   ├── plan.md              ← 協調者撰寫
│   ├── task-01-schema.md    ← 協調者撰寫，實作者讀取
│   ├── task-02-api.md       ← 協調者撰寫，實作者讀取
│   ├── progress.md          ← 實作者撰寫，協調者讀取
│   └── errors.md            ← 驗證者撰寫，修復者讀取
├── src/                     ← 實作者 + 修復者撰寫
└── tests/                   ← 驗證者執行，修復者修復

協議：協調者撰寫任務檔案。實作者讀取任務、撰寫程式碼、更新進度。驗證者執行檢查、撰寫錯誤報告。修復者讀取錯誤、套用修復。

協調者模式

┌─────────────────────────────────────────────────┐
│               協調者流程                          │
│                                                  │
│  1. 讀取需求                                     │
│  2. 分析程式碼庫結構                              │
│  3. 將工作拆分為順序任務                          │
│  4. 將任務檔案寫入 .tasks/                        │
│          │                                       │
│          ▼                                       │
│  5. 告訴實作者：「開始 task-01」                   │
│  6. 監控 progress.md 的完成狀態                   │
│          │                                       │
│          ▼                                       │
│  7. 當所有任務完成後，進行最終審查                 │
│  8. 撰寫摘要並提交                                │
│                                                  │
└─────────────────────────────────────────────────┘

上下文隔離的優勢

這是關鍵優勢：

單一 CLI（1 個會話，所有任務）：
  需求 + 結構 + API + 前端 + 測試 + 錯誤
  ████████████████████████████████████ 95%
  └── 所有東西塞進同一個視窗 ──┘

多 CLI（4 個會話，各有專精）：
  協調者：     ████████░░░░░ 40%   (計畫 + 進度)
  實作者：     ██████████░░░ 55%   (當前任務 + 程式碼)
  驗證者：     ██████░░░░░░░ 35%   (測試輸出 + lint)
  修復者：     ████████░░░░░ 40%   (錯誤 + 修復)

每個會話都有餘裕空間，沒有任何一個在上下文極限邊緣掙扎。

關鍵洞見

多 CLI 工作流是大型任務最強大的模式，因為每個終端都是擁有完整上下文視窗的專家，而不是擁有有限上下文的子代理。

子代理回傳的是摘要。它適合獨立的子任務。但對於持續的、多階段的工作 --- 每個角色都需要深入的領域認知 --- 完整的終端會話從根本上就更優越。

  • 子代理 = 傳訊息給同事，請他快速查一下某件事
  • 多 CLI 終端 = 一位完全沉浸在專案中其負責部分的專職團隊成員

檔案系統就是共享記憶體。任務目錄成為專案的協調匯流排。

實作範例

設置 4 終端功能工作流

Terminal 1 --- 協調者：

You are the ORCHESTRATOR for this feature. Your job:
1. Read the requirements I give you
2. Break them into numbered task files in .tasks/
3. Each task file contains: what to implement, which files, acceptance criteria
4. Monitor .tasks/progress.md for updates
5. Do NOT write code yourself — only plan and review

Feature: Add user profile page with avatar upload

協調者建立結構化的任務檔案：

<!-- .tasks/task-01-schema.md -->
# Task 01: Database Schema

## What
Add user_profiles table with avatar_url column.

## Files
- prisma/schema.prisma (modify)
- prisma/migrations/ (new migration)

## Acceptance Criteria
- [ ] user_profiles table exists with foreign key to users
- [ ] avatar_url is nullable string
- [ ] Migration runs without errors

Terminal 2 --- 實作者：

You are the IMPLEMENTER. Read task files from .tasks/ in order.
Implement each task. Update .tasks/progress.md when done.
Do NOT run tests. Start with task-01-schema.md.

Terminal 3 --- 驗證者：

You are the VALIDATOR. Run: pnpm test && pnpm lint && pnpm typecheck
Write results to .tasks/errors.md with exact error messages.
Do NOT fix errors — just report them clearly.

Terminal 4 --- 修復者：

You are the FIXER. Watch .tasks/errors.md for new entries.
Read the error, find root cause, apply minimal fix.
Do NOT change the overall approach.

何時使用多 CLI 與單一 CLI

使用單一 CLI：                    使用多 CLI：
├── 任務 < 30 分鐘               ├── 任務 > 1 小時
├── 涉及 1-3 個檔案              ├── 跨越多個層級的多個檔案
├── 線性工作流程                  ├── 可以平行工作
└── 全程相同領域                  └── 上下文會溢出

替代模式：
  2 終端：  規劃 + 執行
  3 終端：  前端 + 後端 + QA
  5 終端：  協調者 + 服務 A + 服務 B + 閘道器 + 測試

前後對比

單一 CLI多 CLI 工作流
一個上下文視窗處理所有事每個角色都有完整上下文
只能順序工作平行執行
大型任務時上下文滿溢每個終端保持精簡
一個通才會話多個專家會話
子代理的上下文有限完整會話擁有完整上下文

下一堂課

第 20 堂課涵蓋錯誤恢復 --- 如何建構重試邏輯、分類錯誤，以及設計備用策略，讓你的代理能優雅地處理失敗，而不是直接停擺。