Claude Code Projects 該不該開：目標會長出很多任務才值得，雲端 thread 看不到你的 hooks

手上有一批服務要全部升到新的 lint 設定，會拖好幾週。每個服務開一條雲端 session，每一條的第一句話都一樣：從 main 開分支、一個 PR 對一件事、別直接 merge。講到第七次的時候，你會不會想問：這串話為什麼不能只寫一次？

Claude Code 的 Projects 就是衝著這個問題來的。先把邊界講清楚：這篇我讀的是官方的 Projects 文件和並行方式比較頁，2026-10-28 讀的，沒有實際開過專案，所以下面每一個行為都是「文件這樣寫」，不是「我看到它這樣跑」。上面那個 lint 場景也是我假設的，官方範例裡有一句類似的任務（Bring every service up to the new lint config），我只是拿來當處境。

先問：這個目標活得過一個 session 嗎

官方的判準只有一句：專案值得開的條件，是工作的目標比一個 session 活得久，而且會一直長出新任務。它列的情境有四種：同一個目標橫跨很多 repo、一塊你會持續餵東西進去的領域、比一個 session 大的建置或遷移，以及不是寫程式的工作。

結構很像工頭和工班。專案裡有一條長時間存在的對話，Claude 在裡面當協調者，決定哪些事變成 thread、記住每條 thread 的狀態。它看得到 thread 回報的結果，看不到每一步細節。thread 才是工人，各自有獨立的 context window，做完一件事回報，需要的時候在自己的 branch 上開 PR。thread 通常是雲端 session，所以闔上筆電它還會繼續跑。

反過來，官方自己列了四種「別開專案」的情況，我覺得這是整頁最有用的一段。一個 session 就能做完的單一任務，直接開雲端 session 就好，我之前寫過雲端沙箱那篇。每個任務都得用你自己的機器，用本機 session 或 Agent View。沒有對話、只是定時重複的單一工作，用 cloud scheduled task。多人要在 Slack channel 裡一起下指令，那是 Claude Tag 的事，專案只屬於你一個人。

官方的並行方式比較頁（agents）給 Projects 的適用描述是：工作橫跨好幾天或好幾週、機器關了也要繼續跑、你寧可描述一次也不想逐條派工追蹤。這三個條件湊不齊兩個，我會當它不適用。

進門前的幾道關

資格比想像的窄。Projects 目前是 Pro 與 Max 的 public beta，逐步開放，Team 和 Enterprise 方案還沒有。入口在 claude.ai/code、桌面 app 的 Code 分頁，或 iOS／Android 的 Claude app，不在終端機 CLI、VS Code 擴充和 JetBrains 外掛裡，Bedrock、Google Cloud 的 Agent Platform、Microsoft Foundry 也不支援。側邊欄看不到的話，先到 More 底下找，再沒有就是還沒輪到你的帳號，可以排候補。

程式碼要放在 github.com，GitHub Enterprise Server、GitLab、Bitbucket 都不行。你得有 push 權限，還要裝 Claude GitHub App。

這裡有一個很容易踩的坑，官方特別點名：你如果之前用 /web-setup 連過 GitHub，那個 token 讓你的其他雲端 session 讀得到 repo，但不夠專案的雲端 thread 用，thread 要的是 Claude GitHub App。組織的 repo 只有 organization owner 能完成安裝，不是 owner 的話 GitHub 會寄安裝請求給他。組織有 SAML SSO 的話，還要重新連 GitHub 並授權 Claude app，否則私有 repo 不會出現在 New project 對話框裡。

搬進雲端前，先對這張清單

整篇我覺得最該先看的是這一段，因為它最可能讓人白做工。

雲端 thread 起手會帶四樣東西：專案的 repo 與檔案加上 instructions 和 memory、各 repo 的 CLAUDE.md、你 claude.ai 帳號上的 connectors，還有一個 cloud environment。注意第二項的括號：只有 CLAUDE.md，不含 repo 裡的 skills、.claude/settings.json 和 .mcp.json。

細項照文件的表格是這樣：根目錄的 CLAUDE.md、.claude/CLAUDE.md、.claude/rules/ 會載入，子目錄的 CLAUDE.md 和 path-specific rules 不會。.claude/skills/、agents、commands 不載入。.mcp.json 不載入。.claude/settings.json 裡的 plugins、permission rules、hooks、env 也都不套用。

文件給的替代路徑各走各的：skills 要在 claude.ai 帳號上啟用，plugins 加在 Project settings 的 Plugins，MCP 改用 claude.ai 的 connectors（專案對話本身沒有 connectors），要裝工具就寫 environment 的 setup script。權限提示也有一條容易誤會的規則：thread 在模型支援時跑 auto mode，需要你批准的提示出現在 thread 裡面，thread 會一直等你在那邊回答。你在專案對話裡跟 Claude 說「go ahead」，到不了那條 thread。

文件的表格直接寫了：.claude/settings.json 裡的 hooks「Not run」，permission rules「Not applied」。所以如果你本機的底線是靠 repo 裡 settings 的 hook 或 permission deny 在執法，搬到雲端 thread 就是沒人守。要用你的 hooks，文件的答案是把那條 thread 跑在自己的電腦上。

那底線該放哪裡？官方的做法是寫進 project instructions，上限 16,000 個字元，每條新 thread 起手都會帶。下面是我從官方範例（一個壓低 API p95 延遲的專案）摘出來的幾行，原文照抄：

Branch from main and open one draft pull request per thread.
Before you call work done, run `make test` and `make lint` and paste the summary lines in your final message.
If you can't reach something you need… say exactly what's missing in your first message and stop. Don't substitute, mock, or guess.
Don't merge, force-push, or change CI configuration without asking me in the thread.

這幾行回答了開場那個問題：第七次不用再講，寫一次，每條 thread 都收到。另外分清楚放哪裡：只跟某個 repo 有關的規則，放那個 repo 的 CLAUDE.md；專案層的筆記，放 project memory。文件特別說 project memory 和你本機的 auto memory 是兩套，雖然兩邊都用 MEMORY.md 當索引。

我的立場，和會讓我改口的條件

我的立場：Projects 的賣點在「instructions 寫一次、所有 thread 共用」，不在「同時跑很多條」。官方自己的說法也是，同時跑多個 session 的功能不只一種，光是平行不是專案的用途，專案的差別是由 Claude 替你開 thread、追蹤 thread，而且每一條都從同一份 instructions 起跑。

所以我會把底線寫進 instructions，但不會只靠它。文件在這點很誠實：這類指示是 Claude 會盡量遵守的請求，不是強制設定。你要它「一次最多跑兩條」，那只是偏好，不是硬上限。靠 instructions 擋「不准 merge」「不准 force-push」，對我來說等於請人幫忙，不是上鎖。

會讓我改口的條件有兩個。一是文件改成雲端 thread 也載入 repo 的 permission rules 或 hooks，那這份清單就不是缺口了。二是我實際開專案跑過一批 thread，在寫了不准 merge 的情況下觀察到它們沒有越線，而且不是一兩次，是成批沒有。目前兩個條件都不成立，我手上只有文件。

「一次最多兩條 thread」這類話是偏好，不是上限。文件裡寫明的硬上限是跨所有專案每天 200 條新 thread；其他你對 Claude 說的數量限制，它都是盡量照做。

錢怎麼燒

新專案預設全場用 Opus，thread 跑 high effort，專案對話本身是 low effort。文件的說法是這樣最快燒你的方案額度。Project settings 的 General 裡可以分別改 Thread model、Thread effort、Coordinator model、Coordinator effort。專案和你其他的 Claude Code session 共用同一份方案上限，而且用得更快。

第一個專案有一個細節：建立完成後，只要你沒先送訊息，Claude 會自己先跑一輪，而且那一輪算你的額度，它可能開一條唯讀的探索 thread，貼上 Setup recommendations。所以官方建議的第一批流程是：先寫 instructions，再送一小塊真實工作觀察，確認 thread 的 model 和 effort，最後請 Claude 先提案要開哪些 thread、你點頭再開，一次只跑幾條。

另外兩個會偷偷花額度的地方。一是閒置的 thread 在 PR 上 CI 失敗或有 review comment 時會被喚醒，又開始用你的額度，不想要就在 thread 裡叫它停止 watch 那個 PR。二是一條閒置超過 cache 壽命（Pro 與 Max 是一小時）的 thread 被你的追問喚醒，會把整段對話重讀一遍。Project settings 的 Usage 可以按 thread 或按 model 看用量。撞到方案上限時，thread 會自己重試、等上限重置後繼續；不過由 scheduled task 啟動的 thread 不會等，那一輪直接停在 limit error。

什麼時候它反而是壞選擇

想要「東西留在雲端」的人，要留意沙箱的行為。雲端 thread 的沙箱在兩輪之間會暫停，繼續時如果沙箱救不回來，thread 會從一份全新的 clone 接著做，沒 commit 的變更可能就沒了。官方的建議是長任務請 Claude 把做到一半的東西 commit 並 push。

如果某件事非得在你的電腦上做，專案可以叫 Claude 把那一條 thread 跑在你的電腦上，走 Remote Control，電腦上的 Claude Code 要 v2.1.280 以上。代價是那條 thread 起手只帶 instructions，不帶 memory 檔，而且電腦睡著就暫停；帳號開了 Require trusted devices 的話，根本不能這樣用。這條路我只讀到文件的描述，claude remote-control 之類的操作都沒有試過。

最後是一個我覺得很實用的排錯法。一批 thread 都猜錯方向的時候，官方建議直接問 Claude：每一條開著的 thread，你交代了什麼、它假設了什麼或碰不到什麼、現在在等什麼。找到缺口以後，只在 project instructions 或 environment 補一次，再送一條 thread 試，成了才把其餘的工作重送。而 thread 在專案對話裡好一陣子沒有新訊息，文件的說法是通常還在做事，因為 Claude 不會貼出 thread 的每一步。

還有兩個限制先放進帳裡：專案只屬於你一個人，不能分享給別的使用者，beta 期間也沒有組織層級的控制；一條 thread 只屬於開它的那個專案，兩個專案不能合併。