Claude Code项目功能引入并行AI工作者

Claude Code Projects 正在把多会话编程变成一项由 Claude 统筹的工作：你给目标，它负责拆任务、分派并行线程、检查产出，再组装结果。人仍然可以随时介入，也能离开电脑后让云端继续跑。

这次变化值得关注的地方，是任务之间开始有了协调者和共享记忆。不过，原文给出的是产品机制与使用示例，没有提供效率、成本或成功率的对照数据。能并行推进，不等于已经解决多人开发中那些棘手的集成问题。

从逐个指挥会话，变成给项目设目标

过去同时开几个 AI 编程会话，拆分工作、传递上下文和汇总结果都要自己做。新版 Projects 把这些职责交给协调者（coordinator）：先界定请求范围，再把工作分派给线程，跟进进度、审查输出并整理最终结果。

原文给了两个例子。

一个是降低应用结账流程的 p75 延迟，也就是让第 75 百分位的请求耗时下降。Claude 可以把分析各个 endpoint、测试优化方案、创建 PR 分到并行线程里。另一个是退役已弃用的 v1 endpoint：连接 API、web 和 mobile 仓库后，每个仓库分配一个线程，迁移调用方、运行测试、创建 PR，最后说明哪些 PR 需要先合并。

这些都是能力示例，原文没有给出实际降幅、迁移耗时或合并成功率。

启动项目时，需要选择目标以及仓库或上下文，还可以配置 cloud environment、connectors、plugins、instructions 和 model。Claude 会先建议可以立即接手的工作。你既能在项目主聊天里调整方向，也能进入某个线程检查细节。

协调者接过了任务调度，但工程验收仍然需要明确标准。

例如「降低延迟」还不够，至少要讲清测量环境、目标指标和允许修改的范围。否则并行线程可能各自完成了一项优化，合起来却未必解决同一个问题。

线程独立执行，共享记忆负责延续上下文

这里的线程不是普通聊天窗口。每个线程都是完整的 Claude Code cloud session，拥有独立分支和仓库副本。它可以创建 pull request、运行测试；面对文档，也可以读取材料并起草内容。任务较大时，线程还能通过 subagents、loops 和 workflows 继续拆分工作。

独立副本方便并行，却没有消除代码重叠。如果多个线程修改同一份代码，仍然要像普通 PR 一样处理 merge conflict。协调者能组织工作，不能据此推断它能自动解决所有集成问题。

另一项变化是共享记忆。所有线程都可以写入和读取项目记忆，让跨多次请求、持续多天的工作接得上。原文举的内容包括：发布日期改到周五、为什么取消某个导出功能，以及修改 billing service 前应该先找谁确认。

Claude 也能记住沟通偏好，例如多久汇报一次、多久启动新线程、更新需要多详细。项目还增加了 library，用来集中保存用户加入的文件和 Claude 生成的产物。

这些设计有助于减少重复交代，但原文没有说明记忆如何纠错、过期决策如何失效，以及不同线程遇到冲突信息时如何取舍。长期任务能不能稳定运行，这些机制很关键。

我的判断

我认可把「统筹」单独交给协调者。对于跨仓库迁移、可以分头验证的优化任务，人工最容易耗在反复交代和等待交接上。Projects 把目标、线程、记忆和产物放进同一个工作空间，确实更贴近持续开发的组织方式。

但与手动开多个 Claude Code 会话相比，它到底节省多少时间，原文没有对照数据。共享记忆能减少多少提示词工作，也只是产品方的主张，不能直接当成已验证的收益。

成本同样要算。每个线程都是完整会话，多个线程同时运行会更快触及使用额度。项目支持查看专属用量，并分别选择协调聊天和工作线程的 model、effort levels。并行数增加，消耗也可能增加，原文没有给出成本测算。

可用范围也有限。按原文发布时的安排，beta 首批面向部分使用 cloud sessions、且 web 或 desktop 没有现有项目的 Claude Pro 和 Max 用户；随后一周扩大到更多同套餐用户，再扩展至 Claude 其他场景以及 Team、Enterprise。未获权限的 Pro、Max 用户可加入 waitlist。现有项目继续照常工作，后续随 chat 和 Cowork 的推广升级。

目前线程运行在云端。在本机结合本地工具、代码和内网执行，原文仅称即将推出，没有给出确定日期。

能拿来做什么

• 跨 API、web、mobile 仓库迁移时，可以按仓库分配线程，并要求输出调用方清单、测试结果和 PR 合并顺序，方便检查依赖是否遗漏。
• 优化结账流程延迟时，先固定 p75 的测量口径和环境，再让线程分别分析 endpoint、验证方案，避免只看某一次请求变快就接受修改。
• 持续多天的项目，可以把发布日期、取消方案的原因和服务修改约束纳入共享记忆，同时把关键决定保留在可检查的项目材料里。
• 开启多个线程前，先设置协调者与工作线程的 model、effort levels，并查看项目用量；涉及本地工具或内网的任务，则先确认云端环境是否具备执行条件。