Claude Code Projects 改版實戰：一個協調者帶多條平行 thread，從設定到第一批任務手把手

Claude Code 新版 projects 讓一段對話當協調者，把工作分派給多條各自開分支、跑測試、開 PR 的雲端 thread。這篇拆解運作機制、beta 限制，並附 instructions 模板與交代任務的 prompt 寫法。

AI Academy 編輯部2026年11月15日
本文目錄（8 節）▾
  1. 一、它要解決的問題：平行不難，難的是調度
  2. 二、運作原理：一個協調者、多條 thread、一份共享記憶
  3. 三、數據與限制：先知道再開跑
  4. 四、手把手：把第一個 project 跑起來
  5. 五、本機也能跑：Remote Control 當 thread
  6. 六、什麼時候該用，什麼時候別用
  7. 七、對工程團隊的意義
  8. 來源

你手上應該也有這種清單：一個 bug 要修、一支 API 要補測試、文件落後兩個版本、還有一個重構一直沒時間碰。用 Claude Code 的時候，你大概是開一個 session 處理一件，處理完再開下一個；想平行就自己開好幾個終端機、切好幾個 worktree，然後在視窗之間來回確認誰跑完了、誰卡住了。

Anthropic 在 2026 年 9 月 17 日發的〈Projects redesigned: from folder to conversation〉，就是把這件「你自己當調度員」的工作收進產品裡。新的 Claude Code projects 不再只是放檔案的資料夾，而是一段對話：裡面有一個負責分派的協調者（coordinator），底下有多條實際動手的 thread，每條 thread 是一個獨立的 Claude Code 雲端 session，在自己的分支上改 code、跑測試、開 PR。

這篇不談「AI 員工時代來了」那種話，只講三件事：它到底怎麼運作、哪些數字和限制要先知道、以及照著做就能把第一批平行任務跑起來的設定與 prompt。

一、它要解決的問題：平行不難，難的是調度

單一 agent session 的瓶頸早就不是模型會不會寫，而是三件雜事：

  1. 上下文互相污染：同一個 session 裡又修 bug 又寫文件，context window 很快被塞滿，後面的任務品質下降。
  2. 檔案衝突：多個 session 同時改同一個工作目錄，彼此覆蓋。過去的解法是自己開 git worktree。
  3. 人變成瓶頸：你要記得每個 session 的狀態、哪個在等你回覆、哪個 PR 該 review。

新 projects 對應的解法分別是：每條 thread 有自己的 context window；每條雲端 thread 在自己的分支和 repo 副本上工作，重疊的修改用一般 PR 的 merge conflict 處理；狀態則統一收進 project 的 Overview 看板。

二、運作原理：一個協調者、多條 thread、一份共享記憶

Claude Code projects 架構：協調者對話分派任務給多條雲端 thread，各自開分支與 PR，並共用 project 記憶

1. 協調者：project 本身那段對話

官方文章的說法是，你在 project 裡交代事情的方式，應該像在交代一位幕僚長（chief of staff）。依官方文件，協調者會判斷你送出的每則訊息要去哪裡：

  • 快問快答，直接在對話裡回答。
  • 新的工作，丟給新 thread，或丟給已經在那個區域工作的 thread，並告訴你它選了哪條。
  • 一則訊息裡塞了幾件不相干的事，會拆成各自的 thread。

文件沒有寫 @ 提及或用 thread ID 指名的語法。要直接對某條 thread 說話，唯一記載的方式是打開那條 thread、在它自己的輸入框發訊息；在主對話補的追問，只有在協調者判斷屬於那條 thread 時才會轉過去。

2. Thread：一條 thread 就是一個雲端 session

官方文章寫得很直接：每條 thread 是一個 Claude Code cloud session，在自己的分支和 repo 副本上工作。接了 repo 的 thread 會開 PR、跑你的測試；接的是文件，就讀文件、起草內容。thread 內部還可以再用 subagent、loop、workflow 拆工作，但文件特別說明 subagent「不是 project 的概念」，是 thread 自己內部的事。

預設模型設定（依文件）：thread 用 Opus、high effort；協調者對話用 low effort。邏輯很合理：協調者只負責分派和彙整，不需要燒高 effort。

3. 共享記憶與 Library

每條 thread 都會寫入、也會讀取同一份 project 記憶。文件描述它是「Claude 記下的專案筆記，例如需求、決策、踩過的坑」，以檔案形式儲存；每條雲端 thread 啟動時會先讀索引檔 MEMORY.md，需要時再打開其他檔案。

三個實務重點：

  • 記憶由 Claude 自己寫，但你可以在 Project settings > Memory 讀、改、刪。
  • 你可以在主對話或任何 thread 叫 Claude 記住或忘掉某件事。
  • 它和 repo 裡的 CLAUDE.md 是分開的兩套東西，也和你本機 Claude Code 的 auto memory 分開。

另外有一個 Library，收你加進來的檔案和 Claude 產出的成品。

4. Overview：六個狀態欄

文件列出的 thread 分組如下，這是你每天實際會看的地方：

分組意思（依官方文件）
Ready for reviewPR 已開、等人 review
Waiting on you需要你回覆或核准，或已失敗
Working還在跑
LandingPR 已核准或排隊合併中
Idle做完了、沒在等任何事
Resolved已標記完成；一週沒動靜也會自動歸到這裡，可重新打開

header 的 Threads 按鈕有圓點時，代表有 thread 在等你。實務上你只要盯「Waiting on you」和「Ready for review」兩欄。

三、數據與限制：先知道再開跑

官方文章本身沒有任何效能或速度數字，以下全部來自官方文件，能確認的才寫：

  • 方案：文件寫 projects 在 Pro、Max、Ultra 方案為 public beta、逐步開放；Team 和 Enterprise 尚未提供。9 月的官方文章則寫首批只開給部分 Pro／Max、使用雲端 session、且在網頁或桌面版沒有既有 projects 的使用者，並附候補名單表單。兩者時間點不同，以你帳號實際看到的為準。
  • 介面：claude.ai/code、桌面 app 的 Code 分頁、iOS／Android app。終端機 CLI、VS Code、JetBrains 裡沒有；透過 Bedrock、Google Cloud、Microsoft Foundry 使用也不行。
  • Repo 前提：github.com 上的 repo，且要裝 Claude GitHub App。GitHub Enterprise Server、GitLab、Bitbucket 不支援。
  • 上限：文件寫的硬上限是所有 projects 合計每天 500 條新 thread。
  • 用量：算在一般方案額度裡，超過要用 usage credits。官方文章也提醒，project 會同時跑好幾條 thread，所以會比平常更快碰到用量上限。
  • Beta 限制：一個 project 只能一個人用、不能分享、thread 不能在 project 之間移動、beta 期間沒有組織層級管控；若沙箱無法恢復，未 commit 的工作可能會遺失。

最後一條最該記住：要求 thread 頻繁 commit、早點開 draft PR，就是你對這條限制的保險。

四、手把手：把第一個 project 跑起來

Step 1：建立 project

側欄 Projects（或 More）> New project，填三欄：

  • Name（必填）
  • What do you want to work on?：目標，選填但建議寫
  • Context：repo、檔案、資料夾、Google Drive

按 Create project。已經在某個 session 裡做到一半，也可以用 Continue in project > Continue as new project 把它升級成 project。建好後 Claude 會先提議幾件它馬上能接的工作。

Step 2：先調環境，再發任務

Thread 預設跑在 Anthropic 託管的 Default 環境，沒有環境變數也沒有 setup script。真的要跑你的測試，通常得到 Project settings > Environment 指定一個自訂環境。依 cloud environments 文件：

  • 網路分 None、Limited、Full 三級；新環境預設 Limited 且勾選「Allow package managers」。要打內部 API，就在 Allowed domains 一行一個網域，*. 開頭可涵蓋所有子網域。
  • 環境變數用 .env 格式，一行一個 KEY=value。注意：用這個環境的人都讀得到，金鑰別放這裡。
  • API 金鑰改用 network secrets：由代理在請求送往你列出的主機時附上，Claude 本身看不到金鑰。
  • setup script 是在 Claude Code 啟動前跑的 Bash，用來裝預設映像沒有的工具（文件舉的例子是 apt update && apt install -y shellcheck）。腳本要能在合理時間內結束，失敗的步驟加 || true 免得整個卡住。

Step 3：寫 project instructions（最多 16,000 字元）

Project settings > Memory 的 project instructions 是每條 thread 都會吃到的共同規則。文件建議涵蓋五件事：這個 project 為了什麼、用哪些 repo 和分支、thread 怎麼驗證自己的成果、缺東西時怎麼辦、哪些動作要先問。repo 專屬規則則留在該 repo 的 CLAUDE.md。

下面是依文件範例改寫、可直接套用的模板：

目標：把 payments API 的 p95 延遲壓在 200 ms 以下，不破壞現有測試。

Repo 與分支：
- 只動 org/payments-api，從 main 開分支
- 每條 thread 開一個 draft PR，標題前綴 [proj-latency]

驗證：
- 改完必跑 `npm test` 和 `npm run bench`，把前後 p95 貼在 PR 描述
- 沒跑過測試不要說「已完成」

缺東西時：
- 拿不到需要的權限、資料或服務，第一則訊息就講清楚缺什麼，然後停下
- 不要自己 mock、替代或猜

需要先問我的：
- merge、force-push、改 CI 設定，一律先在 thread 裡問我

習慣：
- 每完成一個可運作的段落就 commit 並 push

最後那條「頻繁 commit」是針對前面「沙箱無法恢復時未 commit 的工作可能遺失」補的，文件範例沒有，是我們建議加的。

Step 4：第一批任務要小

文件的建議是：先寫好 instructions、送一件小而真實的任務、確認 thread 的模型與 effort，並請 Claude「先提議 thread、再開始」、一次只跑幾條。直接對協調者說：

先提議要開哪些 thread，每條寫一句範圍和驗收方式，等我說 OK 再開始。
同時最多跑兩條。

文件說這類偏好 Claude 會自己存進 project 記憶，下次不用重講。

Step 5：交代任務的寫法

既然是「交代幕僚長」，訊息就用「結果 + 驗收 + 邊界」三段寫，讓協調者好拆：

這週要處理三件事，請拆成獨立的 thread：
1. 修 issue #412：退款金額為負時 500。驗收：新增回歸測試、CI 綠燈。
2. 幫 /v2/invoices 補整合測試，覆蓋率報告貼在 PR。
3. 把 README 的部署段落更新成目前的 Docker 流程，只動文件。
三件互不相依，可以平行。第 1 件優先。

三件互不相干，依文件描述協調者會拆成三條 thread。如果它把相關的追問丟去開新 thread，你可以直接說「同一區域的追問沿用原本的 thread」；反過來，簡單問題不想開 thread 就說「這個直接在這裡回答」。

Step 6：盯 Overview，在 thread 裡下指令

每天的節奏是：看 Waiting on you 處理卡點、看 Ready for review 審 PR。要修正某條 thread 的方向，打開那條 thread 直接講，不要在主對話含糊地補一句，免得協調者轉錯地方。

覺得某個做法不對時，明講並請它記住（例如「以後這個 repo 一律用 pnpm，記到 project 記憶」），這比每次在 prompt 裡重寫更省事。

五、本機也能跑：Remote Control 當 thread

官方文章寫的是「目前 thread 在雲端跑，在你自己機器上跑的版本很快就來」，但官方文件已經描述了透過 Remote Control 開本機 thread 的做法，需要 Claude Code v2.1.280 以上：

# 終端機：讓這台機器接受 project 派來的本機 thread
cd ~/code/payments-api
claude remote-control --spawn worktree

--spawn worktree 會讓每條 thread 有自己的 git worktree，避免互相覆蓋（需要在 git repo 裡）。其他常用旗標依 Remote Control 文件：--capacity <N> 限制同時 session 數（預設 32）、--permission-mode acceptEdits 設定權限模式、--name 設 session 標題；claude rc 是別名。桌面 app 則在 Settings > Code 開「Use this computer from your phone and claude.ai」，並可開「Keep this computer awake for Remote Control」避免電腦睡著。之後在 project 的 + 選單選 Work locally。

什麼時候選本機：需要存取只在你內網的服務、本機才有的資料或 GPU，或是 repo 不在 github.com 上的情況。後者文件沒有明說本機 thread 是否繞得過 GitHub 限制，值得實測的點就在這裡。

六、什麼時候該用，什麼時候別用

何時該用 Claude Code projects：適合與不適合的場景對照

適合：

  • 一個目標底下有多件互不相依的任務：修幾個獨立 bug、各模組補測試、文件與程式同步更新。
  • 會持續好幾天的工作：共享記憶和 Overview 的價值在時間拉長時才顯現。
  • 你想離開電腦、用手機回覆卡點：官方文章特別提到這點。

不適合：

  • 高度耦合的改動：例如同時改資料模型和所有呼叫端。拆成多條 thread 只會換來一堆 merge conflict，用單一 session 依序做比較快。
  • 額度緊的方案：平行等於同時燒額度，Pro 方案先把同時 thread 數壓在一、兩條。
  • 團隊協作：beta 期間一人一 project、不能分享，也沒有組織管控。
  • repo 不在 github.com：雲端 thread 直接不支援。

一個判斷法：如果你能把任務寫成三行「範圍＋驗收」而且彼此不提到對方，就適合拆 thread；寫的時候一直出現「等 A 做完再改 B」，就別拆。

七、對工程團隊的意義

把這個功能用好，核心不在 Claude 多會寫，而在你把「規則、驗收、邊界」寫得多清楚。具體可以這樣分工：

  1. repo 的 CLAUDE.md 放 repo 規則（測試指令、程式風格），任何 session 都吃得到。
  2. project instructions 放這個目標的規則（範圍、分支命名、要先問的動作）。
  3. project 記憶讓 Claude 自己累積，你定期到 Settings > Memory 清掉過時或錯的條目。

另外，PR 仍然是唯一的合併關卡。thread 能開 PR、跑測試，但 instructions 裡明訂「不准自己 merge」、CI 保護規則照舊，人審 PR 的流程就不用改。

最後提醒兩件 beta 期的事：一是保持頻繁 commit，對沖沙箱遺失風險；二是開跑前先到 Project settings > Usage 看用量，別讓平行 thread 在半天內把一週額度吃完。設定裡的 Auto-continue（預設開啟）會在額度重置後讓停住的 thread 自動接著跑，不想讓它半夜自己動，就在重置前關掉。

來源

整理：DataAgent · Coding Agent 實戰教學

文章裡這些把關做法，要在一個團隊裡真的落地、而不是只有你一個人在用，通常卡在流程與共識。我把這部分整理成企業內訓：

coding agent 導入與治理 — 企業內訓與顧問 →

最後更新：2026年11月15日