【2026 最新】Claude Code Projects 教學：一個 Coordinator 安全帶 3 條 Threads

你把三件工作一起丟給 AI，最怕的不是它慢，而是三個工作者同時改到同一份檔案、各自記住不同規則，最後還得由你收拾。2026 年 9 月 17 日公開的 Claude Code Projects，正是 Anthropic 對這個問題的新介面：一段 Coordinator 主對話負責分工，多條雲端 thread 各自在隔離分支執行。

但「能同時開三條 thread」不等於「三倍快」，隔離分支也不等於不會衝突。這篇專為已經會用 Git、但第一次操作多 Agent 工作流的讀者寫。我們用可丟棄的 Exercism fork，從零設計一個三工班驗收實驗：怎麼劃 ownership、怎麼中途改方向、怎麼修正舊記憶、怎麼故意製造衝突，以及什麼時候該退回單一 Agent。

本文依 2026 年 9 月 19 日的官方 Projects 文件設計操作；這是一份可重現的 acceptance lab，不是 AlphaLab 已取得公測資格後跑出的效能評測，也不會宣稱有官方未公布的品質或省時幅度。

先說結論：Claude Code Projects 是總管、工班與施工日誌

Claude Code Projects ＝ 1 位總管（Coordinator）＋多條隔離工班（threads）＋1 本共享施工日誌（Project memory）。

總管負責拆工作；每條 thread 仍要有清楚邊界與驗收命令

Coordinator 是 Project 的主對話，會理解目標、建議分工、把延續工作送回既有 thread，並彙整回報。每條 thread 則是完整的 Claude Code cloud session：有自己的 context、雲端 repo copy、Git 分支與對話；工作需要時可以開 PR。它們不共用 working tree，也不會即時共享完整思考過程。

真正的安全帶不是「多開幾條」，而是讓每條 thread 都有唯一工作區、同一個 Definition of Done（完成定義）、可複製的驗收命令，以及遇到越界時必須停下的規則。如果你還不熟多 Agent 的角色分工，可先看Claude Code Subagents Team 教學；若想理解 session 之間如何交接，再補跨 Session 協作。

開始前：先確認你真的在新版公測範圍

截至 2026 年 9 月 19 日，新版 Projects 是逐步開放給部分 Pro／Max 使用者的 public beta；Team／Enterprise 與有舊版 Projects 的部分帳號仍要等待。入口在 claude.ai/code → Projects → New project，桌面版 Code 分頁與行動 App 也可能看得到。若你的帳號沒有入口，不要把一般 CLI 的 --cloud 或 --teleport 當成替代：官方文件目前把 Project threads 定義為雲端 session，本機 session 不能加入 Project。

程式碼分支與 PR 工作目前以 GitHub.com repo 為主，需要 push 權限與 Claude GitHub App；GitHub Enterprise Server、GitLab、Bitbucket 尚不在官方列出的支援範圍。Project 可以沒有 repo 來處理一般資料與檔案，但本篇的 branch／PR 實驗一定要有 GitHub repo。這也和Cowork、Cloud 與 Local Projects 的差異不同，別只憑「Project」三個字判斷執行位置。

實驗材料：用三個互不重疊的 Python 練習

先 fork Exercism 官方 Python repo 到自己的 GitHub 帳號，禁止對上游送 PR。這個 repo 的練習預設保留未完成函式，剛好能讓三條 thread 各自完成一個小任務：

• Thread A：只負責 exercises/practice/two-fer/**。
• Thread B：只負責 exercises/practice/isogram/**。
• Thread C：只負責 exercises/practice/pangram/**。

我們在 2026 年 9 月 19 日以乾淨 clone 驗證過下列三個命令能正確找到測試；因初始實作是 stub，所以基線會失敗，完成後才應全部通過：

cd exercises/practice/two-fer
python3 -m unittest -v two_fer_test.py

cd ../isogram
python3 -m unittest -v isogram_test.py

cd ../pangram
python3 -m unittest -v pangram_test.py

這三個目錄沒有交集，適合先驗證正常並行；之後再用一個可刪除的 lab-status.md 故意練衝突。不要一開始就拿 production repo、部署金鑰或客戶資料試。

Claude Code Projects Step 1：建立 Project 與雲端環境

1. 進入 claude.ai/code → Projects → New project，名稱填 Exercism 3-thread lab，Goal 填「以三條隔離 thread 完成 three exercises，最後人工驗收」。
2. 在 Context 加入你 fork 的 repo；base branch 使用 fork 的預設分支。
3. 到 Project settings → Environment 確認 repo 與 cloud environment；本實驗只需 Python 標準函式庫，不加入 API key。
4. 到 Project settings → Memory → Project instructions 貼上下一節的 Coordinator brief。
5. 到 Project settings → Usage 記下啟動前基線；之後每完成一輪再看各 thread 與 Coordinator 的用量。

官方文件提醒：本機 ~/.claude、只裝在本機的 MCP、skills、工具、VPN 與未提交檔案不會自動搬進雲端。若 repo 需要 setup script 或套件，先在雲端環境明確設定，不要假設「我電腦跑得動」等於 thread 也跑得動。

Step 2：貼上 Coordinator brief，先寫停止條件

把下面文字放進 Project instructions。它不是硬權限沙盒，而是讓 Coordinator 與新 threads 共用的操作契約；真正驗收仍要看 diff、測試與 PR。

目標：
在我的 Exercism fork 完成 two-fer、isogram、pangram，
每項工作各用一條 thread、一個分支、一個 draft PR。

Definition of Done：
1. 只修改該 thread 擁有的 exercise 目錄。
2. 使用 Python 3 標準函式庫，不加依賴。
3. 執行該目錄 *_test.py，完整通過才可回報完成。
4. PR 說明列出修改檔案、測試命令、結果與未解風險。
5. 不合併 PR；由人類最後 review。

禁止：
- 不修改 repo 根目錄、CI、其他 exercise 或 generated files。
- 不使用 secret、不對 Exercism 上游送 PR。
- 若測試要求跨 ownership 修改，立刻停止並回報，不自行擴張範圍。

協作：
- 先提出三條 threads 與各自 ownership，等我確認後才啟動。
- 每條 thread 完成後 commit 並 push WIP，避免 sandbox 重建時遺失。
- 若兩條 thread 需要同一檔案，先回 Coordinator 重新排程。

特別注意「最多同時三條」只能當偏好，不是官方硬併發上限。你要的控制點是：Coordinator 先列出建議、你看過 ownership，才按啟動箭頭。這和自行打造Agent Workspace的概念相同：共享目標不等於共享寫入範圍。

Step 3：啟動三條 threads，逐條驗收

在 Coordinator 對話輸入：「依 instructions 提出 A／B／C 三條 thread；先不要啟動，請列出每條的 owned path、驗收命令、預計 PR。」確認沒有重疊後，再啟動三條。不要只看 Coordinator 的「完成」摘要；逐一打開 thread 與 draft PR，檢查：

• Scope：git diff --name-only 是否只落在 owned path。
• Test：PR 是否附上精確命令與完整通過結果。
• Change：實作是否解決題目，而不是改測試讓它變綠。
• Handoff：分支、commit、PR 與殘留風險是否清楚。

Coordinator 能看到 thread 的狀態與回報，但不是每一次工具呼叫的即時監控畫面。權限或確認提示如果卡在某條 thread，直接進那條 thread 回答；只在主對話說「繼續」不保證會送到正確工作者。

Step 4：故意做四次故障演練

演練 A｜中途改方向：訊息要送進正確 thread

讓 isogram thread 開始後，直接打開該 thread，補充：「忽略空白與連字號時不要加入正規表示式依賴；先說明目前改到哪，再調整。」驗收它是否保留既有成果、更新計畫並重跑同一組測試。這是在測 steer，不是在測 Coordinator 猜不猜得到你要找誰。

演練 B｜修正 stale memory：同時修當下與未來

先故意在 Project memory 寫「測試用 pytest」，再更正為「本實驗使用標準函式庫 unittest，不新增套件」。要求記住修正，並到 Project settings → Memory 確認。接著建立一條全新檢查 thread，問它應跑什麼命令。設定變更只保證影響新 threads，不會回頭改寫正在跑的 thread；舊 thread 也要直接通知。

演練 C｜branch overlap：隔離不會消滅 Git 衝突

只在可丟棄 fork 裡建立 lab-status.md。暫時允許 A、B 兩條 thread 修改同一行並各自開 PR；先合併 A，再要求 B rebase／resolve。預期結果不是「零衝突」，而是 B 能指出衝突、保留兩邊意圖、重跑驗收並讓人類 review。練完刪掉該檔案與測試分支。

演練 D｜handoff：沙盒失效前留下可恢復狀態

要求進行中的 thread 在小里程碑 commit 並 push WIP，再回報下一步。如果雲端 sandbox 暫停後無法恢復，新的 clone 可能不含未 commit 工作；可恢復的交接點才是長任務的保險。

用量煞車：三條 thread 不是免費平行運算

Projects 與一般 Claude／Claude Code 共用 plan limits；每條 thread 都是完整 cloud session，Coordinator 與 PR watchers 也會計入用量。並行越多，通常消耗越快，但沒有可信的固定倍數。請在 Project settings → Usage 看各 thread 與模型的用量，而不是靠感覺。

本文建議設三層煞車：第一層，每條 thread 只有一個小交付；第二層，第一個 PR 沒通過人工 review 前不擴張新工作；第三層，用量或需求不確定時，對單條工作按 Stop／Esc，要停整個 Project 則用 Pause，再由人決定是否只留一條主線。一般由你啟動的 Project thread 碰到五小時或 weekly plan limit，官方文件指出會自行重試並在重置後繼續；由 routine 啟動的 thread 則不會等待。若你不想讓它用到下一個額度視窗，就要明確停止。想從根本減少上下文浪費，可搭配Claude 省 token 方法。

Secret 與網路邊界：Cloud 不等於你的本機

普通 Environment variables 會被複製進 VM，指令與 Claude 都可能讀到，所以不要拿它當安全 secret store。Pro／Max 提供的 API credentials 由 VM 外的 proxy 在符合 host 規則時附加，適合需要外部 API 的情境；本實驗完全不需要。網路也採最小權限：能用 Trusted／Custom 就不要開 Full，connectors 與 credential hosts 另有通道，None 也不代表物理 air-gap。

最簡單的 cloud／local 邊界是：只把可公開的練習 repo 與必要設定放進 Project；公司內網、客戶資料、瀏覽器 session、本機 SSH key 與 production .env 一律不帶入。若任務離不開這些資源，就先停下來評估，而不是為了讓 thread 跑通而擴大權限。

六個常見坑

1. 把三條當硬上限：自然語言只形成偏好，不能取代你逐條確認與停止。
2. 把 ownership 當權限：它是協作規則；每次仍要看 git diff --name-only。
3. 只修當前對話：長期規則要同步更新 Project memory，新舊 threads 分開通知。
4. 認為不同分支不會撞：改同一區域照樣會發生一般 Git merge conflict。
5. 把環境變數當保險箱：普通 env 可讀；不需要的 secret 不要配置。
6. 只看完成摘要：以 diff、測試、commit 與 PR 為準，人類保留最後合併權。

Claude Code Projects FAQ

1. 我一定要同時開三條 threads 嗎？

不用。三條只是這次實驗的可讀規模。任務彼此依賴、ownership 不清楚或用量吃緊時，一條通常更容易驗收。

2. Coordinator 會自動避免檔案衝突嗎？

不保證。它可協助分工與安排順序；不同 threads 若改到同一區域，仍要走 Git rebase、resolve、test、review。

3. 我在 Project instructions 寫「最多三條」就是硬限制嗎？

不是。官方把這類提示描述為偏好。你仍要在啟動前確認建議清單，必要時 Stop 或 Pause。

4. Project memory 等於所有 threads 共用完整 context 嗎？

不等於。新 thread 會讀 Project instructions 與記憶索引，再按需開檔；它不會取得其他 thread 的完整上下文或 working tree。

5. 改設定會立刻套用到正在跑的 thread 嗎？

不會自動回填。官方文件說設定變更影響新 threads；正在跑的 thread 要直接傳訊修正。

6. 可以把 Project thread 拉回本機 CLI 接手嗎？

截至 2026 年 9 月 19 日，官方 Projects 文件不支援。不要把一般 cloud session 的 teleport 流程套到 Project；本地執行仍是發布文預告的後續方向。

7. 普通 environment variable 適合放 API key 嗎？

不適合。它會進入 VM 且可被指令讀取。需要外部 API 時評估 API credentials 與最小 host allowlist；不用就不要放。

8. Projects 會讓開發變快三倍嗎？

沒有足夠證據這樣說。三條並行只代表三個完整 session 可同時工作；實際速度受拆分品質、衝突、review、模型與用量限制影響。先量你的 lead time、重工與衝突，再談效益。

給新手的七個重點

• 先切不重疊 ownership，再啟動 threads。
• 每條工作都要有完成定義與精確驗收命令。
• 中途改向要進正確 thread，不只對 Coordinator 喊話。
• 錯誤規則要同時修當前工作與 Project memory。
• 隔離 branch 仍可能 merge conflict。
• 平行 thread 會加速用量；必要時退回單一主線。
• 人類最後用 diff、test、PR 決定是否合併。