前言:AI 協作開發的範式演進
在 AI 輔助開發工具快速演進的今天,我們已經從「程式碼自動補全」進化到「AI 主動協作」的階段。Claude Code 作為 Anthropic 推出的革命性開發工具,引入了兩種截然不同但互補的協作模式:Subagent-Driven Development 和 Parallel Session。
這兩種模式不只是技術上的差異,更代表了兩種不同的開發哲學:
- Subagent-Driven:像是 pair programming,強調即時互動和快速迭代
- Parallel Session:像是 CI/CD pipeline,強調自動化執行和長期任務管理
在實際使用這兩種模式數週後,我深刻體會到它們各自的優勢與適用場景。這篇文章將系統性地分享我的實戰經驗,幫助你理解何時使用哪種模式,以及如何最大化開發效率。
核心概念:理解兩種開發模式
Subagent-Driven Development:即時協作的藝術
Subagent-Driven 的核心理念是在單一 session 內動態生成多個子代理(subagent),每個 subagent 負責特定的任務,並在完成後立即提供回饋。
技術架構:
graph TD
A[開發者下達任務] --> B[主系統分析任務]
B --> C{任務複雜度}
C -->|簡單任務| D[單一 Subagent 處理]
C -->|複雜任務| E[生成多個 Subagent]
D --> F[Subagent 1: 撰寫程式碼]
E --> F
E --> G[Subagent 2: Code Review]
E --> H[Subagent 3: 測試驗證]
F --> I[即時回饋]
G --> I
H --> I
I --> J{需要調整?}
J -->|是| K[動態調整並重新執行]
J -->|否| L[任務完成]
K --> F
style B fill:#114762ff
style I fill:#ff69b4
style L fill:#0a5317ff
Subagent 的角色與職責:
每個 subagent 就像一個專業的工程助理,具備特定的能力:
| Subagent 類型 | 職責 | 輸出成果 |
|---|---|---|
| Code Writer | 撰寫完整的功能程式碼 | 可執行的程式碼檔案 |
| Component Builder | 建立元件骨架和結構 | 元件檔案與介面定義 |
| Logic Implementer | 實作互動邏輯與狀態管理 | 狀態機、事件處理器 |
| Code Reviewer | 自動進行程式碼審查 | 審查報告、改進建議 |
| Test Validator | 執行測試並驗證輸出 | 測試結果、覆蓋率報告 |
核心特性:
- 即時回饋循環:每個 subagent 完成任務後立即提供結果,開發者可以馬上調整方向
- 共享上下文:所有 subagent 在同一 session 內,共享相同的專案上下文和對話歷史
- 快速迭代:適合需要頻繁調整的任務,如 UI 調整、API 整合、演算法優化
- 低延遲溝通:開發者和 AI 之間的溝通成本極低,可以隨時打斷、調整
實際工作流程範例:
// 開發者指令:「建立一個熱力圖元件,使用 D3.js 繪製」
// Subagent 1: Component Builder
// 輸出:元件骨架
const HeatmapComponent = {
props: ['data', 'width', 'height'],
setup(props) {
// 基本結構
}
}
// Subagent 2: Logic Implementer
// 輸出:D3.js 繪圖邏輯
import * as d3 from 'd3'
const drawHeatmap = (data, width, height) => {
const svg = d3.select('#heatmap')
.attr('width', width)
.attr('height', height)
// 色階設定
const colorScale = d3.scaleSequential(d3.interpolateYlOrRd)
.domain([0, d3.max(data, d => d.value)])
// 繪製矩形
svg.selectAll('rect')
.data(data)
.enter()
.append('rect')
.attr('x', d => d.x)
.attr('y', d => d.y)
.attr('width', 20)
.attr('height', 20)
.attr('fill', d => colorScale(d.value))
}
// Subagent 3: Code Reviewer
// 輸出:審查建議
/*
建議改進:
1. 色階應該使用 props 傳入,提高可重用性
2. 缺少 tooltip 互動功能
3. 需要處理資料為空的情況
*/
// Subagent 4: Test Validator
// 輸出:測試結果
describe('HeatmapComponent', () => {
it('should render correct number of cells', () => {
const data = [{x: 0, y: 0, value: 5}]
const result = mount(HeatmapComponent, { props: { data } })
expect(result.findAll('rect').length).toBe(1)
})
})
// ✅ All tests passed
適用場景:
✅ 高度適合:
- 互動式 UI 開發(需要視覺調整)
- API 整合與調試(需要即時測試)
- 演算法優化(需要快速驗證效能)
- 原型開發(需要快速嘗試不同方向)
- Bug 修復(需要即時驗證修復效果)
❌ 不適合:
- 長時間執行的任務(如資料庫遷移)
- 可完全自動化的批次任務
- 不需要人工監督的重複性工作
- 需要背景執行的任務(會佔用 session)
Parallel Session:自動化執行的力量
Parallel Session 代表了完全不同的協作模式:建立多條獨立的平行開發支線,每條支線自主執行任務,不需要持續的人工監督。
技術架構:
graph LR
A[開發計畫] --> B[任務拆分]
B --> C[Session 1: 前端開發]
B --> D[Session 2: 後端 API]
B --> E[Session 3: 資料庫遷移]
B --> F[Session 4: 測試撰寫]
C --> C1[建立元件]
C --> C2[實作路由]
C --> C3[狀態管理]
D --> D1[設計 API]
D --> D2[實作端點]
D --> D3[驗證邏輯]
E --> E1[Schema 設計]
E --> E2[遷移腳本]
E --> E3[資料驗證]
F --> F1[單元測試]
F --> F2[整合測試]
F --> F3[E2E 測試]
C1 --> G[Checkpoint 1]
C2 --> H[Checkpoint 2]
C3 --> I[Checkpoint 3]
D1 --> G
D2 --> H
D3 --> I
E1 --> G
E2 --> H
E3 --> I
F1 --> G
F2 --> H
F3 --> I
I --> J[整合驗證]
J --> K[部署]
style A fill:#114762ff
style G fill:#3c1010ff
style H fill:#3c1010ff
style I fill:#3c1010ff
style K fill:#0a5317ff
實作技術:Git Worktree + Superpowers
Parallel Session 的實作依賴於兩個關鍵技術:
- Git Worktree:允許同一個 repository 有多個工作目錄
- Superpowers Skill:提供自動化執行框架
實際設定範例:
# 1. 建立主要開發分支
git checkout -b feature/user-dashboard
# 2. 為不同任務建立 worktree
git worktree add ../user-dashboard-frontend feature/frontend
git worktree add ../user-dashboard-backend feature/backend
git worktree add ../user-dashboard-tests feature/tests
# 3. 查看所有 worktree
git worktree list
# /Users/dev/project abc1234 [feature/user-dashboard]
# /Users/dev/user-dashboard-frontend def5678 [feature/frontend]
# /Users/dev/user-dashboard-backend ghi9012 [feature/backend]
# /Users/dev/user-dashboard-tests jkl3456 [feature/tests]
# 4. 使用 Superpowers 執行計畫
# 在每個 worktree 中啟動獨立的 Claude Code session
# Session 1 (frontend): 專注於 React 元件開發
# Session 2 (backend): 專注於 Express API 開發
# Session 3 (tests): 專注於 Cypress E2E 測試
Superpowers 整合:執行計畫範例
使用 superpowers:executing-plans skill 來管理 Parallel Session:
# implementation-plan.md
## 前端開發 (Session 1)
### Task 1.1: 建立 Dashboard 佈局
- 檔案: `src/components/Dashboard.tsx`
- 需求: 響應式網格佈局,支援 2x2 卡片
- 驗證: 在 1920x1080 和 375x667 解析度下測試
### Task 1.2: 實作使用者統計卡片
- 檔案: `src/components/UserStatsCard.tsx`
- 需求: 顯示總使用者數、活躍使用者、新註冊數
- API: `GET /api/stats/users`
- 驗證: Mock API 回應測試
### Task 1.3: 建立圖表元件
- 檔案: `src/components/UsageChart.tsx`
- 需求: 使用 Chart.js 繪製過去 7 天使用量
- 驗證: 測試資料更新動畫
---
## 後端開發 (Session 2)
### Task 2.1: 設計資料庫 Schema
- 檔案: `prisma/schema.prisma`
- 需求: User, Session, Activity 三個 model
- 驗證: `prisma generate` 無錯誤
### Task 2.2: 實作統計 API
- 檔案: `src/api/stats.ts`
- 端點: `GET /api/stats/users`
- 回應格式: `{ total: number, active: number, new: number }`
- 驗證: Postman 測試所有情境
### Task 2.3: 實作使用量查詢
- 檔案: `src/api/usage.ts`
- 端點: `GET /api/usage?days=7`
- 需求: 聚合過去 N 天的 activity 資料
- 驗證: 測試邊界條件(0 天、365 天)
---
## 測試開發 (Session 3)
### Task 3.1: Dashboard E2E 測試
- 檔案: `cypress/e2e/dashboard.cy.ts`
- 測試: 頁面載入、卡片顯示、圖表渲染
- 驗證: CI 環境通過測試
### Task 3.2: API 整合測試
- 檔案: `tests/integration/stats.test.ts`
- 測試: API 回應格式、錯誤處理、效能
- 驗證: 所有測試覆蓋率 > 80%
### Task 3.3: 效能測試
- 檔案: `tests/performance/load.test.ts`
- 測試: 1000 併發請求,p95 延遲 < 200ms
- 驗證: Artillery 報告通過
使用 Claude Code 執行計畫:
# 在 Claude Code 中使用 slash command
/superpowers:execute-plan implementation-plan.md
# 系統會:
# 1. 解析計畫檔案
# 2. 批次 1: 執行 Task 1.1, 2.1, 3.1 (獨立任務)
# 3. 報告進度並等待審查
# 4. 批次 2: 執行 Task 1.2, 2.2, 3.2 (依賴批次 1)
# 5. 報告進度並等待審查
# 6. 批次 3: 執行 Task 1.3, 2.3, 3.3 (依賴批次 2)
# 7. 最終整合驗證
Checkpoint 機制:
Parallel Session 的關鍵優勢是可恢復性。每個任務完成後都會建立 checkpoint:
# .antigravity/checkpoints/task-1-1.yml
task_id: "1.1"
status: "completed"
timestamp: "2025-11-30T10:30:00Z"
files_modified:
- "src/components/Dashboard.tsx"
- "src/components/Dashboard.test.tsx"
git_commit: "abc1234"
verification:
- type: "test"
command: "npm test Dashboard"
result: "passed"
- type: "visual"
screenshot: ".antigravity/screenshots/dashboard-1920x1080.png"
status: "approved"
如果系統崩潰或需要中斷,可以從最近的 checkpoint 恢復:
# 恢復執行
/superpowers:execute-plan implementation-plan.md --resume-from task-1-2
# 系統會:
# 1. 載入 task-1-1 的 checkpoint
# 2. 跳過已完成的任務
# 3. 從 task-1-2 繼續執行
適用場景:
✅ 高度適合:
- 大型重構專案(多個模組同時修改)
- 長期執行任務(資料庫遷移、大量測試)
- 多人協作專案(不同開發者負責不同 session)
- 可完全自動化的任務(不需要即時回饋)
- 跨領域整合(前端、後端、DevOps 並行)
❌ 不適合:
- 需要頻繁調整方向的任務
- 高度依賴視覺回饋的 UI 開發
- 探索性開發(方向不明確)
- 簡單快速的 bug 修復
深入對比:兩種模式的技術差異
工作流程對比
graph TB
subgraph "Subagent-Driven 工作流程"
A1[開發者] -->|下達任務| B1[主系統]
B1 -->|生成| C1[Subagent 1]
B1 -->|生成| D1[Subagent 2]
B1 -->|生成| E1[Subagent 3]
C1 -->|即時回饋| A1
D1 -->|即時回饋| A1
E1 -->|即時回饋| A1
A1 -->|調整指令| B1
style A1 fill:#114762ff
style C1 fill:#ff69b4
style D1 fill:#ff69b4
style E1 fill:#ff69b4
end
subgraph "Parallel Session 工作流程"
A2[開發計畫] -->|拆分任務| B2[任務佇列]
B2 -->|分配| C2[Session 1]
B2 -->|分配| D2[Session 2]
B2 -->|分配| E2[Session 3]
C2 -->|自動執行| F2[Checkpoint 1]
D2 -->|自動執行| F2
E2 -->|自動執行| F2
F2 -->|繼續| G2[Checkpoint 2]
G2 -->|完成| H2[整合驗證]
H2 -->|通知| A3[開發者審查]
style A2 fill:#114762ff
style F2 fill:#3c1010ff
style G2 fill:#3c1010ff
style H2 fill:#0a5317ff
end
技術特性比較表
| 面向 | Subagent-Driven | Parallel Session |
|---|---|---|
| 執行模式 | 同步、即時互動 | 非同步、批次執行 |
| 上下文共享 | 單一 session,完全共享 | 多個 session,獨立上下文 |
| 回饋延遲 | 秒級(< 5 秒) | 分鐘級(批次完成後) |
| 可中斷性 | 高(隨時調整) | 低(需等待 checkpoint) |
| 可恢復性 | 低(session 關閉後遺失) | 高(checkpoint 機制) |
| 並行能力 | 有限(單一 session 內) | 強大(多 session 並行) |
| 適合任務數 | 1-5 個小任務 | 10-100 個大任務 |
| 人工監督 | 持續監督 | 階段性審查 |
| Git 整合 | 手動 commit | 自動 commit per task |
| 測試驗證 | 手動觸發 | 自動執行 |
| 資源佔用 | 佔用主 session | 背景執行 |
| 學習曲線 | 低(直覺操作) | 中(需理解計畫格式) |
| 錯誤恢復 | 手動重試 | 自動重試(可設定) |
| 成本效益 | 高(快速任務) | 高(長期任務) |
決策流程圖:如何選擇模式?
graph TD
A[開始新任務] --> B{任務能否明確定義?}
B -->|否,需要探索| C[使用 Subagent-Driven]
B -->|是,需求清晰| D{任務是否可拆分為獨立子任務?}
D -->|否,高度耦合| C
D -->|是,可獨立執行| E{需要即時視覺回饋?}
E -->|是,UI/互動式| C
E -->|否,邏輯為主| F{任務執行時間?}
F -->|< 30 分鐘| C
F -->|> 30 分鐘| G[使用 Parallel Session]
C --> H[單一 session 快速迭代]
G --> I[多 session 自動執行]
H --> J{任務完成後需要大規模重構?}
J -->|是| K[切換到 Parallel Session]
J -->|否| L[完成]
I --> M{中途需要調整方向?}
M -->|是| N[暫停並切換到 Subagent-Driven]
M -->|否| L
K --> I
N --> H
style C fill:#ff69b4
style G fill:#0a5317ff
style L fill:#114762ff
實戰案例:真實世界的應用
案例 1:使用 Subagent-Driven 開發互動式熱力圖
背景: 需要為資料分析儀表板開發一個互動式熱力圖元件,要求支援縮放、tooltip、色階調整等功能。
為什麼選擇 Subagent-Driven?
- 高度視覺化的任務,需要即時查看效果
- 色階、佈局需要多次調整
- 互動邏輯需要快速驗證
實際執行過程:
步驟 1:初始元件骨架
// 開發者指令:「建立一個 Vue 3 熱力圖元件,使用 D3.js」
// Subagent 1 輸出:基本結構
<template>
<div ref="container" class="heatmap-container"></div>
</template>
<script setup>
import { ref, onMounted, watch } from 'vue'
import * as d3 from 'd3'
const props = defineProps({
data: {
type: Array,
required: true
},
width: {
type: Number,
default: 800
},
height: {
type: Number,
default: 600
}
})
const container = ref(null)
onMounted(() => {
initHeatmap()
})
const initHeatmap = () => {
// TODO: D3.js 繪圖邏輯
}
</script>
步驟 2:D3.js 繪圖邏輯
// 開發者指令:「實作 D3.js 繪圖,使用 YlOrRd 色階」
// Subagent 2 輸出:完整繪圖邏輯
const initHeatmap = () => {
const svg = d3.select(container.value)
.append('svg')
.attr('width', props.width)
.attr('height', props.height)
// 計算格子尺寸
const rows = [...new Set(props.data.map(d => d.row))].length
const cols = [...new Set(props.data.map(d => d.col))].length
const cellWidth = props.width / cols
const cellHeight = props.height / rows
// 色階設定
const colorScale = d3.scaleSequential(d3.interpolateYlOrRd)
.domain([0, d3.max(props.data, d => d.value)])
// 繪製熱力圖格子
svg.selectAll('rect')
.data(props.data)
.enter()
.append('rect')
.attr('x', d => d.col * cellWidth)
.attr('y', d => d.row * cellHeight)
.attr('width', cellWidth)
.attr('height', cellHeight)
.attr('fill', d => colorScale(d.value))
.attr('stroke', '#fff')
.attr('stroke-width', 1)
}
步驟 3:即時調整色階
// 開發者:「色彩太淺了,能否調整為更鮮豔的色階?」
// Subagent 3 即時調整:
const colorScale = d3.scaleSequential()
.interpolator(d3.interpolateRgbBasis(['#fee5d9', '#fcae91', '#fb6a4a', '#de2d26', '#a50f15']))
.domain([0, d3.max(props.data, d => d.value)])
// 立即看到效果,滿意後繼續下一步
步驟 4:新增 Tooltip 互動
// 開發者:「滑鼠移到格子上時顯示數值」
// Subagent 4 輸出:Tooltip 邏輯
const tooltip = d3.select('body')
.append('div')
.attr('class', 'heatmap-tooltip')
.style('position', 'absolute')
.style('visibility', 'hidden')
.style('background', '#fff')
.style('padding', '8px')
.style('border', '1px solid #ddd')
.style('border-radius', '4px')
.style('font-size', '12px')
svg.selectAll('rect')
// ... 前面的屬性 ...
.on('mouseover', function(event, d) {
tooltip
.style('visibility', 'visible')
.html(`
<strong>Row ${d.row}, Col ${d.col}</strong><br/>
Value: ${d.value.toFixed(2)}
`)
d3.select(this)
.attr('stroke', '#000')
.attr('stroke-width', 2)
})
.on('mousemove', function(event) {
tooltip
.style('top', (event.pageY - 10) + 'px')
.style('left', (event.pageX + 10) + 'px')
})
.on('mouseout', function() {
tooltip.style('visibility', 'hidden')
d3.select(this)
.attr('stroke', '#fff')
.attr('stroke-width', 1)
})
步驟 5:Code Review 與優化
// Subagent 5: Code Reviewer 自動執行
// 輸出審查報告:
/*
✅ 程式碼品質評估:
優點:
1. 使用 Vue 3 Composition API,符合現代最佳實踐
2. D3.js 色階設定正確
3. Tooltip 互動流暢
建議改進:
1. 【效能】color scale 應該快取,避免每次 render 重新計算
2. 【可維護性】繪圖邏輯應拆分為獨立函式
3. 【響應式】缺少視窗 resize 處理
4. 【可訪問性】缺少 ARIA 標籤
5. 【類型安全】建議加入 TypeScript 類型定義
優先級排序:
🔴 高優先級:#1 效能優化、#3 響應式處理
🟡 中優先級:#2 程式碼重構
🟢 低優先級:#4 可訪問性、#5 TypeScript
*/
步驟 6:快速迭代修復
// 開發者:「先處理效能和響應式問題」
// Subagent 6 快速修復:
// 1. 快取 color scale
const colorScale = computed(() => {
return d3.scaleSequential()
.interpolator(d3.interpolateRgbBasis([...colors]))
.domain([0, d3.max(props.data, d => d.value)])
})
// 2. 響應式處理
const handleResize = () => {
d3.select(container.value).select('svg').remove()
initHeatmap()
}
onMounted(() => {
initHeatmap()
window.addEventListener('resize', debounce(handleResize, 300))
})
onBeforeUnmount(() => {
window.removeEventListener('resize', handleResize)
})
// 3. Debounce 工具函式
const debounce = (fn, delay) => {
let timeoutId
return (...args) => {
clearTimeout(timeoutId)
timeoutId = setTimeout(() => fn(...args), delay)
}
}
最終成果:
整個開發過程耗時約 45 分鐘,包含 6 輪快速迭代:
- 初始骨架(5 分鐘)
- D3.js 繪圖(10 分鐘)
- 色階調整(3 分鐘)
- Tooltip 互動(8 分鐘)
- Code Review(自動,2 分鐘)
- 效能與響應式優化(15 分鐘)
- 最終測試(2 分鐘)
如果使用 Parallel Session,可能需要:
- 預先撰寫詳細的實作計畫(30 分鐘)
- 等待自動執行完成(15 分鐘)
- 發現色階不滿意,修改計畫(10 分鐘)
- 重新執行(15 分鐘)
- 總計:70+ 分鐘
結論: 對於視覺化、互動式的開發任務,Subagent-Driven 的即時回饋大幅提高效率。
案例 2:使用 Parallel Session 執行大規模 API 重構
背景: 需要將舊版 REST API 遷移到 GraphQL,涉及 50+ 個端點、資料庫 schema 調整、前端查詢改寫。
為什麼選擇 Parallel Session?
- 任務量龐大(預估 20+ 小時工作量)
- 可明確拆分為獨立子任務
- 不需要即時視覺回饋
- 可以背景執行,不佔用主 session
實作計畫結構:
# graphql-migration-plan.md
## Phase 1: GraphQL Schema 設計 (Session 1)
### Task 1.1: 設計核心 Types
**檔案:** `schema/types/user.graphql`
**需求:**
- User, Profile, Settings 類型定義
- 欄位對應到現有 Prisma schema
- 加入必要的 nullable 設定
**驗證:**
```bash
npm run graphql:validate
Task 1.2: 設計查詢 Queries
檔案: schema/queries/user.graphql
需求:
- getUser(id: ID!): User
- listUsers(limit: Int, offset: Int): [User!]!
- searchUsers(query: String!): [User!]!
驗證:
- Schema 編譯無錯誤
- 與前端需求文件比對
Task 1.3: 設計變更 Mutations
檔案: schema/mutations/user.graphql
需求:
- createUser(input: CreateUserInput!): User!
- updateUser(id: ID!, input: UpdateUserInput!): User!
- deleteUser(id: ID!): Boolean!
驗證:
- Input types 正確定義
- Error handling 規範
Phase 2: Resolver 實作 (Session 2)
Task 2.1: User Query Resolvers
檔案: src/resolvers/user.queries.ts
需求:
export const userQueries = {
getUser: async (_parent, { id }, { prisma }) => {
return prisma.user.findUnique({ where: { id } })
},
listUsers: async (_parent, { limit = 10, offset = 0 }, { prisma }) => {
return prisma.user.findMany({
take: limit,
skip: offset,
orderBy: { createdAt: 'desc' }
})
},
searchUsers: async (_parent, { query }, { prisma }) => {
return prisma.user.findMany({
where: {
OR: [
{ name: { contains: query, mode: 'insensitive' } },
{ email: { contains: query, mode: 'insensitive' } }
]
}
})
}
}
驗證:
npm test src/resolvers/user.queries.test.ts
Task 2.2: User Mutation Resolvers
檔案: src/resolvers/user.mutations.ts
需求:
- 實作所有 CRUD mutations
- 加入輸入驗證(使用 Zod)
- 處理錯誤情境(重複 email、無效 ID)
驗證:
- 所有測試通過
- 錯誤訊息清晰易懂
Task 2.3: Field Resolvers (關聯資料)
檔案: src/resolvers/user.fields.ts
需求:
export const userFieldResolvers = {
User: {
posts: async (parent, _args, { prisma }) => {
return prisma.post.findMany({
where: { authorId: parent.id }
})
},
profile: async (parent, _args, { prisma }) => {
return prisma.profile.findUnique({
where: { userId: parent.id }
})
}
}
}
驗證:
- N+1 查詢問題測試(使用 DataLoader)
- 效能測試(100 users 查詢 < 500ms)
Phase 3: REST to GraphQL 橋接層 (Session 3)
Task 3.1: 建立 REST 相容層
檔案: src/compat/rest-adapter.ts
需求:
- 將舊版 REST 端點轉換為 GraphQL 查詢
- 維持相同的 response 格式(向後相容)
- 加入 deprecation warnings
範例:
// 舊版: GET /api/users/:id
// 新版: 內部轉換為 GraphQL query
app.get('/api/users/:id', async (req, res) => {
const query = `
query GetUser($id: ID!) {
getUser(id: $id) {
id
name
email
createdAt
}
}
`
const result = await executeGraphQL(query, { id: req.params.id })
res.set('X-API-Deprecated', 'true')
res.set('X-Migration-Deadline', '2026-03-01')
res.json(result.data.getUser)
})
驗證:
- 所有現有整合測試仍通過
- Deprecation headers 正確設定
Phase 4: 前端查詢遷移 (Session 4)
Task 4.1: 建立 GraphQL Client
檔案: src/api/graphql-client.ts
需求:
- 使用 Apollo Client
- 設定快取策略
- 錯誤處理與重試邏輯
驗證:
npm test src/api/graphql-client.test.ts
Task 4.2: 遷移 User 相關查詢
檔案: src/hooks/useUser.ts
Before (REST):
const useUser = (id: string) => {
return useSWR(`/api/users/${id}`, fetcher)
}
After (GraphQL):
const GET_USER = gql`
query GetUser($id: ID!) {
getUser(id: $id) {
id
name
email
profile {
avatar
bio
}
posts {
id
title
}
}
}
`
const useUser = (id: string) => {
return useQuery(GET_USER, { variables: { id } })
}
驗證:
- 元件測試通過
- 無 console 錯誤
Task 4.3: 遷移 Mutation 操作
檔案: src/hooks/useUserMutations.ts
需求:
- createUser, updateUser, deleteUser mutations
- 樂觀更新(Optimistic UI)
- 快取自動更新
驗證:
- E2E 測試:建立 → 編輯 → 刪除流程
Phase 5: 整合測試與部署 (Session 5)
Task 5.1: E2E 測試
檔案: tests/e2e/graphql-migration.spec.ts
測試情境:
- REST API 仍可正常運作(向後相容)
- GraphQL API 功能完整
- 前端使用 GraphQL 無錯誤
- 效能無退化(回應時間對比)
驗證:
npm run test:e2e
Task 5.2: 效能測試
檔案: tests/performance/graphql-load.test.ts
需求:
- 1000 併發 GraphQL 查詢
- p95 延遲 < 200ms
- 記憶體使用穩定
驗證:
artillery run tests/performance/graphql-load.yml
Task 5.3: 文件更新
檔案: docs/api/graphql.md
需求:
- 完整的 Schema 文件
- 查詢範例
- 遷移指南
- Deprecation timeline
驗證:
- 文件審查通過
**執行 Parallel Session:**
```bash
# 在 Claude Code 中執行
/superpowers:execute-plan graphql-migration-plan.md
# 系統輸出:
# ✅ 計畫已解析:5 個 Phase,18 個 Tasks
# 🚀 開始批次執行...
#
# 批次 1 (並行執行 Task 1.1, 1.2, 1.3):
# - Session 1a: 設計核心 Types... ⏳
# - Session 1b: 設計查詢 Queries... ⏳
# - Session 1c: 設計變更 Mutations... ⏳
#
# [10 分鐘後]
# ✅ 批次 1 完成 (3/3 tasks)
# 📊 Checkpoint 已建立
#
# 等待審查... [開發者審查 schema 定義]
#
# 👍 審查通過,繼續批次 2
#
# 批次 2 (並行執行 Task 2.1, 2.2, 2.3):
# - Session 2a: User Query Resolvers... ⏳
# - Session 2b: User Mutation Resolvers... ⏳
# - Session 2c: Field Resolvers... ⏳
#
# [20 分鐘後]
# ✅ 批次 2 完成 (3/3 tasks)
# ⚠️ 發現問題:Task 2.3 N+1 查詢問題
# 🔄 自動重試中...
# ✅ 問題已修復(使用 DataLoader)
# 📊 Checkpoint 已建立
#
# ... [繼續執行剩餘批次] ...
#
# 🎉 所有任務完成!
# 📈 統計:
# - 總任務數:18
# - 成功:18
# - 失敗後重試:1
# - 總執行時間:3.5 小時
# - 檔案修改:67
# - Git commits:18
# - 測試覆蓋率:87%
最終成果比較:
| 面向 | Parallel Session | 傳統手動開發 | Subagent-Driven |
|---|---|---|---|
| 總時間 | 3.5 小時(自動) | 20+ 小時 | 8+ 小時(需持續監督) |
| 人工時間 | 30 分鐘(審查) | 20+ 小時 | 8+ 小時 |
| 錯誤率 | 低(自動測試) | 中(人為疏失) | 低(即時修正) |
| 可追蹤性 | 高(checkpoint) | 中(手動 commit) | 低(單一 session) |
| 可恢復性 | 高 | 低 | 低 |
結論: 對於大規模、可明確定義的重構任務,Parallel Session 提供了10 倍效率提升,同時維持高品質和可追蹤性。
案例 3:混合模式 - 最佳實踐
場景: 開發一個電商網站,包含產品目錄、購物車、結帳流程。
策略: 使用混合模式,根據任務特性選擇不同模式。
graph TB
A[電商專案啟動] --> B[需求分析與架構設計]
B --> C[Phase 1: 基礎架構]
C -->|Parallel Session| C1[資料庫 Schema 設計]
C -->|Parallel Session| C2[API 架構建置]
C -->|Parallel Session| C3[認證系統實作]
C1 --> D[Phase 2: 產品目錄]
C2 --> D
C3 --> D
D -->|Subagent-Driven| D1[產品列表 UI 開發<br/>需要視覺調整]
D -->|Parallel Session| D2[產品搜尋 API<br/>可自動執行]
D -->|Subagent-Driven| D3[篩選器元件<br/>互動式開發]
D1 --> E[Phase 3: 購物車]
D2 --> E
D3 --> E
E -->|Subagent-Driven| E1[購物車 UI<br/>拖放互動]
E -->|Parallel Session| E2[庫存管理邏輯<br/>複雜規則]
E -->|Subagent-Driven| E3[價格計算顯示<br/>即時回饋]
E1 --> F[Phase 4: 結帳流程]
E2 --> F
E3 --> F
F -->|Subagent-Driven| F1[多步驟表單<br/>UX 調整]
F -->|Parallel Session| F2[付款整合<br/>Stripe API]
F -->|Parallel Session| F3[訂單處理邏輯<br/>狀態機]
F1 --> G[Phase 5: 測試與優化]
F2 --> G
F3 --> G
G -->|Parallel Session| G1[E2E 測試套件<br/>自動化測試]
G -->|Subagent-Driven| G2[效能優化<br/>需要監控調整]
G -->|Parallel Session| G3[文件撰寫<br/>可自動生成]
G1 --> H[上線部署]
G2 --> H
G3 --> H
style C fill:#0a5317ff
style D fill:#ff69b4
style E fill:#114762ff
style F fill:#ff69b4
style G fill:#0a5317ff
詳細執行策略:
Phase 1: 基礎架構(100% Parallel Session)
理由:基礎架構任務明確、可獨立執行,不需要視覺回饋。
# Session 1: 資料庫 Schema
prisma/schema.prisma
model Product {
id String @id @default(cuid())
name String
price Decimal
stock Int
category Category @relation(fields: [categoryId], references: [id])
categoryId String
}
# Session 2: API 架構
src/api/routes/products.ts
src/api/routes/cart.ts
src/api/routes/orders.ts
# Session 3: 認證系統
src/auth/jwt.ts
src/auth/middleware.ts
src/auth/providers/ (Google, Email)
# 執行時間:2 小時(自動),人工時間:15 分鐘(審查)
Phase 2: 產品目錄(60% Subagent, 40% Parallel)
// Task 2.1: 產品列表 UI (Subagent-Driven)
// 理由:需要視覺調整,色彩、間距、響應式佈局
// 開發者與 subagent 互動:
// 「建立產品列表,使用 grid 佈局」
// → 查看效果
// 「卡片間距太小,改為 24px」
// → 即時調整
// 「加入 hover 效果,放大 1.05 倍」
// → 立即驗證
<template>
<div class="product-grid">
<ProductCard
v-for="product in products"
:key="product.id"
:product="product"
@add-to-cart="handleAddToCart"
/>
</div>
</template>
<style scoped>
.product-grid {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
gap: 24px; /* 即時調整後的值 */
}
</style>
// Task 2.2: 產品搜尋 API (Parallel Session)
// 理由:純邏輯實作,有明確規格,可自動執行
// implementation-plan.md
### Task 2.2: 產品搜尋 API
**端點:** GET /api/products/search?q=keyword&category=id
**需求:**
- 全文搜尋(名稱、描述)
- 分類篩選
- 價格範圍篩選
- 排序(價格、熱度、新品)
- 分頁(limit, offset)
**實作:**
src/api/search/products.ts
**測試:**
- 測試各種搜尋組合
- 測試邊界條件
- 效能測試(1000+ 商品)
// Task 2.3: 篩選器元件 (Subagent-Driven)
// 理由:高度互動,需要即時調整 UI/UX
// 開發者與 subagent 互動:
// 「建立價格範圍滑桿」
// → 「顏色改為品牌色 #3B82F6」
// → 「加入即時預覽(顯示符合的商品數量)」
// → 「加入重置按鈕」
Phase 3: 購物車(70% Subagent, 30% Parallel)
// Task 3.1: 購物車 UI (Subagent-Driven)
// 理由:複雜的拖放互動、動畫效果
// 開發者與 subagent 互動:
// 「實作拖放功能,可以調整商品順序」
// → 使用 Vue Draggable
// 「加入刪除動畫(淡出)」
// → 調整動畫時長
// 「總價需要即時更新」
// → 驗證計算邏輯
// Task 3.2: 庫存管理邏輯 (Parallel Session)
// 理由:複雜的業務邏輯,可完全自動化
### Task 3.2: 庫存管理邏輯
**需求:**
- 即時庫存檢查(防止超賣)
- 預留庫存(加入購物車後鎖定 15 分鐘)
- 庫存釋放(購物車過期、結帳失敗)
- 庫存警告(低於 10 件時提示)
**實作:**
```typescript
class InventoryManager {
async reserveStock(productId: string, quantity: number, userId: string): Promise<boolean> {
// 1. 檢查庫存充足
// 2. 建立預留記錄
// 3. 設定 15 分鐘過期
// 4. 返回成功/失敗
}
async releaseStock(reservationId: string): Promise<void> {
// 1. 刪除預留記錄
// 2. 恢復庫存數量
}
async commitReservation(reservationId: string): Promise<void> {
// 1. 確認訂單付款
// 2. 永久扣減庫存
// 3. 刪除預留記錄
}
}
測試:
- 併發測試(100 人同時搶購)
- 過期測試(15 分鐘自動釋放)
- 異常測試(付款失敗恢復庫存)
// Task 3.3: 價格計算顯示 (Subagent-Driven) // 理由:需要即時驗證計算邏輯和顯示效果
// 開發者與 subagent 互動: // 「顯示小計、運費、折扣、總計」 // → 驗證計算邏輯 // 「加入動畫效果(數字滾動)」 // → 調整動畫參數 // 「折扣碼套用時高亮顯示折扣金額」 // → 調整視覺效果
**效率對比:**
| Phase | 傳統開發 | 純 Subagent | 純 Parallel | 混合模式 |
|-------|---------|-----------|-----------|---------|
| Phase 1 | 8 小時 | 4 小時 | 2 小時 | **2 小時** ✅ |
| Phase 2 | 12 小時 | 6 小時 | 8 小時 | **4 小時** ✅ |
| Phase 3 | 10 小時 | 5 小時 | 7 小時 | **3.5 小時** ✅ |
| Phase 4 | 15 小時 | 7 小時 | 10 小時 | **5 小時** ✅ |
| Phase 5 | 8 小時 | 5 小時 | 3 小時 | **3 小時** ✅ |
| **總計** | **53 小時** | **27 小時** | **30 小時** | **17.5 小時** ✅ |
**結論:** 混合模式根據任務特性選擇最適合的工具,達到**最高效率**(比傳統開發快 3 倍,比單一模式快 1.5 倍)。
---
## 最佳實踐與進階技巧
### Subagent-Driven 最佳實踐
#### 1. Prompt 工程技巧
**❌ 不好的 Prompt:**
改一下這個元件
**✅ 好的 Prompt:**
請優化 ProductCard 元件:
- 加入 skeleton loading 動畫(使用 Tailwind CSS)
- 圖片加入 lazy loading
- 價格顯示改為格式化(千分位逗號)
- 加入「加入購物車」按鈕的 hover 效果
- 確保響應式設計(手機版垂直排列)
**原則:**
- 具體列出所有需求
- 提供技術偏好(使用哪個函式庫)
- 說明驗收標準
- 分點列出,方便 subagent 逐項處理
#### 2. 善用 Code Review Subagent
```javascript
// 開發完成後,主動要求 code review
// Prompt: 「請審查這段程式碼,重點檢查效能、安全性、可維護性」
// Subagent Code Reviewer 會輸出:
/*
🔍 程式碼審查報告
效能問題:
🔴 Critical: useEffect 缺少 dependency array,造成無限渲染
🟡 Warning: 大型陣列使用 map,建議使用虛擬滾動
安全性問題:
🔴 Critical: XSS 風險 - 使用 dangerouslySetInnerHTML 未清理輸入
🟡 Warning: API key 硬編碼在前端程式碼中
可維護性問題:
🟢 Info: 函式過長(150 行),建議拆分為多個小函式
🟢 Info: 缺少 TypeScript 類型定義
建議修復順序:
1. 修復 useEffect dependency
2. 修復 XSS 漏洞
3. 移除硬編碼 API key
4. (可選) 重構函式結構
*/
3. 快速迭代循環
理想的迭代節奏:
graph LR
A[Prompt 1:<br/>基本功能] -->|2-3 分鐘| B[查看結果]
B -->|立即回饋| C[Prompt 2:<br/>調整 UI]
C -->|1-2 分鐘| D[查看結果]
D -->|立即回饋| E[Prompt 3:<br/>加入互動]
E -->|2-3 分鐘| F[查看結果]
F -->|立即回饋| G[Prompt 4:<br/>優化效能]
G -->|2-3 分鐘| H[完成]
style A fill:#114762ff
style C fill:#114762ff
style E fill:#114762ff
style G fill:#114762ff
style H fill:#0a5317ff
關鍵: 每次 prompt 只專注一個面向,保持快速反饋循環。
4. 上下文管理技巧
Subagent-Driven 的限制是單一 session,上下文可能過大。解決方法:
// 技巧 1: 定期總結上下文
// Prompt: 「總結目前的進度和待辦事項」
/*
Subagent 輸出:
✅ 已完成:
- ProductCard 元件基本結構
- 圖片 lazy loading
- 響應式佈局
🔄 進行中:
- 價格格式化(剩餘千分位逗號)
📋 待辦:
- Skeleton loading 動畫
- 加入購物車按鈕互動
- Hover 效果
*/
// 技巧 2: 使用「記憶點」
// Prompt: 「記住:這個專案使用 Tailwind CSS,色彩使用 blue-600 作為主色」
// 後續 subagent 會自動使用這些偏好
// 技巧 3: 關鍵決策寫入註解
// 請 subagent 在程式碼中加入關鍵決策的註解
/**
* 價格計算邏輯
*
* 決策記錄:
* 1. 使用 Decimal.js 避免浮點數精度問題
* 2. 折扣優先級:會員折扣 > 促銷折扣 > 折扣碼
* 3. 運費計算:訂單 > $1000 免運費
*/
Parallel Session 最佳實踐
1. 撰寫高品質實作計畫
計畫結構範本:
# Task X.Y: [任務標題]
## 目標
[一句話描述任務目標]
## 檔案
**主要檔案:** `path/to/file.ts`
**相關檔案:** `path/to/test.ts`, `path/to/types.ts`
## 需求
[詳細需求列表,使用項目符號]
## 技術規格
[具體的技術實作細節,可包含程式碼範例]
## 驗證條件
- [ ] 單元測試通過
- [ ] 整合測試通過
- [ ] Code coverage > 80%
- [ ] ESLint 無錯誤
- [ ] TypeScript 編譯通過
## 相依性
**依賴於:** Task X.Y-1, Task Z.W
**被依賴於:** Task X.Y+1
## 預估工作量
**複雜度:** 🟢 簡單 / 🟡 中等 / 🔴 複雜
**預估時間:** 30 分鐘
## 備註
[任何額外的上下文或注意事項]
實際範例:Task 2.3 - 實作產品搜尋 API
目標: 建立全文搜尋端點,支援多維度篩選和排序
檔案:
- 主要檔案:
src/api/products/search.ts - 相關檔案:
src/api/products/search.test.ts,src/types/search.ts,prisma/schema.prisma
需求:
- 支援全文搜尋(商品名稱、描述、標籤)
- 支援多維度篩選:分類、價格範圍、庫存狀態、品牌
- 支援排序:相關性、價格、熱度、新品
- 支援分頁(limit, offset)
- 返回符合條件的總數(total)
技術規格 - API 端點:
GET /api/products/search
Query Parameters:
- q: string (搜尋關鍵字)
- categoryId?: string
- minPrice?: number
- maxPrice?: number
- inStock?: boolean
- brandId?: string
- sortBy?: 'relevance' | 'price_asc' | 'price_desc' | 'popularity' | 'newest'
- limit?: number (預設 20, 最大 100)
- offset?: number (預設 0)
Response:
{
products: Product[],
total: number,
limit: number,
offset: number
}
實作要點:
- 使用 Prisma 全文搜尋功能
- 動態組合 where 條件
- 使用 index 優化查詢效能
- 實作相關性評分(使用 _relevance)
- 加入 query 快取(Redis, TTL 5 分鐘)
程式碼骨架:
import { prisma } from '@/lib/prisma'
import { redis } from '@/lib/redis'
import type { SearchParams, SearchResult } from '@/types/search'
export async function searchProducts(params: SearchParams): Promise<SearchResult> {
// 1. 生成快取 key
const cacheKey = generateCacheKey(params)
// 2. 檢查快取
const cached = await redis.get(cacheKey)
if (cached) return JSON.parse(cached)
// 3. 建立搜尋條件
const where = buildWhereClause(params)
const orderBy = buildOrderByClause(params.sortBy)
// 4. 執行查詢
const [products, total] = await Promise.all([
prisma.product.findMany({
where,
orderBy,
take: params.limit,
skip: params.offset,
include: {
category: true,
brand: true,
images: { take: 1 }
}
}),
prisma.product.count({ where })
])
// 5. 組合結果
const result = {
products,
total,
limit: params.limit,
offset: params.offset
}
// 6. 快取結果
await redis.setex(cacheKey, 300, JSON.stringify(result))
return result
}
驗證條件:
- 單元測試覆蓋率 > 90%(基本搜尋、篩選、排序、分頁、邊界條件)
- 整合測試通過(真實資料庫查詢、Redis 快取機制)
- 效能測試:100 萬筆商品資料下查詢 < 100ms,併發 100 requests/sec 穩定
- API 文件更新(OpenAPI spec)
相依性:
- 依賴於:Task 1.2 (Product Schema), Task 1.3 (Prisma 全文搜尋 index)
- 被依賴於:Task 3.1 (前端搜尋元件), Task 4.2 (搜尋建議功能)
預估工作量: 🟡 中等,1.5 小時(實作 45 分鐘、測試 30 分鐘、文件 15 分鐘)
備註:
- 全文搜尋需要 PostgreSQL(使用 tsvector),MySQL 需調整為 FULLTEXT index
- Redis 快取 key 格式:
search:products:{hash(params)} - 考慮加入搜尋分析(記錄熱門搜尋關鍵字)
2. 任務拆分策略
黃金法則: 每個任務應該:
- ✅ 可在 30-90 分鐘內完成
- ✅ 有明確的驗證條件
- ✅ 最小化相依性
- ✅ 產出可獨立測試的成果
任務拆分範例:
# ❌ 不好的拆分(任務過大)
## Task 1: 實作使用者認證系統
- 登入功能
- 註冊功能
- 密碼重置
- Email 驗證
- OAuth 整合(Google, GitHub)
- JWT token 管理
- 權限控制
- 測試
# ✅ 好的拆分(細粒度任務)
## Task 1.1: JWT Token 工具函式
- 檔案: `src/auth/jwt.ts`
- 功能: generateToken, verifyToken, refreshToken
- 驗證: 單元測試 100% 覆蓋率
- 時間: 30 分鐘
## Task 1.2: 使用者註冊 API
- 檔案: `src/api/auth/register.ts`
- 功能: 驗證輸入、hash 密碼、建立使用者
- 驗證: 整合測試(成功、重複 email、無效輸入)
- 時間: 45 分鐘
## Task 1.3: Email 驗證服務
- 檔案: `src/services/email-verification.ts`
- 功能: 發送驗證信、驗證 token
- 驗證: 使用 email sandbox 測試
- 時間: 60 分鐘
## Task 1.4: 使用者登入 API
- 檔案: `src/api/auth/login.ts`
- 功能: 驗證憑證、生成 JWT
- 依賴: Task 1.1
- 驗證: 整合測試
- 時間: 30 分鐘
## Task 1.5: 密碼重置流程
- 檔案: `src/api/auth/reset-password.ts`
- 功能: 請求重置、驗證 token、更新密碼
- 依賴: Task 1.3
- 驗證: E2E 測試完整流程
- 時間: 60 分鐘
## Task 1.6: Google OAuth 整合
- 檔案: `src/auth/oauth/google.ts`
- 功能: OAuth 流程、使用者關聯
- 驗證: 使用 Google OAuth playground 測試
- 時間: 90 分鐘
## Task 1.7: GitHub OAuth 整合
- 檔案: `src/auth/oauth/github.ts`
- 功能: OAuth 流程、使用者關聯
- 依賴: Task 1.6 (可重用 OAuth 基礎架構)
- 驗證: 使用 GitHub OAuth app 測試
- 時間: 45 分鐘
## Task 1.8: 權限控制中介層
- 檔案: `src/middleware/auth.ts`
- 功能: requireAuth, requireRole
- 依賴: Task 1.1
- 驗證: 單元測試 + 整合測試
- 時間: 45 分鐘
## Task 1.9: E2E 認證測試
- 檔案: `tests/e2e/auth.spec.ts`
- 功能: 完整流程測試
- 依賴: 所有前面的任務
- 驗證: Cypress 測試通過
- 時間: 60 分鐘
拆分原則:
- 按功能邊界拆分:每個任務對應一個明確的功能單元
- 按檔案拆分:一個任務主要修改 1-3 個檔案
- 按測試類型拆分:單元測試任務、整合測試任務、E2E 測試任務分開
- 識別共享依賴:可重用的工具函式先實作
3. Checkpoint 策略
自動 Checkpoint(預設):
# .antigravity/config.yml
checkpoint:
auto: true
trigger:
- on_task_complete # 每個任務完成後
- on_test_pass # 測試通過後
- on_git_commit # Git commit 後
保存內容:
- modified_files # 修改的檔案列表
- git_commit_hash # Git commit SHA
- test_results # 測試結果
- execution_log # 執行日誌
- performance_metrics # 效能指標
手動 Checkpoint(關鍵節點):
# 在計畫中標記關鍵 checkpoint
## 🔖 Checkpoint Alpha: 基礎架構完成
**觸發條件:** Task 1.1-1.5 全部完成
**驗證:**
- [ ] 所有 API 端點可正常呼叫
- [ ] 資料庫 migrations 成功
- [ ] 基本認證流程運作
**Review 重點:**
- Schema 設計是否合理?
- API 介面是否符合前端需求?
- 安全性是否考慮周全?
---
## 🔖 Checkpoint Beta: 核心功能完成
**觸發條件:** Task 2.1-2.8 全部完成
**驗證:**
- [ ] 產品CRUD 功能完整
- [ ] 搜尋效能達標
- [ ] 購物車邏輯正確
**Review 重點:**
- 效能是否符合預期?
- 錯誤處理是否完善?
- 使用者體驗是否流暢?
---
## 🔖 Checkpoint RC: 上線前驗證
**觸發條件:** 所有任務完成
**驗證:**
- [ ] E2E 測試 100% 通過
- [ ] 效能測試達標
- [ ] 安全性掃描無嚴重問題
- [ ] 文件完整
**Review 重點:**
- 是否有遺漏的功能?
- 是否有技術債需要處理?
- 上線計畫是否完整?
Checkpoint 恢復:
# 列出所有 checkpoint
/superpowers:list-checkpoints
# 輸出:
# 🔖 Checkpoint Alpha (2025-11-30 10:00)
# Status: ✅ Passed
# Tasks: 1.1-1.5 (5/5 completed)
#
# 🔖 Checkpoint Beta (2025-11-30 14:30)
# Status: ⚠️ Partial (7/8 tasks)
# Failed: Task 2.7 (效能測試未達標)
#
# 🔖 Checkpoint RC
# Status: ⏳ Pending
# 從 Beta checkpoint 恢復並重試失敗任務
/superpowers:resume-from checkpoint-beta --retry-failed
# 系統會:
# 1. 恢復到 Beta checkpoint 的狀態
# 2. 檢查 Task 2.7 失敗原因
# 3. 調整實作(例如加入 index、優化查詢)
# 4. 重新執行效能測試
# 5. 如果通過,繼續後續任務
4. 錯誤處理與自動重試
配置自動重試策略:
# implementation-plan.yml
retry_strategy:
max_attempts: 3
backoff: exponential # linear, exponential, fixed
retry_conditions:
- test_failure
- performance_threshold_not_met
- compilation_error
- linting_error
no_retry_conditions:
- manual_approval_rejected
- dependency_missing
- external_service_down
task_specific_retry:
"Task 2.7": # 效能測試任務
max_attempts: 5
strategy: optimize_and_retry
optimization_steps:
- add_database_index
- enable_query_cache
- implement_connection_pooling
- use_batch_processing
- add_cdn_caching
自動優化範例:
// Task 2.7: 產品搜尋效能優化
// 第一次嘗試:基本實作
// 結果:p95 延遲 450ms ❌ (目標 < 200ms)
// 第二次嘗試:加入資料庫 index
await prisma.$executeRaw`
CREATE INDEX idx_product_search ON products
USING GIN (to_tsvector('english', name || ' ' || description));
`
// 結果:p95 延遲 280ms ❌ (仍未達標)
// 第三次嘗試:加入 Redis 快取
const cacheKey = `search:${hashParams(params)}`
const cached = await redis.get(cacheKey)
if (cached) return JSON.parse(cached)
// ... 執行查詢 ...
await redis.setex(cacheKey, 300, JSON.stringify(result))
// 結果:p95 延遲 180ms ✅ (達標!)
// Checkpoint 記錄:
// Attempt 1: Failed (450ms > 200ms)
// Attempt 2: Failed (280ms > 200ms) - Added DB index
// Attempt 3: Passed (180ms < 200ms) - Added Redis cache
// Final solution: DB index + Redis cache
技術限制與挑戰
Subagent-Driven 的限制
1. 上下文視窗限制
問題: 長時間的 session 會累積大量上下文,導致效能下降或觸及 token 限制。
解決方案:
// 策略 1: 定期總結並重置
// 每完成一個功能模組,要求總結並開啟新 session
// Prompt: 「總結目前完成的工作,列出關鍵決策和下一步」
/*
總結:
✅ 完成 ProductCard 元件(支援 lazy loading、響應式)
✅ 完成價格格式化(使用 Decimal.js)
✅ 完成 hover 效果(scale 1.05)
關鍵決策:
- 使用 Tailwind CSS
- 主色 blue-600
- 間距 24px
- 圖片比例 4:3
下一步:
- 購物車元件
- 結帳流程
*/
// 策略 2: 使用「記憶檔案」
// 將關鍵決策寫入專案的 DECISIONS.md
// 新 session 可以快速載入這個檔案
// DECISIONS.md
/*
# 專案決策記錄
## UI/UX
- 主色: #3B82F6 (blue-600)
- 間距標準: 8px 為基準單位
- 圓角: 8px (卡片), 4px (按鈕)
- 動畫時長: 200ms (hover), 300ms (轉場)
## 技術選型
- 狀態管理: Pinia
- UI 框架: Tailwind CSS
- 圖表: Chart.js
- 日期: date-fns
- 數字精度: Decimal.js
## API 規範
- 日期格式: ISO 8601
- 錯誤格式: { error: { code, message, details } }
- 分頁: limit/offset
*/
// 新 session 開始時:
// Prompt: 「請閱讀 DECISIONS.md,遵循這些決策」
2. 不適合長時間執行任務
問題: Subagent 需要開發者持續在場,不適合超過 1-2 小時的任務。
解決方案: 混合模式 - 長任務切換到 Parallel Session
# 範例:大型資料庫遷移
# 階段 1: 使用 Subagent-Driven 設計遷移腳本
# (30 分鐘,需要即時調整邏輯)
Prompt: 「設計 User 資料表遷移腳本,從 MySQL 到 PostgreSQL」
→ 生成遷移腳本
→ 審查並調整
→ 測試小量資料
# 階段 2: 切換到 Parallel Session 執行大規模遷移
# (3 小時,背景執行)
/superpowers:execute-plan migration-plan.md
→ 系統自動執行
→ 開發者可以去做其他事
→ 完成後通知審查
3. 多人協作困難
問題: Subagent-Driven 是單人單 session,無法多人同時協作同一任務。
解決方案: 使用 Parallel Session 或 Git 工作流程
Parallel Session 的限制
1. 需要詳細的前期規劃
問題: 如果實作計畫寫得不夠詳細,AI 可能無法正確執行。
解決方案: 使用計畫範本 + AI 輔助生成計畫
# 使用 Subagent 幫忙撰寫 Parallel Session 計畫
Prompt: 「我需要實作使用者認證系統,包含註冊、登入、OAuth。請幫我撰寫一份適合 Parallel Session 執行的實作計畫」
# Subagent 會生成詳細的 implementation-plan.md
# 包含:
# - 任務拆分(每個 30-90 分鐘)
# - 檔案路徑
# - 程式碼範例
# - 驗證條件
# - 相依性圖
# 開發者審查並調整計畫
# 然後執行 Parallel Session
2. 難以處理需求變更
問題: 執行過程中如果需求改變,Parallel Session 難以動態調整。
解決方案: Checkpoint 暫停 + Subagent 調整
# 情境:正在執行 Phase 2,但 Phase 1 的設計需要調整
# 1. 暫停 Parallel Session
/superpowers:pause-execution
# 2. 切換到 Subagent-Driven 快速調整
Prompt: 「Phase 1 的 User Schema 需要加入 role 欄位,請幫我調整」
→ 快速修改 schema
→ 更新 migration
→ 測試驗證
# 3. 更新實作計畫
# 修改 implementation-plan.md,反映新的 schema
# 4. 恢復 Parallel Session
/superpowers:resume-execution --update-plan
→ 系統重新載入計畫
→ 繼續執行,使用新的 schema
3. 除錯困難
問題: 自動執行的程式碼出錯時,難以即時除錯。
解決方案: 詳細的日誌 + 自動測試 + 人工審查點
# 配置詳細日誌
logging:
level: debug
output:
- console
- file: .antigravity/logs/execution.log
include:
- executed_commands
- test_output
- error_stack_traces
- performance_metrics
- git_operations
on_error:
- capture_screenshot # 如果是 UI 相關
- dump_database_state # 如果是資料相關
- save_network_logs # 如果是 API 相關
- pause_execution # 暫停讓開發者介入
自動重試範例:
// Task 執行失敗時的處理流程
async function executeTask(task: Task) {
let attempt = 0
const maxAttempts = 3
while (attempt < maxAttempts) {
try {
attempt++
// 執行任務
const result = await runTask(task)
// 執行測試
const testResult = await runTests(task.tests)
if (testResult.passed) {
// 成功,建立 checkpoint
await createCheckpoint(task, result)
return result
} else {
// 測試失敗,分析原因
const analysis = await analyzeFailure(testResult)
if (analysis.canAutoFix) {
// 自動修復並重試
await applyFix(analysis.suggestedFix)
continue
} else {
// 無法自動修復,暫停並通知開發者
await pauseExecution()
await notifyDeveloper({
task,
attempt,
error: testResult.errors,
analysis
})
// 等待人工介入
await waitForManualFix()
continue
}
}
} catch (error) {
// 執行階段錯誤
logger.error(`Task ${task.id} attempt ${attempt} failed:`, error)
if (attempt === maxAttempts) {
// 最終失敗,記錄並暫停
await logFailure(task, error)
await pauseExecution()
throw new TaskExecutionError(task, error)
}
// 重試前等待(exponential backoff)
await sleep(Math.pow(2, attempt) * 1000)
}
}
}
工具與生態系統
推薦工具整合
| 工具類型 | 推薦工具 | 與 Subagent 整合 | 與 Parallel 整合 |
|---|---|---|---|
| 版本控制 | Git + GitHub | ✅ 手動 commit | ✅ 自動 commit per task |
| CI/CD | GitHub Actions | ✅ 手動觸發 | ✅ 自動觸發 |
| 測試 | Vitest, Cypress | ✅ 即時執行 | ✅ 批次執行 |
| Linting | ESLint, Prettier | ✅ 即時檢查 | ✅ pre-commit hook |
| 類型檢查 | TypeScript | ✅ 即時驗證 | ✅ 批次驗證 |
| 效能監控 | Lighthouse CI | ✅ 手動觸發 | ✅ 自動執行 |
| 錯誤追蹤 | Sentry | ✅ 整合 | ✅ 整合 |
| 專案管理 | Linear, Notion | 🔶 手動同步 | ✅ 自動同步(MCP) |
Claude Code Superpowers Skills
推薦安裝的 skills:
# 核心 skills
- superpowers:brainstorming # 任務規劃前腦力激盪
- superpowers:writing-plans # 撰寫 Parallel Session 計畫
- superpowers:executing-plans # 執行 Parallel Session 計畫
- superpowers:verification-before-completion # 完成前驗證
- superpowers:code-reviewer # 程式碼審查
- superpowers:test-driven-development # TDD 工作流程
- superpowers:systematic-debugging # 系統化除錯
# 進階 skills
- superpowers:using-git-worktrees # Git worktree 管理
- superpowers:subagent-driven-development # Subagent 最佳實踐
- superpowers:dispatching-parallel-agents # 並行代理管理
總結與決策指南
快速決策表
| 你的情境 | 推薦模式 | 原因 |
|---|---|---|
| 🎨 開發互動式 UI | Subagent-Driven | 需要即時視覺回饋 |
| 🔧 修復單一 Bug | Subagent-Driven | 快速迭代驗證 |
| 📦 大型重構(10+ 檔案) | Parallel Session | 可明確拆分任務 |
| 🗄️ 資料庫遷移 | Parallel Session | 長時間背景執行 |
| 🧪 撰寫測試套件 | Parallel Session | 可批次執行 |
| 🎯 探索性開發 | Subagent-Driven | 方向尚未明確 |
| 📚 撰寫技術文件 | Parallel Session | 可完全自動化 |
| ⚡ 效能優化 | Subagent-Driven | 需要即時監控調整 |
| 🔐 實作認證系統 | Parallel Session | 有標準實作流程 |
| 🎭 設計原型 | Subagent-Driven | 需要快速嘗試 |
| 🏗️ 建立專案骨架 | Parallel Session | 可用範本自動化 |
| 🐛 除錯複雜問題 | Subagent-Driven | 需要互動式調查 |
| 📊 資料分析腳本 | Parallel Session | 可自動執行驗證 |
| 🎮 遊戲邏輯開發 | Subagent-Driven | 需要即時測試體驗 |
| 🌐 API 整合 | 混合模式 | 設計用 Subagent,批次實作用 Parallel |
核心建議
1. 從 Subagent-Driven 開始,必要時切換到 Parallel Session
大多數任務一開始方向不夠明確,使用 Subagent-Driven 快速探索和驗證。當設計穩定後,切換到 Parallel Session 大規模執行。
2. 投資時間撰寫高品質的實作計畫
對於 Parallel Session,詳細的計畫是成功的關鍵。花 30 分鐘撰寫計畫,可以節省 3 小時的執行時間。
3. 建立 Checkpoint 文化
無論哪種模式,都要養成建立 checkpoint 的習慣:
- Subagent: 每完成一個功能模組就總結
- Parallel: 在關鍵節點設定 manual checkpoint
4. 善用混合模式
不要拘泥於單一模式。根據任務特性靈活切換,發揮兩種模式的互補優勢。
5. 持續學習和調整
這兩種模式都還在快速演進。持續關注社群最佳實踐,調整自己的工作流程。
參考資源
官方文件
延伸閱讀
社群資源
寫作時間: 2025-11-30 最後更新: 2025-11-30