一個人的工程團隊：Claude Code 平行作業完整指南

2026 年初，Boris Cherny——Claude Code 的創造者——在 Threads 分享了一條讓開發者社群驚呼的工作流：他同時跑著 10-15 個 Claude Code session，各自在不同任務上獨立推進。這條貼文在開發者社群廣泛流傳，因為它揭示了一個多數人從未想過的可能性。

大多數人用「單線程」思維在使用 Claude Code，等同於雇了一個工程師卻只讓他一次做一件事。如果你每天等 Claude 完成一個任務才開始下一個，你浪費的不是時間，是整個工作流的槓桿。這篇指南從決策框架到實際設定，完整拆解平行作業工作流，讓一個開發者發揮小型工程團隊的吞吐量。

TL;DR

• 平行 3-5 個 worktree 是 Boris 本人的直接建議，加上網頁 session 可達 10-15 個
• 決策原則：只有任務之間完全獨立、不共用核心檔案，才適合平行
• claude --worktree [name] 一行指令建立完全隔離的工作環境
• CLAUDE.md 三層架構（全局 / 專案 / 任務）是平行作業保持一致性的大腦
• macOS hooks 讓你不需要盯著每個 terminal tab，Claude 完成或卡住時自動通知

---

為什麼 Claude Code 的創造者同時跑 15 個 session？

Boris Cherny 在 Threads 分享的原文是這樣描述的：他在終端機開 5 個 Claude Code 視窗，同時透過 claude.ai/code 網頁版跑 5-10 個附加 session，加上手機上的 session，總計接近 10-15 個並行工作流。這條貼文在開發者社群廣泛流傳。

他把這個做法稱為「最大的單一生產力解鎖（single biggest productivity unlock）」，而且這是整個 Claude Code 開發團隊票選的第一名技巧，不是他個人偏好。

核心哲學只有一句話：「減少干預 + 更好的工具使用 = 更快的整體結果」。

傳統開發思維是序列的——完成 A，再做 B，再做 C。但 Claude Code 不是一個會累的工程師，它可以同時在多個獨立問題上全力推進，而你只需要在關鍵節點介入。Boris 的另一個核心做法是搭配 Plan Mode：先用 Plan Mode 細化每個任務的策略和邊界，確認方向後再啟動多個 session 平行執行，而非反覆來回修正。這讓他能夠「放心讓 Claude 跑，不需要隨時盯著」。

我在 Shareuhack 自己的 autonomous content system 中也驗證了同樣的模式：同時跑 scout、research、writer、social 四個獨立 worker，每個負責完全不同的任務，整體吞吐量提升了 3-4 倍。

---

哪些任務值得平行？四象限決策框架

平行作業不是「越多越好」，而是「對的任務才平行」。我整理了一個判斷框架：

問三個問題：

1. 這個任務完成的前提，是否仰賴另一個進行中的任務？（有相依性 → 不適合）
2. 多個任務是否需要修改同一組核心檔案？（有共用狀態 → 不適合）
3. 每個任務的邊界是否清楚到可以用一句話說明？（邊界模糊 → 先拆分再平行）

三題都通過才啟動平行。

適合平行的任務：

• 多個獨立的功能開發（Feature A 和 Feature B 用不同檔案）
• 單元測試撰寫（幾乎不相依）
• 文件生成（完全獨立）
• 分散在不同模組的 bug 修復
• 大規模程式碼遷移（按目錄分批）

不適合平行的任務：

• 任務 B 需要任務 A 的輸出（例如：先重構 API，再更新前端）
• 多個 agent 同時修改 config.ts 或共用的核心 utility
• 整體架構層級的設計決策（需要人類保持主控視角）

incident.io 的工程團隊實際案例是很好的參考：他們同時跑 4-5 個 agent，分別負責 UI 改善、build 工具優化、測試規格撰寫、後端 feature——每個任務都在自己的檔案領域，沒有交疊。

---

一鍵建立隔離環境：git worktree + --worktree flag 實戰

為什麼需要 worktree？

平行跑多個 Claude Code session，最大的風險是多個 session 在同一個 working directory 上互相覆蓋。git worktree 的作用是讓每個任務在自己的目錄裡工作，有自己的 branch，完全隔離。

官方 --worktree flag（推薦）

Claude Code CLI 有內建的 --worktree 支援，一行指令搞定：

# 建立名為 feature-auth 的隔離 worktree 並啟動 Claude
claude --worktree feature-auth

# 同時開另一個 session
claude --worktree bugfix-payment

# 不指定名稱，Claude 自動產生（如 bright-running-fox）
claude --worktree

這行指令會：

1. 在 <repo>/.claude/worktrees/<name>/ 建立新的工作目錄
2. 建立 branch worktree-<name>，從預設 remote branch 分支
3. 在隔離目錄裡啟動 Claude Code session

Session 結束時：若 worktree 沒有任何修改，自動清除；若有 commit，Claude 會詢問你是否保留。

建議在 .gitignore 加入：

.claude/worktrees/

避免主 repo 出現大量 untracked files。

手動 git worktree（需要更精細控制時）

# 建立新 branch + worktree
git worktree add ../project-feature-a -b feature-a

# 在 worktree 啟動 Claude
cd ../project-feature-a && claude

# 完成後清除
git worktree remove ../project-feature-a

Plan Mode 搭配使用

啟動多個 worktree session 之前，先進入 Plan Mode（Shift+Tab 切換，或 claude --permission-mode plan）為每個任務確認方向。Plan Mode 下 Claude 不會執行任何檔案修改，只規劃策略，確認 scope 清晰後再切換到執行模式——這樣你就能放心讓多個 session 在背景跑，不用擔心未授權的修改。

---

CLAUDE.md 三層架構：讓每個平行 session 都懂規則

多個 worktree 同時跑，每個 session 都需要理解「這個專案的規則是什麼」。CLAUDE.md 的三層架構就是解決這個問題的核心設計。

第一層：全局層（~/.claude/CLAUDE.md）

這是你的個人設定，所有 session 都載入，不進 git。適合放：

• 個人程式碼風格偏好
• 個人常用工具和快捷指令
• 個人工作習慣

重要：保持極度精簡，每個 session 都會完整載入這個檔案，太長會消耗 context。我個人建議不超過 50 行。

第二層：專案層（./CLAUDE.md 或 ./.claude/CLAUDE.md）

這是團隊共享的規範，進 git，讓所有協作者和所有 worktree 共享：

• 架構決策和設計原則
• Build 指令、測試指令
• 命名慣例、目錄結構
• 常用 workflow 的說明

Shareuhack 的專案層 CLAUDE.md 放的就是整個內容 pipeline 的規則：每個 Agent 做什麼、禁止事項、frontmatter 規範——讓每個平行跑的 agent 都清楚邊界。

第三層：任務層（.claude/rules/ 目錄）

這是最細粒度的設定，可以把規則綁定到特定檔案路徑：

---
description: API 路由層規範
paths:
  - "src/api/**/*.ts"
---

# API 路由規則
- 所有端點必須有 Zod 驗證
- 錯誤回應格式統一用 { error: string, code: string }

這個規則只在 Claude 開啟 src/api/**/*.ts 路徑的檔案時才載入，避免污染其他任務的 context。

跨 worktree 的記憶：所有 worktree 共享同一個 auto memory 目錄（~/.claude/projects/<git-repo>/memory/），所以 Claude 在一個 worktree 學到的東西，在另一個 worktree 也能用。

實用建議：官方建議每個 CLAUDE.md 盡量保持在 200 行以內，超過這個長度遵循度會下降。詳細說明建議拆成 agent_docs/ 子目錄的獨立 .md 檔案，主 CLAUDE.md 用 @agent_docs/api-rules.md 語法按需引入。

---

不在 10 個 Tab 裡迷失：Session 管理與通知機制

同時管理多個 session，最大的挑戰不是技術設定，而是「我要怎麼知道哪個完成了，哪個卡住需要我介入」。

macOS 通知機制（hooks）

Claude Code 的 hooks 功能是解決這個問題的最佳工具。在 ~/.claude/settings.json 設定：

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e \"display notification 'Claude 完成任務' with title 'Claude Code'\" && afplay /System/Library/Sounds/Glass.aiff",
            "async": true
          }
        ]
      }
    ],
    "PermissionRequest": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e \"display notification '需要你的確認' with title 'Claude Code 等待'\" && afplay /System/Library/Sounds/Ping.aiff",
            "async": true
          }
        ]
      }
    ]
  }
}

• Stop hook：Claude 完成一個回應時觸發，用來通知「任務完成」
• PermissionRequest hook：Claude 需要人工確認時觸發，用來通知「有 session 卡住等你」

設定 "async": true 避免 hook 阻塞 session 的執行。

命名和狀態追蹤

worktree 命名即任務描述：用有意義的名稱，例如 feature-auth、bugfix-payment，而不是 worktree-1、worktree-2。這樣在終端機分頁上一眼就能看出每個 session 在做什麼。

自訂 /worktree-status 指令：jackle.pro 的做法是在 CLAUDE.md 定義一個 slash command，一次列出所有 worktree 的 git 狀態：

# 在 CLAUDE.md 或 slash command 中定義
git worktree list && for wt in $(git worktree list --porcelain | grep worktree | awk '{print $2}'); do echo "=== $wt ==="; git -C $wt status --short; done

Boris 的 iTerm2 做法：用 iTerm2 的編號分頁管理多個 session，並在 iTerm2 設定「需要輸入時鳴響」。--name flag 可以給 session 命名便於識別：

claude --worktree feature-auth --name "auth-worker"

決定何時介入

我的個人原則：啟動 session 後，在第一個 5 分鐘 checkpoint 看一下進展，確認 Claude 的方向正確再讓它繼續跑。之後每 15-20 分鐘掃描一次，依賴 hooks 通知處理完成或卡住的情況。不要在 Claude 執行中途不斷打斷，這反而會降低整體品質。

---

立刻試試看：今天就打開你的第二個 session

平行作業不是 power user 的特技，而是讓 Claude Code 物盡其用的正確姿勢。如果你已經在用 Claude Code，你現在已經有所有需要的工具了。

最快的上手方式：找一個你手邊可以拆成 3 個獨立任務的專案，用上面的決策框架驗證這 3 個任務彼此獨立，然後：

claude --worktree task-a   # 第一個 terminal tab
claude --worktree task-b   # 第二個 terminal tab
claude --worktree task-c   # 第三個 terminal tab

給每個 session 清楚的任務說明，啟動，然後去喝杯咖啡。等 hooks 通知響了再回來。

這就是 Boris 工作的方式，也可以是你工作的方式。