任務圖與依賴關係
學習 Claude Code 如何用依賴邊協調多個任務，實現複雜工作流程。
你將學到什麼
在第 3 堂課中，你學了 TodoWrite 如何建立扁平的任務清單。但真實的專案並不是扁平的 — 任務之間互相依賴。你不能在 API 還不存在時就撰寫整合測試，也不能在測試通過前就部署。
完成後，你將了解：
- 任務如何形成帶有依賴邊的有向無環圖（DAG）
- Claude Code 如何判斷哪些任務可以平行執行、哪些必須依序執行
- 按正確順序執行任務的圖遍歷演算法
- 如何組織提示詞以產生結構良好的依賴圖
問題是什麼
扁平任務清單看起來像這樣：
□ 建立資料庫遷移
□ 新增 API 路由
□ 建立認證中介層
□ 撰寫整合測試
□ 更新前端AI 從上到下依序處理這些任務。但這遺漏了關鍵資訊：
- 浪費的循序執行 — 「建立資料庫遷移」和「新增 API 路由」可以平行執行，但扁平清單強制它們必須循序處理
- 不正確的排序 — 沒有機制阻止「撰寫整合測試」在 API 路由還不存在時就執行
- 連鎖失敗 — 如果「建立認證中介層」失敗了，AI 不知道哪些下游任務現在被阻塞了
這些問題隨著任務清單增長而倍增。一個包含隱藏依賴關係的 15 項實作計劃是回溯和浪費上下文的溫床。
如何運作
任務即 DAG
當 Claude Code 規劃複雜工作時，任務自然形成有向無環圖。每個任務是一個節點，依賴關係是邊：
┌──────────────┐
│ Analyze │
│ Requirements│
└──────┬───────┘
│
┌────────┴────────┐
│ │
▼ ▼
┌────────────────┐ ┌────────────────┐
│ DB Migration │ │ Route Handlers│
│ (users table) │ │ (auth routes) │
└────────┬───────┘ └────────┬───────┘
│ │
└────────┬──────────┘
│
▼
┌────────────────┐
│ Auth │
│ Middleware │
└────────┬───────┘
│
┌────────┴────────┐
│ │
▼ ▼
┌────────────────┐ ┌────────────────┐
│ Integration │ │ Update │
│ Tests │ │ Frontend │
└────────────────┘ └────────────────┘在這個圖中：
- DB Migration 和 Route Handlers 是獨立的 — 它們可以平行執行
- Auth Middleware 依賴兩者 — 兩者都完成後才能開始
- Integration Tests 和 Update Frontend 依賴 Auth Middleware 但彼此不依賴
依賴邊
每個任務攜帶兩個關係欄位：
Task: "Auth Middleware"
status: pending
blockedBy: ["DB Migration", "Route Handlers"]
blocks: ["Integration Tests", "Update Frontend"]這些邊編碼了完整的圖：
| 欄位 | 意義 |
|---|---|
blockedBy | 在此任務開始前必須完成的任務 |
blocks | 在此任務完成前無法開始的任務 |
blockedBy / blocks 關係是對稱的 — 如果任務 A 阻塞任務 B，那麼任務 B 被任務 A 阻塞。
圖遍歷演算法
Claude Code 使用一個簡單但有效的演算法來遍歷任務圖：
REPEAT:
1. Scan all tasks
2. Find tasks where:
- status = "pending"
- ALL blockedBy tasks have status = "completed"
3. These are "ready" tasks -- execute them
(If multiple tasks are ready, run in parallel)
4. Mark completed tasks
5. Check: did completing these unlock new tasks?
6. If no tasks remain, DONE以下是該演算法在時間軸上的視覺化：
Time ──────────────────────────────────────────────►
Round 1: [Analyze Requirements]
status: pending → in_progress → completed
Round 2: [DB Migration]────────┐ (parallel)
[Route Handlers]──────┘
Round 3: [Auth Middleware]
(unlocked because both blockers completed)
Round 4: [Integration Tests]───┐ (parallel)
[Update Frontend]─────┘
DONE ✓四個回合取代六個循序步驟。圖揭示了兩個回合可以平行執行任務，縮短總執行時間。
AI 如何建構圖
當你要求 Claude Code 實現一個複雜功能時，它會分析子任務之間的自然依賴關係。規劃階段看起來像這樣：
User: "Add authentication to the Express app"
AI internal reasoning:
"I need to break this down. Let me think about what
depends on what..."
1. Analyze requirements → nothing depends on, everything starts here
2. DB migration (users table) → needs requirements analysis
3. Route handlers (login/signup) → needs requirements analysis
4. Auth middleware (JWT validation) → needs both DB and routes
5. Tests → needs middleware
6. Frontend login page → needs middleware
TodoWrite output:
Task 1: Analyze requirements blockedBy: []
Task 2: Create users table migration blockedBy: [1]
Task 3: Create auth route handlers blockedBy: [1]
Task 4: Implement auth middleware blockedBy: [2, 3]
Task 5: Write integration tests blockedBy: [4]
Task 6: Update frontend with login blockedBy: [4]關鍵在於任務 2 和 3 共享同一個阻塞者（任務 1），但彼此不會阻塞。AI 認識到它們是獨立的，可以同時執行。
使用子代理平行執行
當多個任務同時就緒時，Claude Code 可以將它們委派給平行的子代理：
Round 2 — Two tasks ready:
Parent Agent
│
├──► Subagent A: "Create users table migration"
│ └── Works in isolated context
│
└──► Subagent B: "Create auth route handlers"
└── Works in isolated context
Both return results → Parent continues to Round 3這結合了課程中的兩個概念：任務圖識別可平行化的工作，而子代理（第 4 堂課）提供隔離的上下文來執行它們。
關鍵洞見
任務圖讓 AI 通過識別可平行化的子任務，在每一輪中完成更多工作。 沒有圖的話，AI 按線性序列逐一處理任務。有了圖，它可以批次處理獨立任務並同時執行。
但更深層的洞見是關於正確性，而不僅僅是速度。扁平任務清單無法表達「在那個完成之前不要開始這個」。依賴圖使排序約束明確化，防止 AI 對尚不存在的程式碼撰寫測試，或在依賴項目尚未就緒時整合中介層。
把它想像成建構系統。make 不會隨機編譯檔案 — 它讀取依賴圖，先建構葉節點，然後向上推進。Claude Code 的任務圖以相同方式運作。就像 make -j4 可以平行化獨立的編譯單元一樣，Claude Code 也可以平行化獨立的任務。
實作範例
組織提示詞以產生良好的依賴圖
你可以通過在提示詞中明確描述關係來引導 Claude Code 產生結構良好的任務圖：
Add a notification system to the app. Break it into tasks
with clear dependencies:
Phase 1 (no dependencies):
- Design the notification data model
- Research WebSocket libraries
Phase 2 (depends on Phase 1):
- Create notifications table migration
- Set up WebSocket server
Phase 3 (depends on Phase 2):
- Build notification API endpoints
- Implement real-time push via WebSocket
Phase 4 (depends on Phase 3):
- Create frontend notification component
- Write end-to-end tests
Use TodoWrite with blockedBy edges. Run parallel tasks
where possible.識別依賴模式
你會遇到的常見依賴模式：
Linear Chain: Fan-Out: Fan-In:
A → B → C A → B D ←─ A
A → C D ←─ B
A → D D ←─ C
Diamond: Independent:
A A B C
/ \ (no edges)
B C
\ /
D菱形模式是實際專案中最常見的。一個分析任務扇出到平行的實作任務，然後匯聚到一個整合任務。
處理圖中的失敗
當任務失敗時，其下游依賴項會被阻塞：
Before failure:
✓ Analyze requirements
→ DB Migration (in progress)
→ Route Handlers (in progress)
□ Auth Middleware (blocked by 2, 3)
DB Migration fails:
✓ Analyze requirements
✗ DB Migration (FAILED)
✓ Route Handlers
⊘ Auth Middleware (BLOCKED — dependency failed)
Recovery:
The AI diagnoses the failure, fixes the migration,
re-runs it, and then Auth Middleware becomes unblocked.圖使失敗的影響範圍可見。沒有圖的話，AI 可能會嘗試繼續執行 Auth Middleware，然後因為資料庫表不存在而遇到難以理解的錯誤。
一眼讀懂圖
在執行過程中，任務清單成為即時儀表板：
Task Graph Status:
✓ [1] Analyze requirements
✓ [2] Create users table migration
✓ [3] Create auth route handlers
→ [4] Implement auth middleware (blockedBy: 2✓, 3✓)
□ [5] Write integration tests (blockedBy: 4)
□ [6] Update frontend with login (blockedBy: 4)
Progress: 3/6 tasks completed | 1 in progress | 2 blocked
Next parallel batch: [5, 6] when [4] completes前後對比
| 扁平任務清單 | 帶依賴關係的任務圖 |
|---|---|
| 只能循序執行 | 獨立任務平行執行 |
| 沒有排序保證 | 明確的依賴邊防止錯誤順序 |
| 失敗阻塞所有任務 | 失敗只阻塞下游依賴項 |
| 沒有超出當前任務的進度可見性 | 完整圖顯示已完成、執行中和等待中的任務 |
| AI 必須在上下文中記住排序 | 依賴關係編碼在資料中，在壓縮後仍然存在 |
| 一次處理一個任務 | 多個子代理處理獨立任務 |
下一堂課
第 8 堂課涵蓋背景任務 — Claude Code 如何在背景啟動長時間執行的操作（建構、測試套件、部署），並在等待結果的同時繼續進行有效的工作。