前言:AI 協作開發的範式演進

在 AI 輔助開發工具快速演進的今天,我們已經從「程式碼自動補全」進化到「AI 主動協作」的階段。Claude Code 作為 Anthropic 推出的革命性開發工具,引入了兩種截然不同但互補的協作模式:Subagent-Driven DevelopmentParallel 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執行測試並驗證輸出測試結果、覆蓋率報告

核心特性:

  1. 即時回饋循環:每個 subagent 完成任務後立即提供結果,開發者可以馬上調整方向
  2. 共享上下文:所有 subagent 在同一 session 內,共享相同的專案上下文和對話歷史
  3. 快速迭代:適合需要頻繁調整的任務,如 UI 調整、API 整合、演算法優化
  4. 低延遲溝通:開發者和 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 的實作依賴於兩個關鍵技術:

  1. Git Worktree:允許同一個 repository 有多個工作目錄
  2. 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-DrivenParallel 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 輪快速迭代:

  1. 初始骨架(5 分鐘)
  2. D3.js 繪圖(10 分鐘)
  3. 色階調整(3 分鐘)
  4. Tooltip 互動(8 分鐘)
  5. Code Review(自動,2 分鐘)
  6. 效能與響應式優化(15 分鐘)
  7. 最終測試(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 測試情境:

  1. REST API 仍可正常運作(向後相容)
  2. GraphQL API 功能完整
  3. 前端使用 GraphQL 無錯誤
  4. 效能無退化(回應時間對比)

驗證:

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 元件:

  1. 加入 skeleton loading 動畫(使用 Tailwind CSS)
  2. 圖片加入 lazy loading
  3. 價格顯示改為格式化(千分位逗號)
  4. 加入「加入購物車」按鈕的 hover 效果
  5. 確保響應式設計(手機版垂直排列)

**原則:**
- 具體列出所有需求
- 提供技術偏好(使用哪個函式庫)
- 說明驗收標準
- 分點列出,方便 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
}

實作要點:

  1. 使用 Prisma 全文搜尋功能
  2. 動態組合 where 條件
  3. 使用 index 優化查詢效能
  4. 實作相關性評分(使用 _relevance)
  5. 加入 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. 按功能邊界拆分:每個任務對應一個明確的功能單元
  2. 按檔案拆分:一個任務主要修改 1-3 個檔案
  3. 按測試類型拆分:單元測試任務、整合測試任務、E2E 測試任務分開
  4. 識別共享依賴:可重用的工具函式先實作

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/CDGitHub Actions✅ 手動觸發✅ 自動觸發
測試Vitest, Cypress✅ 即時執行✅ 批次執行
LintingESLint, 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  # 並行代理管理

總結與決策指南

快速決策表

你的情境推薦模式原因
🎨 開發互動式 UISubagent-Driven需要即時視覺回饋
🔧 修復單一 BugSubagent-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