Claude Projects 大重構：資料夾換成一場對話，雲端執行緒並行提 PR

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

2026 年 9 月 17 日，Anthropic 在官方部落格發布〈Projects redesigned: from folder to conversation〉，把 Claude Projects 這個功能整個翻掉。過去的專案是一個資料夾：把參考文件丟進知識庫、貼上自訂指令，然後自己開一個又一個彼此不知道對方存在的對話。現在的專案是一場持續進行的對話，你交代目標，Claude 劃定範圍、指派工作、協調並行的雲端執行緒、審查產出，再把成品組起來。公告在台北時間 18 日凌晨上線，官方說明文件與說明中心條目同日翻新。

官方給這個新角色一個好記的帶法：像交代幕僚長那樣交代專案裡的 Claude。不過先弄懂的不是比喻，而是執行緒的本體。官方文件的定義只有一句：每一條 thread 都是一個完整的 Claude Code 雲端工作階段（cloud session），有自己的上下文視窗、自己的分支、自己的一份程式碼副本。並行調度的單位不是聊天分身，是 Anthropic 伺服器上真正各開一個工程環境。這次重構的代價與限制，全部從這個定義長出來。

Pin

舊版是收納盒，新版是工頭

先講被換掉的東西。舊版 Projects 的核心是把對話和參考文件分組，官方文件回頭描述它時只用了一句話：沒有執行緒、沒有協調器。你把 API 文件、規範、需求丟進知識庫，Claude 在每個對話裡被動讀取；兩個對話之間的決策不互通，你得自己當搬運工。這個版本也有它的體質：說明中心載明免費帳號最多建 5 個專案，付費方案的知識庫在接近上下文上限時會自動啟用檢索增強，容量最多約 10 倍。

新版把單位換掉了。一個專案就是一場對話，工作以執行緒的形式從對話裡長出來，而且闔上筆電之後繼續跑。說明中心現在把新舊兩版並列在同一篇條目裡，新版的描述是：你隨口交代、Claude 把工作拆成平行的雲端執行緒、告訴你哪些做完哪些在等你。已經存在的舊專案不受影響，照常運作；官方的說法是等推播擴及一般對話與 Cowork 時才會把它們升級。急著搬遷沒有必要。

Pin

一場對話怎麼指揮一群雲端工程環境

拆開看有兩層。專案對話裡的 Claude 是協調者：它收你的訊息、決定什麼變成一條執行緒、追蹤自己開過的每一條。執行緒是幹活的人：每條都是獨立的雲端工作階段，在自己的分支上改程式碼，工作需要時開拉取請求（Pull Request），做完回報。當某條執行緒的任務太大，它內部還能再拆出子代理、迴圈與工作流。建立第一個專案時它可能主動出招：如果專案接了可讀的 repo，會先開一條不動程式碼的探索執行緒看看 repo，提議下一步。

官方公告給了兩個例子，都可以照著讀一遍。例子一是把結帳流程的 p75 延遲設為目標，交代 Claude 對各個端點做效能分析、測試優化、在並行執行緒裡各自提 PR。另一個例子是把 API、Web、Mobile 三個 repo 接進同一個專案，目標是退役某個舊版端點：Claude 為每個 repo 開一條執行緒，遷移呼叫端、跑測試、提 PR，最後告訴你哪幾個要先合併。合併順序的指引是例子裡的行為描述，不是一個叫依賴排序的獨立功能。

兩條執行緒改到同一段程式碼時怎麼辦？公告原文：重疊就當成合併衝突處理，跟任何其他 PR 一樣。沒有智慧合併的黑箱。執行緒開了 PR 之後會掛著自動修復盯後續：CI 失敗就推修正、收到審查意見就處理，並且在對話卡片上亮出下一步按鈕，讓你自己決定要不要叫它解衝突或合併。狀態全部攤在 Overview 面板：待審查、等你回覆、執行中、待落地、閒置、已結案六種，閒置一週的自動結案。檔案與產出則收在 Library 分頁，PR 與排程各有自己的分頁。

專案有兩種起手式。從零建立時只填名稱就行，目標與 repo 之後再補；第一個專案建立起來時，Claude 還會自己先開口，貼出從你近期雲端工作階段整理出來的設定建議，像該接哪些 repo、該建哪些排程，讓你勾選送出。另一種是把已經在跑的雲端工作階段直接轉成專案，Claude 讀完該場對話後提議專案該長什麼樣子，原對話保留不動。這條路對已經習慣單場工作階段的人很實際：先用舊方式開工，做到一半發現工作性質對了，再升級成專案。

怎麼指揮也有官方劇本。你可以在對話裡直接規定節奏，例如先提議執行緒等我點頭再開、一次最多跑兩條、回報短一點、沒看到計畫前不要提 PR；Claude 會把這些偏好記進專案記憶，之後的執行緒照著走。這類指示 Claude 會記住並遵守，但要每條執行緒從第一天就嚴格套用的規則，寫進專案指令才算數。

還有一個容易漏掉的工程事實：執行緒在雲端，你本機裝的東西帶不過去。官方文件明講，執行緒拿不到你機器上安裝的技能、MCP 伺服器與外掛；要讓它們可用，技能要嘛 commit 進專案接的 repo、要嘛在 claude.ai 帳號層級啟用；MCP 工具則走 claude.ai 帳號上的連接器，每條執行緒都能用，不必逐專案設定。

首波只開給 Pro 與 Max 的 Claude Code 雲端用戶

首波資格有三個條件：Claude Pro 或 Max 訂閱、使用 Claude Code 的雲端工作階段、而且在一般對話與 Cowork 裡沒有既有專案的帳號。判斷方式不用猜，看介面就好：claude.ai/code 或桌面 App 的 Code 分頁側邊欄沒有出現 Projects，就是還沒輪到你，可以到官方表單排候補。官方預告未來一週會開放給同方案的更多 Claude Code 用戶，之後才輪到整個 Claude 以及 Team 與 Enterprise 方案。手機 App 也算正式入口，iOS 與 Android 都能建立與使用專案。

Pin

排除清單同樣具體。終端機 CLI 不在此列，Amazon Bedrock、Google 的 Agent Platform、Microsoft Foundry 也都不在。程式碼必須放在 github.com：GitHub Enterprise Server、GitLab、Bitbucket 都不行，而且要安裝 Claude GitHub App、連結的帳號要有 push 權限，組織強制 SSO 的還要先授權過。官方公布的資格條件只看方案與帳號狀態，沒有地區欄位，台灣的 Pro 與 Max 訂閱者照同一套條件排隊。至於把執行緒搬回自己機器、放在公司防火牆後面跑，公告只說很快就會有，沒給時間。

額度怎麼算，是官方文件寫得最多的段落

並行的代價直接反映在用量。專案吃的是與其他 Claude Code 工作階段同一桶方案限額，但好幾條執行緒同時開工，官方對 Pro 用戶的提醒是不設防的：跑專案的日子要預期更早碰到限額。額度之外的計費也只有一個開口，帳號自己開啟額外用量點數才可能超出方案，執行緒不能替你開。

預設值直接記住：新專案全部跑 Opus，執行緒用高努力等級、協調對話用低努力等級。要省額度，模型與努力等級可以分開調，對話與執行緒各自設定。硬性上限只有一條，所有專案合計每天 200 條新執行緒；你口頭交代一次最多跑幾條，官方明說那是偏好而非上限，Claude 會尊重但不保證。另兩個容易忽略的計費行為：閒置超過一小時的執行緒被喚醒時，會先把整段對話重讀一次才動工；盯著 PR 的執行緒平時睡著，CI 失敗或審查意見進來就會醒來繼續耗額度，不想要可以叫它收工。

撞到限額的行為則對非同步工作很友善。執行緒碰到方案的五小時或每週限額時不會死掉，而是顯示服務忙碌、自己持續重試，限額一重置就接著跑，你前一晚交辦的工作會自動用掉下一個額度時段，不需要你傳訊息催它；唯一例外是由排程帶起的執行緒，它會停下並回報限額錯誤，限額重置後要你再傳一則訊息才會繼續。不想讓它吃掉下一個時段，就在執行緒裡按停，或把整個專案暫停。反過來說，暫停鍵的語意是全部凍結：執行中的執行緒、對話、排程一起停，專案不收任何訊息，恢復之前什麼都不動。閒置的專案本身零消耗：沒有執行中的執行緒、沒有盯著的 PR、沒有新訊息的專案，放著就只是放著。

不能分享的專案，與可能丟掉的工作

最實際的一條關於資料安全。執行緒的沙盒在回合之間暫停，下次繼續時恢復；如果沙盒恢復失敗，執行緒會從全新的副本重新開始，沒有 commit 的變更可能就沒了。官方的建議很工程師：長任務直接交代它定期 commit 並 push 工作進度。其次是協作邊界，專案屬於單一用戶：不能分享給另一個人，執行緒不能搬到別的專案，beta 期間也沒有組織層級的控制項；官方只承諾 Team 與 Enterprise 之後開放，屆時有哪些協作機能還沒有說。

治理面有個多 repo 團隊要留意的缺口。單一 repo 的專案會套用那個 repo 裡的權限規則與 hooks；專案接了多個 repo 時，各 repo 的這些設定一律不套用，規則要改寫進專案指令。專案指令是每條新執行緒（連同協調對話裡的 Claude）都會收到的一份前置簡報，上限 16,000 字元，官方給的範本可以直接照抄結構：先一句話講專案目的，然後規定分支從哪裡開、PR 怎麼命名、收工前要跑哪些測試並貼結果、缺什麼資源就在第一句話講清楚然後停手不要自己亂猜替代品、以及哪些動作要先問過你。這幾條剛好就是並行工作最容易翻車的地方。

記憶也有三份要分清楚：Claude 在專案裡自己維護的專案記憶（以 MEMORY.md 索引為入口）、你本機 Claude Code 的自動記憶、以及各 repo 的 CLAUDE.md，三者互相獨立，放錯位置的規則只有特定範圍讀得到。你講過的規則要跨執行緒生效，就開口叫它記住；你修正某條執行緒的錯誤時順便說一句把這個教訓記下來，之後的新執行緒就帶著出門。上下文的管理同樣不必手工：執行緒滿了會自動壓縮，協調對話只靠近期訊息、近期執行緒與專案記憶運作，專案可以一直跑下去；官方唯一的提醒是，絕對不能掉的資訊要放進專案記憶，不要賭它還在對話裡。

一週前 Cursor 才做過同一件事

把時間軸拉遠一點看，這是 9 月第二家把專案層重做成常駐協調者的公司。Cursor 在 9 月 10 日推出 Projects，把一次任務一個對話換成一個專案一位常駐協調代理，當時的觀察是工作單位的換位。兩家相隔七天先後走到同構的架構：上層一個不親自寫程式碼的協調者，下層一群各自開分支提 PR 的執行者。差別在規格書的寫法：Anthropic 把每一條執行緒的定義寫到基礎設施層，就是一個雲端工作階段，連沙盒暫停與恢復的行為都載明；這讓它的額度結構與工程邊界比產品話術更該讀。

還沒說死的事，發布當下都沒有答案：本機與內部網路執行只給了很快登場四個字、Team 與 Enterprise 沒有時程、舊專案的升級時程未定、專案也沒有獨立於方案之外的計價。首波資格正在逐步放寬，側邊欄依然是唯一可靠的訊號。在排到之前，想先理解這條產品線的走向，可以回頭看 Claude 前一天才把 Cowork 併進對話的整線收束，以及 OpenAI 九月初把代理調度做成付費基礎設施的Agents API：三份文件對照著讀，會發現雲端代理的工作單位、額度與治理邊界，已經變成這一波產品設計真正較勁的地方。