Claude Code Projects入门指南：多线程并行开发实战

什么是 Claude Code Projects？

Claude Code Projects 是 Anthropic 为 Claude Code 推出的全新工作模式。它的核心思路很直接：你给出一个宏大目标，Claude 自动将其拆解为多个子任务，并分配独立的线程（Thread）并行推进。

据 B 站技术 UP 主的演示视频介绍，过去使用 Claude Code 时，用户需要自己考虑创建子代理、管理多个会话或 work tree。而 Projects 将这一层复杂度完全接管——你只需要描述目标，剩下的调度工作由 Claude 完成。

每个 Thread 本质上是一个独立的 Claude Code 会话，运行在云端自己的分支上。这意味着即使你合上笔记本电脑，任务仍在继续推进，你也可以随时通过手机端查看进度。

子代理与会话管理：在 Claude Code Projects 出现之前，Claude Code 已经支持「子代理」和「work tree」这两个概念。子代理（Subagent）指在一个主会话里派生出的、拥有独立上下文窗口的辅助代理，适合把探索、搜索等高频但结果简单的操作隔离出去，避免污染主对话的上下文。Work tree（工作树）是 Git 的多工作目录机制，允许同一个仓库同时检出多个分支到不同目录，从而让多个任务在文件层面互不干扰。过去开发者要自己手动创建子代理、切换会话目录、协调各分支的合并顺序，心智负担不小。Projects 做的事就是把这套调度和隔离机制产品化，用「目标 → 子任务 → 云端 Thread」的抽象替代手动编排，让并行工作的规模不再受限于本地环境。

什么时候该用 Projects？

Projects 最适合那些超出单次会话承载能力的任务。视频中列举了几类典型场景：

• 大规模迁移：例如将应用从已废弃的包中迁移出来
• 跨仓库更新：在 API、Web 和移动端仓库中同步更新某个端点
• 持续性排查：如视频中的示例——调查并修复网站上一系列性能问题，同时设置每日检查以防未来回归

判断标准很简单：如果你的目标需要跨越多个会话、甚至涉及多个 repo，Projects 就是为这个场景设计的。

从零开始：创建与配置

在桌面端或 Web 应用中打开 Code 标签页，点击创建新项目。你需要填写三个关键信息：项目名称、Claude 需要努力达成的目标、以及相关的仓库或文件夹。

创建完成后，你会进入主对话界面。这里是与 Claude 沟通和协调工作的中枢。你可以从它给出的建议中挑选一个、快速提问，或者直接给出一组任务列表。

视频演示中，UP 主将指标数据和用户反馈分享给 Claude，让它探索代码库并给出性能优化建议。Claude 在探索完仓库后返回发现结果。双方确认要做的工作后，Claude 为每个任务启动一个 Thread。

大多数时候你可以放手让 Thread 自行运转，但也可以点击卡片跟进 Claude 的操作、在 Thread 中对话来引导任务方向，或者直接停止它。

Thread、PR 与产物管理

当一个 Thread 产出了具体变更（比如一个 bug 修复），它会自动打开 Pull Request——也可以由你随时要求。之后 Thread 会持续关注这个 PR：CI 失败时推送修复，有审查评论时逐条回应。

你可以在主对话中看到 PR 的下一步动态。想查看所有 PR 及其状态，进入 Overview 中的 Pull Requests 标签页即可。准备合并时，直接告诉 Claude。

Projects 还引入了共享产物（Artifacts）机制。你可以让 Claude 生成一份包含优化前后性能指标对比的报告，用于与团队分享。这些产物存放在 Library 标签页中——可以把它理解为项目的共享文件夹。任何 Thread 都能访问其中的内容，包括你手动添加的线框图或设计规范。这意味着下次再做性能相关工作时，Claude 可以直接更新那份报告。

CI 与 Pull Request 工作流：PR（Pull Request，合并请求）是 GitHub 等平台上提交代码变更的标准方式——开发者在独立分支上提交改动，通过 PR 请求合并到主分支，并可附带说明、讨论和审查。CI（Continuous Integration，持续集成）则是每次推送代码后自动触发的构建、测试流水线，失败时会在 PR 上标红并给出日志。文中说的「Thread 持续关注 PR」，正是指 Claude 会读取 CI 状态和审查者的评论，主动推送修复提交或逐条回复评论，直到 PR 可以合并。这套机制之所以重要，是因为它把「编码—提交—验证—修改」的循环交给了 Thread，开发者只需在关键节点确认即可，而不是自己盯着流水线反复调试。

进阶用法：监控集成与自动化

在 Shell 环境中，你可以将 Claude 连接到监控服务，让它自行检查真实的用户指标。随后要求 Claude 设置一个每日运行的例程来检测性能回归。一旦发现问题，它会自动打开一个 Thread 进行调查，等你下次查看项目时，排查工作已经在等待你了。

Claude Code 团队的三个实用建议

视频末尾分享了来自 Claude Code 团队的优化技巧：

一、注意用量管理。 每个 Thread 都是一个完整的 Claude Code 会话，一个项目可以同时运行多个，因此消耗套餐额度的速度远快于单会话。建议将协调者（Coordinator）保持在低投入（low effort）级别——它主要负责路由分发，提高级别不会带来明显更好的结果。而 Thread 承担了主要工作量，但每个任务范围明确，可以考虑默认使用较小的模型，遇到更大、更复杂的任务时再在 Thread 中切换。

二、主动设定工作方式。 你可以告诉 Claude 你希望它如何运作——比如同时运行多少个 Thread、多久向你汇报一次进度，或者在开始工作前先展示计划。

三、利用共享记忆。 Thread 之间共享记忆。你可以让 Claude 记住某项偏好，应用于所有未来的 Thread，也可以在项目设置中编辑这些记忆内容。

低投入级别与模型分层的取舍：这里提到的「低投入（low effort）」以及「默认使用较小模型」，对应的是大模型推理中常见的成本—质量权衡。推理投入级别越高，模型在生成前进行的思考步骤越多、上下文消耗越大，通常能提升复杂推理的质量，但也显著增加延迟和 token 开销。协调者（Coordinator）的职责主要是解析目标、拆分任务、把任务路由到各个 Thread，本质是调度而非攻坚，因此低投入级别已足够，调高不会带来等比例的质量提升。相反，Thread 承担真正的工作，但每个任务边界清晰、范围有限，用小模型足以胜任；只有在遇到架构设计、复杂 debug 等硬骨头时，再临时切换到大模型。按角色分配模型和投入级别，是在多 Thread 并行场景下控制套餐额度消耗最直接的手段。

当前状态

Claude Code Projects 目前处于 Beta 阶段，正在逐步向 Pro 和 Max 套餐用户推送。对于经常面对跨会话、跨仓库大型任务的开发者来说，这套将调度、隔离和持续性整合在一起的工作流，值得在获得访问权限后第一时间尝试。

它的核心价值不在于某个单点功能的突破，而是把「管理多个并行任务」这件消耗认知带宽的事情，从开发者手中接了过去。