目录

2026年9月17日，Anthropic 宣布重建了 Claude Code 里的 Projects。这个名字本身并不新鲜，claude.ai 的聊天界面一直用这个词来称呼那个把对话和参考文件装在一起的盒子。新的 Projects 沿用了这个名字，却把背后的一切都换掉了。官方博客文章的副标题本身就是完整的答案：“从文件夹到对话”。

一句话概括，变化在于分派工作这件事从你手上转到了 Claude 手上。你把需求丢进对话，Claude 把它拆成一个个“线程”（thread），线程在云端并行运行，每个线程完成后会开一个 pull request 并回报结果。合上笔记本也不会让它们停下来。

不过在动手之前，有三件事值得先确认：能用的账号仍然有限、GitHub 在实际操作中是硬性要求，以及它消耗用量上限的速度和单个会话完全不是一个量级。本文回到一手资料——Claude Code 官方文档和官方博客——来理清你能不能用，以及用起来之后会发生什么。

先说结论：Projects 的三个面

出处：Claude Code 官方文档《Let Claude coordinate ongoing work with Projects》

分派工作的是 Claude

一条对话，多个线程

写下你的需求，Claude 会按需要开出相应数量的线程，并一路替你盯着

关掉之后仍然继续

线程住在云端

它们跑在云端而不是你的机器上。你可以用手机查看情况并随时指挥

代价是什么

必须有 GitHub，额度共用一份

只支持 github.com。用量和你其他会话花的是同一个钱包

1. 不再是文件夹，而是一整条对话

新的 Projects 由两部分构成：由 Claude 担任协调者的项目对话，以及这条对话启动的一个个线程。

项目对话是一个长期运行的会话。它读取你发过去的内容，只需要一句回答时就当场回答，凡是构成“工作”的部分则切出去交给线程。它并不盯着这些线程内部发生了什么。它看到的只有线程回报上来的内容。

线程才是干活的地方。每个线程都是一个独立的云端会话，拥有自己的上下文窗口。它在自己的分支上工作，需要时开一个 pull request，完成后向对话回报。文档把线程的状态描述为排列在一个叫 Overview 的列表里，像下面这样。

Overview 里的六种状态

Ready for review

PR 已经开好，正等你评审

Waiting on you

需要你回答或批准，或者它失败了

Working

仍在运行

Landing

PR 已获批准，或正排在合并队列里

Idle

已经结束，没有在等任何东西

Resolved

已了结并归档。一周没有动静的线程会被自动移到这里

这里值得记住的一点是，并行工作并不是新东西。Claude Code 本来就有 Subagents、agent view、Agent Teams 和动态工作流。Projects 增加的不是并行能力，而是另外两件事：分派和跟踪不再由你自己做，而且合上机器之后工作不会消失。文档自己也是这么写的，明确说明“能并行运行”并不是 Projects 的目的。

2. 名字相同，却不是旧的 Projects

让人混淆的地方在于，claude.ai 的聊天界面也有“Projects”。那个是对话和文件的容器，没有线程，也没有协调者。名字完全一样很容易让人搞混，但文档把两者当作各自独立的功能。

对比项旧 Projects（聊天、Cowork）新 Projects（Claude Code）
本质是什么装着对话和参考文件的文件夹一条带协调者的对话，外加一组线程
谁在干活你打开的那条对话Claude 启动的线程（云端会话）
合上机器之后停下来继续运行
最终拿到什么对话里的一个回答分支、pull request，以及 Library 标签页里的文件
接下来会怎样暂时保持现状继续可用随着放量范围扩大，旧项目会被升级

💡 还有第三个同名的功能：终端里 Claude Code 的 claude project 命令管理的是某个工作目录的本地状态，它和本文讲的 Projects 除了名字之外毫无关系。文档特地注明这两者“互不相关”。

3. 谁能用——怎么判断有没有轮到你

截至2026年9月19日，它处于分批放量的公开测试（public beta）阶段。条件写得相当细，下面尽量照原文列出。

放量条件清单

✅ 订阅方案

仅限 Pro 和 Max。Team 和 Enterprise 暂不包含

✅ 排在最前面的人

用过云端会话，而且在聊天或 Cowork 里还没有项目的账号

✅ 去哪里找

claude.ai/code 的侧边栏，或桌面应用的 Code 标签页。手机应用也能用

❌ 哪里用不了

终端里的 CLI。通过 Amazon Bedrock、Google Cloud Agent Platform 或 Microsoft Foundry 接入的同样不行

第二条最容易被忽略。你在聊天那边积攒的旧项目越多，新 Projects 轮到你的时间就越晚。官方博客说现有项目暂时照常可用，并会随着放量范围扩大而升级。换句话说，排在前面的不是重度用户，而是一张白纸的账号。

如果侧边栏里没有，就说明还没轮到你。这种情况下可以去等候名单登记。找对地方也比听上去更要紧：它出现在 Code 那一侧，也就是 claude.ai/code 的侧边栏或桌面应用的 Code 标签页。聊天的侧边栏你翻多久都没用，在那里找到的是旧的 Projects。

4. 必须有 GitHub，多数人卡在这一步

这是实际使用中最硬的一道限制。线程能碰的代码只有 github.com 上的代码，而且那个仓库上必须装好 Claude GitHub App。文档把条件列成下面这样。

  • 代码放在 github.com 上。GitHub Enterprise Server、GitLab 和 Bitbucket 都不行
  • 已连接的 GitHub 账号对该仓库拥有推送权限
  • 该仓库上装有 Claude GitHub App。用 /web-setup 添加的令牌对其他云端会话有效，但不足以支撑项目线程
  • 组织的仓库只有组织所有者才能完成安装（其他人只能发出一条审批请求）

这意味着在自建 git 服务器或共享主机上用裸仓库干活的个人开发者，就目前而言不在支持范围内。公司 VPN 后面的 API、笔记本上的数据库、设备模拟器，以及通过 SSH 连接的生产服务器也一样：线程运行在你的机器之外，所以这些它一个都碰不到。

⚠️ 有绕开的办法，但那不是给 Projects 用的：用普通的云端会话时，可以设置 CCR_FORCE_BUNDLE=1，把非 GitHub 的仓库作为本地 bundle 传上去。不过文档写得很直白，结果没法推回那个远端。项目线程默认依赖 GitHub App，所以这条路只够让 Claude 读代码。

那不用 GitHub 的人就彻底没辙了吗？也不尽然。项目可以不带任何仓库创建。上传一叠合同或者一份工单导出，交给线程一件“把这里面最常出现的十种对接错误列出来”这样的活，再到 Library 标签页拿结果，这正是文档明确设想过的用法。你上传的文件在线程里可以从 /mnt/project-files 读到。

如果工作内容是代码，而且离不开你自己的环境，那该用的是在 agent view 里并排运行本地会话。它跑在你自己的机器上，所以 VPN、本地数据库和 SSH 都照常能用。

5. 一个线程启动时带着什么

线程并不是每次都从零开始。它带着项目交给它的上下文启动，一共有四样东西。

  • 项目的仓库和文件——每个登记过的仓库每次都会被克隆，无论任务用不用得上
  • 项目指令（project instructions）——发给每一个线程的共同说明。上限是 16,000 个字符
  • 项目记忆（project memory）——Claude 写给自己的笔记。它在启动时读 MEMORY.md 索引，需要时再打开具体的文件
  • 云端环境——允许访问哪些网络目标、环境变量、API 凭据，以及预先装好的工具

这堆行李里最容易出事的是这一条：仓库里的配置文件，会因为项目只有一个仓库还是有多个仓库而被区别对待。把文档的表格整理一下是这样。

仓库里放的东西单仓库的项目多仓库的项目
CLAUDE.md启动时读取每个仓库的都读
.claude/ 里的技能、智能体和命令读取每个仓库的都读
插件（在 .claude/settings.json 里启用）读取每个仓库的都读。冲突时项目设置优先
权限规则、钩子和 env生效哪个仓库的都不生效

原因很简单：权限、钩子和环境变量只会从线程启动所在目录的 .claude/settings.json 里读取。仓库超过一个时，线程会在克隆目录的上一层启动，于是没有任何一个仓库的设置落在会被读取的位置上。只是多加了一个仓库，就会悄无声息地把你的钩子关掉，而且没有任何提示。对于多仓库的项目，文档给出的建议是把共用规则写进项目指令，把环境变量放进云端环境。

顺便说说 MCP：线程能用的 MCP 服务器是你 claude.ai 账号上的连接器。只装在你本机的 MCP 服务器永远够不着。而且项目对话本身完全没有连接器，所以需要连接器的工作必须交给线程，而不能在对话里直接问。

6. 它多消耗多少 token

这是多数人在打开它之前最想知道的问题。文档说得毫不含糊：项目消耗额度的速度比单个会话快，尤其是 Pro 用户，在运行项目的那些天里应该预期更早触及上限。增加来自好几件事的叠加。

token 消耗变大的五个原因

出处：Claude Code 官方文档（Projects / Costs）

① 每个线程都是一个完整会话

每个都有自己的上下文。同时跑五个，就是五个会话的量

② 对话本身也在花钱

读回报、决定下一步，本身就要消耗 token

③ 默认是 Opus 的 high

新项目默认线程用 Opus 的 high effort，对话用 Opus 的 low

④ 盯着 PR 会把线程唤醒

每一次 CI 失败、每一条评审意见，都会唤醒睡着的线程并让它开工

⑤ 停一阵之后的重读

缓存过期（Pro 和 Max 是1小时）之后再去追问某个线程，它会从头重新读一遍对话

④ 尤其要当心。项目线程开出 pull request 之后，会默认开着 auto-fix 盯住那个 PR。即使你已经给其他云端会话关掉了 auto-fix，项目线程也是单独管理的。它会修好失败的 CI、回应评审意见，等全部通过之后回报，代价是只要你把它留在那里，它就会一直吃你的用量。要让它停下，就告诉那个线程停止监视这个 PR。

那到底多了多少？Projects 本身没有公布倍数，但和它基于同一个想法——把一个任务拆到多个会话——的 Agent Teams，文档给出的数字是队友在 plan 模式下运行时约为标准会话的7倍。并行是用来买速度的，不是用来省钱的，这一点两者共通。

还值得知道刹车装在哪里，以及刹得住刹不住。

  • 同时运行的线程数没有上限。你可以说“最多两个”，但文档明确写着这是Claude 会努力遵守的指示，而不是一个强制生效的设置。唯一的硬限制是每天200个线程（所有项目合计）
  • 触到用量上限的线程会自行等待，并在上限重置后自动继续。放着不管，它就会不打招呼地开始花下一个时间窗口的额度（要停下来，就在该线程上按 Stop，或者暂停整个项目）。例外是由例行任务启动的线程，它不会等待而是直接报错
  • 云端虚拟机本身不额外收费。涨的只有 token
  • 闲置的项目——没有在运行的线程、没有在盯的 PR、没有新消息——完全不消耗额度

💡 省着花的办法（文档给出的建议）

  • 在项目设置 > General 里，调低线程使用的模型和 effort 等级
  • 开一个新线程有可能比唤醒旧线程更便宜（不需要重读任何东西）
  • 告诉对话“一次少跑几个线程”“小问题就在这里回答，不要为此开线程”
  • 项目设置 > Usage 会按线程和模型拆分你的开销

7. 在五种并行方式之间怎么选

Claude Code 现在有五种并行推进工作的方式。Projects 是其中之一，它和其余四种的区别在于谁来分派工作，以及在哪里运行。把文档的对比表按“你实际会怎么选”重新排一下，就是下面这样。

方式谁来分派在哪里运行适合什么
SubagentsClaude，在对话进行当中你的机器不想弄乱主对话的旁支调查
agent view你自己你的机器你启动之后、只在需要时才介入的独立任务
Agent Teams担任主管的 Claude你的机器把一件事拆给多个工作者（实验性，默认关闭）
动态工作流脚本你的机器结果之间需要相互校验的大规模审计和迁移
ProjectsClaude云端跨越数天或数周、合上机器之后也该继续推进的工作

放到自己的情况里划这条线，大致归结为两个问题。这份工作需不需要你自己的环境（本地数据库、VPN、SSH）？如果需要，Projects 就不是选项。这份工作今天做得完吗？如果做得完，搬到云端得不到多少好处，agent view 就够了。至于 Subagents 和 Agent Teams 的区别，另有一篇文章做了详细对比。

8. 发出第一批任务之前要做的事

文档列出了“第一批任务之前”该做的四件事，每一件事后再补都很贵。

  1. 写好项目指令——从哪个分支切出来、在宣布完成之前要跑什么、哪些事必须先经你批准。官方给出的例子，是让线程在第一条消息里把自己够不着的东西明确点名然后停下，而不是拿别的东西顶替、做假数据或者靠猜。
  2. 只发一件真实的活，然后打开它、读一遍——看看它怎么回报，以及它在分支上实际留下了什么
  3. 重新审视模型和 effort 等级——放着默认的 Opus high 不动，是烧完额度最快的办法
  4. 说清楚“动手之前先给方案”“一次只跑几个线程”——等几轮下来结果都如你所料，再把这些去掉

还有一条，不那么起眼但值得知道。线程的沙箱会在两轮之间暂停，下一轮再恢复。如果恢复不了，工作就会从一份全新的克隆重新开始，也就是说未提交的改动可能丢失。对于耗时较长的活，文档建议告诉线程边做边提交并推送。

⚠️ auto-fix 和由评论触发的自动化是危险组合：开着 auto-fix 的线程，可能会用你的 GitHub 账号在评审评论的回复里发言（它会注明这是 Claude Code 写的）。在使用 Atlantis、Terraform Cloud，或者由 issue_comment 触发的 GitHub Actions 的仓库上，一条评论就可能触发一次真实的操作，所以文档建议在这类仓库上关掉 auto-fix。

总结

新的 Projects 不是“一个让你能并行干活的功能”，而是“一个把并行干活的麻烦从你手上拿走的功能”。分派、催办、每次都要把同一套背景重讲一遍，这些都消失了。如果你手上有持续推进的工作，代码放在 github.com 上，而且你用的是 Pro 或 Max，那么合得来的可能性很大。

反过来说，它不适合离不开你自己环境的工作、自建的 git 服务器，以及今天就能做完的一次性任务。而无论哪种情况都成立的一点是，并行是靠花 token 换速度。默认是 Opus 的 high，同时运行的线程数没有强制上限，盯着 PR 的线程还会自己醒过来。不知道这三件事就跑上一整天项目，额度掉下去的幅度会让你吃一惊。先把设置调低，把线程数控制住，用一个来回摸清手感，再逐步放开。这是最稳妥的入门方式。

如果想把项目中的调研结果整理成可反复查阅的提案或操作说明，也可以参考Claude Docs 使用指南。持续推进工作的 Projects 与创建、编辑文档的 Docs，可以按任务目的选择。

FAQ

Q. 我在聊天里已经有的项目会怎么样？

A. 暂时照常可用。官方博客说现有的 Pro 和 Max 项目仍然可以使用，并会随着放量范围扩大到聊天和 Cowork 而被升级。不过要注意，新的 Projects 会优先发放给没有现存项目的账号，所以积攒得越多，轮到你的时间就越晚。

Q. 能在终端的 Claude Code 里用吗？

A. 不能。能用的地方有三处：claude.ai/code、桌面应用的 Code 标签页，以及手机应用。通过 Amazon Bedrock、Google Cloud Agent Platform 或 Microsoft Foundry 接入的同样不在支持范围内。顺带一提，CLI 的 claude project 命令是另一个碰巧同名的功能。

Q. 我不用 GitHub，有什么选择？

A. 要真正跑代码，目前有两条路。把仓库放到 github.com 上并安装 Claude GitHub App，或者用跑在你自己机器上的 agent view。不过，不带仓库的项目完全不需要 GitHub 也能创建：把材料上传进去，让线程基于它调研或起草，再到 Library 标签页收结果。

Q. 在 Pro 方案上现实吗？

A. 现实，但动手之前先把设置调低。文档自己就提醒过，尤其是 Pro 用户，在运行项目的那些天里应该预期更早触及上限。新项目默认线程用 Opus 的 high，先把这一项降下来，把同时运行的线程数控制在少数，一边看项目 Usage 设置里的实际开销一边逐步放开。