010. 導言｜Projects 不是資料夾，是一個會分派工作的主對話
Claude 這支官方短片〈Getting started with Claude Code Projects〉只有四分半，但它其實把 Claude Code 接下來很重要的一個工作介面講清楚了：Projects 不是把檔案整理到某個資料夾，也不是只是多開幾個 Claude Code session；它比較像一個長期存在的「專案協調者」。
你把一個大目標丟進主對話，Claude 會判斷哪些事情可以拆開，替每個任務開出一條 thread。每條 thread 都是一個獨立 Claude Code session，可以在雲端自己的 branch 上工作；當它產出具體修改時，可以開 PR，繼續看 CI、處理 review comment，最後再把進度回報到主對話。
這個設計的重點不是「模型更聰明，所以你可以少想一點」。比較準確的說法是：當工作本來就會跨多個 session、跨 repo、跨好幾天，Projects 把原本散落在你腦中的任務分派、背景同步、PR 追蹤和例行檢查，收斂到一個地方。
021. 適用場景｜當一個 session 開始不夠用
影片一開頭用的例子很直接：你不是自己去建立 sub-agents、管理多個 sessions 或 worktrees，而是把大型目標交給 Claude，讓它拆成小任務並行處理。
這種模式適合的不是單點修改。像「修一個 flaky test」或「改一個 button 樣式」，單一 Claude Code session 就夠了。Projects 真正發揮價值的地方，是任務天然有多條線：把 app 從 deprecated package 遷走、同時更新 API / web / mobile endpoint、追查一串網站效能問題，或是把一批支援 ticket 變成分析報告。
影片示範的案例是網站效能：使用者先分享 metrics 與 user feedback，請 Claude 探索 codebase、提出改善方向；等雙方同意要做什麼後，Claude 再為每個任務開 thread。換句話說，主對話不只是聊天窗口，它是一個 dispatch layer。你用它設定目標、確認方向、看總進度；細節工作則被分派到 worker threads 裡。
這裡有一個值得記住的產品判斷：Projects 的抽象不是「一次跑很多模型」，而是「讓同一個目標下的多條執行線共享專案脈絡」。如果你只是想平行叫幾個 agent 做彼此無關的事，Projects 不是唯一選項；但如果每條工作線最後都要回到同一個產品目標，它就開始有意義。
032. Threads 與 PR｜每條工作線都有自己的上下文與分支
影片對 thread 的定義很清楚：thread 是自己的 session，在雲端自己的 branch 上跑。這讓並行不只是 UI 上的清單，而是工作區隔上的並行。每條 thread 有自己的上下文、自己的分支、自己的任務邊界，不會在同一個 working tree 裡互相踩到。
使用者仍然可以介入。你可以點進 thread 看 Claude 正在做什麼，直接在 thread 裡補充方向，或把它停掉。主對話也會顯示哪些 thread 正在等你，以及 PR 的下一步狀態。
當 thread 有具體修改，例如 bug fix，它可以自己開 pull request；之後還會持續 watch PR。如果 CI 失敗，它可以推修正；如果 reviewer 留意見，它可以回應或調整。影片特別提到，可以到 Overview 裡的 Pull requests tab 看所有 PR 和狀態；準備合併時，也可以直接叫 Claude 處理。
這裡的工作流其實接近一個小型工程團隊：主對話像 PM / tech lead，threads 像各自拿 ticket 的工程師，PR tab 像 review board。差別是這個團隊不是獨立思考的真人，而是共享同一個專案目標與記憶的多個 Claude Code sessions。
編輯上要補一句保守提醒：這種 workflow 很適合加速「可分割」的工作，但不代表所有決策都該自動化。架構方向、產品權衡、資料遷移風險、外部服務權限，仍然需要人類在主對話或 thread 裡把邊界講清楚。
043. Library 與 Artifacts｜讓專案有共享記憶，而不是每次重講
Projects 的另一個關鍵部件是 Library。影片把 Library 說成專案的 shared folder：Claude 產出的 artifacts 會放在這裡，使用者加入的檔案也會放在這裡，例如 mockups、design spec、效能報告。
在示範中，Claude 做完效能改善後，使用者要求它產出一份 artifact，整理修改前後的 performance metrics，方便分享給團隊。這份 artifact 放進 Library 後，後續 thread 都能讀到。下一次再處理效能問題，Claude 不需要從零開始理解團隊之前怎麼衡量、做過哪些改動、報告長什麼樣子。
這是 Projects 比「多開幾個 session」更進一步的地方。多 session 的問題不是不能並行，而是背景同步很累：你要一直複製貼上需求、貼 repo 規則、貼設計稿、貼前一次討論結果。Library 把這些變成專案層的資源，讓新的 thread 自然繼承可用脈絡。
但 Library 也不是魔法記憶。影片提到 threads share memory，使用者可以告訴 Claude 記住未來 threads 都要遵守的偏好，也可以到 project settings 編輯 memory。這代表你仍然需要治理它：什麼是長期偏好，什麼只是一次性任務背景；什麼該進 Library，什麼該進 memory；什麼過期後要替換。Projects 解決的是存放與傳遞，不會自動替你判斷所有資訊是否仍然正確。
054. Routines｜把一次性修復接成持續檢查
影片後半段把效能案例往前推一步：既然已經修過一輪 performance issues，下一步不是等下次壞掉，而是把 Claude 接到 monitoring service，讓它每天檢查 real user metrics。有 regression 時，Claude 開一條新 thread 追查，等你回來時就在 project 裡等你。
這段其實是整支影片最有意思的地方，因為它把 agent 從「被叫來修東西」推向「專案裡的例行檢查者」。Routine 不只是 reminder；在 Projects 的語境下，它可以連到同一個 project context、開出新的 investigation thread、把產出留在同一個地方。
對團隊來說，這種能力適合放在幾類事情上：效能退化、錯誤率異常、文件漂移、依賴升級、測試穩定性、客服回饋分類。它們的共通點是：需要定期看、需要上下文、發現問題後往往要接到後續調查。
反過來說，Routine 不適合承擔過度模糊或高風險的任務。像「每天看看產品哪裡可以改」太寬；「每週自動改生產環境設定」太危險。比較好的設計是把 Routine 寫成清楚的檢查條件和回報方式：看哪個 service、用哪個 metric、什麼門檻算 regression、發現後先開 thread 分析還是直接開 PR。
065. 三個使用建議｜省用量、定規則、整理記憶
影片最後給了三個實用提醒。
第一，Projects 會更快吃掉 plan limits。原因很簡單：每條 thread 都是一個完整 Claude Code session，而一個 project 可以同時跑好幾條。影片建議到 project settings 裡調整 model 和 effort level。尤其 coordinator 多半只是 routing work，放在 low effort 通常就夠；真正困難的工作在 threads 裡，再依任務大小切換模型與 effort。
第二，你可以直接告訴 Claude 想怎麼工作。例如一次最多跑幾條 threads、多久更新一次、開始前是否要先展示 plan。這些規則很重要，因為 Projects 的價值不在於「越自動越好」，而在於把自動化調到符合你的信任邊界。你希望它先問、先規劃、先開 PR、還是可以直接修 CI，最好一開始就講清楚。
第三，threads share memory。你可以讓 Claude 記住偏好，讓後續 threads 都吃到同一套脈絡。這裡的重點不是把 memory 當垃圾桶，而是把它當專案操作手冊的一部分：命名規則、測試策略、review 偏好、常見禁忌、發布流程，都比臨時閒聊更適合留下。
總結來說，Claude Code Projects 的核心不是「又多一個功能頁」。它把 Claude Code 從單次 session 往「持續協調的專案系統」推了一步。當你的目標大到需要多個分支、多個 PR、多個 artifact、多次檢查，Projects 讓你不必自己維護那張看不見的任務地圖。
真正的使用心法也很樸素：給 Claude 一個明確目標，讓它拆 threads；用 Library 保存共享脈絡；用 Routine 把一次性修復變成持續檢查；最後，用清楚的 project rules 控制成本與風險。