Claude Code 推出 Projects：让 Claude 当协调者，多任务并行开发

Claude Code 正式上线了 Projects 功能，将「一个项目」定义为一段持续的对话。你只需把要做的事一次性交给它，Claude 会为每个任务开启独立线程，替你协调整个开发流程。目前该功能处于 Beta 阶段，已向候补名单上的 Pro 和 Max 用户全部开放，官方同步发布了一段四分钟的上手演示。

Projects 的核心机制：从手动协调到自动分派

在没有 Projects 之前，同时跑几个会话的协调工作完全靠你自己：决定每个会话做什么、每次开头重复一遍背景、再逐个回去检查谁做完了、谁在等你回答。据 B 站官方演示视频介绍，Projects 把这些事情收拢到一个地方——你贴一份 bug 报告、一段报错或一串任务，Claude 会给每件事开一个线程，或者交给已经在做这一块的线程。简单的问题它直接在对话里回答，背景只需交代一次，项目说明会带进每个新线程。比如「该往哪个分支提交」说一遍，所有线程都知道。

这种设计解决的是多会话并行时的上下文碎片化问题。你可以走开，一小时后或第二天再回来，Overview 面板会列出哪些线程做完了、哪些 PR 等你审、哪个线程在等你回答。

三个组成部分：协调者、线程与总览面板

Projects 由三部分组成。项目对话里的 Claude 是协调者，它接收你发的内容，决定哪些要开成线程并跟踪每个线程，只看线程汇报回来的结果，不看每一步过程。线程负责干活，每个线程是一个独立的会话，拥有自己的上下文窗口，通常跑在云端、在自己的分支上工作，需要时开 PR；云端线程在你合上电脑以后还会继续跑，你可以在手机上查看和调整。需要本机才有的东西，比如本地数据库、设备模拟器、VPN 后面的接口，可以让 Claude 把这个线程放到你的电脑上，通过 Remote Control 运行。Overview 面板汇总所有线程的状态，旁边还有 Library。

官方演示用一个排查和修复网站性能问题的例子串起完整流程：在桌面端的 Code 标签页或网页版里新建项目，填上名字、目标，再加上相关的仓库或文件夹；进入主对话后贴上网站的性能指标，让 Claude 读代码提出改进方案；商量好做哪几项后，Claude 给每一项开一个线程并行去做。线程有了具体改动，比如修好一个 bug，会自己开 PR，然后继续盯着 CI——挂了就推修复，有评审意见就去处理，准备合并时跟 Claude 说一声就行。最后让 Claude 写一份带前后性能数据的总结存进 Library，再接上监控服务，设一个每天运行的 routine 检查性能回退，一旦发现就开一个线程去查。

Remote Control 是 Claude Code 提供的一种桥接机制：当某个线程需要访问只能在本机获取的资源（如本地数据库、设备模拟器、内网接口）时，协调者可以把该线程调度到你自己的电脑上执行，而不是在云端沙箱中运行。你仍然通过网页或手机端的对话界面查看进度、审阅改动，实际的命令执行和文件操作发生在本地。这相当于把云端线程的「遥控」能力延伸到了你的开发机上，兼顾了并行效率与本地环境的必要性。

适用场景与边界

什么时候值得开一个项目？官方文档给出的判断标准是：目标比一次会话长，还会不断冒出新任务。文档举了四类场景：一个目标横跨很多仓库，比如把所有服务升级到新的 Lint 配置；一个你持续往里喂问题的领域；一次比单个会话更大的构建或迁移；以及不是代码的工作，比如一批合同或工单，导出结果以文件的形式交到 Library。

反过来，也有更适合别的工具的情况：一次会话能做完的单个任务，直接开云端会话；每个任务都离不开你的机器，用本地会话或 Agent View；只需要定时跑、不需要对话的，单独建一个 routine；团队在 Slack 里一起派活，用 Claude Tag。

Routine 是 Claude Code 中一种按计划自动触发的任务机制，不与主对话绑定，也不需要你实时参与。你设定运行频率（例如每天一次），到点后 Claude 会自动执行预设的检查或操作，比如扫描性能回退、拉取最新指标。如果发现问题，它可以进一步开一个线程去排查。Routine 适合周期性、无需对话的监控类工作，与 Projects 的「持续对话 + 多线程」模式互补：Projects 负责协调需要人参与的多任务，Routine 负责无人值守的定时巡检。

上手前值得做的四件事

正式派活之前，官方建议先做几件事。第一，写好项目说明——这是每个线程开工时拿到的简报，最多一万六千个字符，写清项目目标、在哪些仓库和分支上做、线程怎么自查缺东西时怎么办、哪些事要先问你。第二，先派一小块真实的工作，等线程做完打开看看它怎么汇报、在分支上做了什么。第三，检查模型和 effort——按文档，新项目默认所有线程用 Opus High Effort，最好额度；Claude Code 团队建议协调者保持 Low Effort，它主要负责分派任务，调高也不会明显更好；范围清楚的线程可以换小一点的模型，复杂任务再换回来。

第四，直接告诉 Claude 你希望他怎么干活：先列计划等你同意再开始、最多同时跑几个线程、多久汇报一次。这些偏好会存进项目记忆，Claude 会照着做，但它们不算硬性约束。项目记忆在线程之间共享，让 Claude 记住一个要求、一个决定或者一个坑，后面的云端线程开工时都会读到，记忆文件可以在项目设置里查看和编辑。

项目记忆 是 Projects 中跨线程共享的持久化上下文存储。你在主对话中提出的偏好、做出的决定或踩过的坑，会被写入项目记忆，之后每个新开的云端线程在启动时都会读取这份记忆，从而避免重复交代背景。它不同于项目说明：说明是你主动编写的静态简报（最多一万六千字符），而记忆是随着对话动态积累的。记忆文件可以在项目设置里查看和编辑，但它属于软性引导而非硬性约束，Claude 会尽量遵循，并不保证绝对执行。

用量、限制与当前状态

用量方面，Projects 和其他 Claude Code 的会话共用同一套额度，但用得更快——每个线程都是一个完整的会话，还能同时跑好几个。每天最多新开 200 个线程，达到额度上限的线程会自己等着，额度重置后接着做。目前 Projects 还在 Beta 阶段，可以在网页版、桌面端和手机 App 上用，命令行和 IDE 插件里还没有；一个项目只属于一个用户，不能共享。

从产品逻辑看，Projects 把「人肉调度多个会话」的工作交给了模型本身，协调者与执行线程的分层设计也解释了为什么官方建议协调者用 Low Effort：它的职责是分派与跟踪，而不是深度推理。对于经常并行处理多个开发任务的团队来说，这可能是比单纯提高单会话能力更实际的一步。

Effort 是 Claude Code 中控制模型推理投入程度的参数，通常分为 Low、Medium、High 等档位。档位越高，模型在回答问题前进行的内部推理越多，消耗的 token 和额度也越多。Projects 中新项目默认所有线程使用 Opus High Effort，以获得最好的任务完成质量；但协调者线程被建议保持 Low Effort，因为它的核心职责是分派任务和跟踪进度，而非深度推理，调高 effort 对协调效果提升有限，反而浪费额度。对于范围清晰、步骤明确的执行线程，也可以换用更小的模型或更低的 effort 来节省用量。