AIREITERClaude Projects 重构后，一个 Project 不再只是单一对话空间，而是可以协调多个并行运行的 Claude Code 云端会话。需要注意的是，在这次改版逐步推送期间，现有的 Chat Project 和 Cowork Project 仍会沿用旧模式。实际使用中，最关键的问题有两个：哪些上下文能够保留，以及任务究竟在哪里执行。
Claude Projects 重构到底改了什么
重构后的 Project 会从目标和相关上下文开始工作。Claude 先拆解请求，再创建或复用工作线程，检查各线程的产出，最后在主对话中汇总结果。Anthropic 表示，每个工作线程都是一个完整的 Claude Code 云端会话，拥有独立的分支和仓库副本；它们可以运行测试、阅读文档并创建拉取请求。（Anthropic 公告）
目前，这套新模式仍处于分阶段 Beta 测试。Anthropic 表示，首批获得访问权限的是使用 Claude Code 云端会话的部分 Pro 和 Max 订阅者；更广泛的 Claude、Cowork、Team 和 Enterprise 支持将在之后推出。现有 Project 按计划会继续运行，并随着新版本覆盖到相应产品界面而完成升级。（Claude 帮助中心）
几个关键的架构差异
| 维度 | 重构后的 Projects | Cowork | 独立使用的 Claude Code |
|---|---|---|---|
| 核心单位 | 一个包含工作线程的协调器对话 | 按工作项目组织的任务 | 在代码仓库或目录中运行的编码会话 |
| 适用场景 | 需要拆分执行并保持连续性的多部分工作 | 围绕桌面文件和已连接应用展开的办公与知识工作 | 直接进行软件开发、测试、分支管理和终端操作 |
| 执行方式 | 当前 Beta 中为云端线程 | 根据任务和推送情况，可能采用云端或本地工作流 | 根据配置，可能采用云端或本地 Claude Code 会话 |
| 上下文 | Project 文件、代码仓库、指令、共享记忆和 Library | 项目上下文、指令、文件、定时任务和 Cowork 记忆 | 仓库文件、CLAUDE.md 以及会话上下文 |
| 并行工作 | 内置于 Project 模型中 | 以任务为中心，不采用重构版的协调器模型 | 通常由开发者或多个独立会话自行管理 |
| 主要风险 | 并发会话越多，消耗的用量越大；同时修改文件还可能产生冲突 | 本地与云端边界不清，以及不同项目之间的记忆彼此独立 | 跨会话工作时必须明确提供上下文 |
Projects、Cowork 和 Claude Code：工作应该交给谁负责？
如果一项工作包含多个相互依赖的方向，例如同时修改 API、Web 客户端和移动客户端，就适合交给 Project 负责。Anthropic 给出的示例涉及三个代码仓库和一个已弃用的 v1 端点：不同线程分别迁移调用方、运行测试并创建拉取请求，协调器则汇报合并顺序。（Projects 重构版）
需要协调多个步骤时，选重构后的 Projects
当任务需要一个持续存在的目标、并行执行能力，以及统一记录决策的地方时，重构后的模式更合适。它尤其适合发布项目、跨仓库迁移，以及同时涉及文档和代码的工作。协调器可以把后续请求分派给最合适的线程。
代价是资源消耗。Anthropic 表示，每个工作线程都按完整的 Claude Code 会话计算，因此同时运行多个线程会更快消耗套餐用量。并行修改也可能像普通拉取请求一样产生合并冲突；有了编排机制，并不意味着可以跳过人工审查。
桌面知识工作和已连接应用，选 Cowork
对于文档、电子表格、浏览器、邮件、日历和本地文件夹等重复性任务，Cowork 通常是更合适的默认选择。它的 Project 可以包含指令、上下文、定时任务和项目范围内的记忆。不过，Cowork 以任务为中心，并不是代码仓库协调器的直接替代品。
不要把 Chat Project 和 Cowork Project 当成同一个工作区。Using Claude 的实测对比发现，通过 Import 导入时，文件和项目指令可以转移，但只存在于累积聊天记忆中的信息并不会随之迁移。作者将结果概括为：
“文件可以，聊天记忆不行”——Using Claude 的实测对比
需要直接控制代码仓库时，选独立的 Claude Code
如果开发者需要直接检查代码仓库、编辑文件、运行命令并审查改动，而不是把一整套工作交给协调器分派，就应该直接使用 Claude Code。建议将长期有效的指令放进版本控制中的 CLAUDE.md。Anthropic 将它描述为项目记忆文件，Claude Code 会在会话开始时读取它。（Claude 帮助中心：CLAUDE.md）
迁移：哪些是官方说法，哪些仍然没说清
Anthropic 的官方说法让人放心，但并不完整：在过渡期间，现有的 Chat Project 和 Cowork Project 会继续运行；随着新体验逐步扩展，Pro 和 Max 用户的 Project 将获得升级。公告没有提供通用的一键转换按钮、明确的升级日期，也没有给出逐字段的迁移清单。（Claude 帮助中心）
因此，目前要区分两种迁移情况：
- 等待 Anthropic 分阶段升级：等重构后的体验覆盖到你的账号和对应界面。在此之前，现有 Project 按计划仍然可以使用。
- 现在把 Chat Project 转到 Cowork：如果 Cowork 中已经提供 Import 选项，可以直接导入，然后核对结果。实测对比显示，Cowork 有三种创建方式——从零开始、从 Claude Project 导入，或使用已有文件夹；其中 Import 会带上文件和指令，但不会带上累积的聊天记忆。
更稳妥的迁移清单
- 在切换工作区前，导出或复制源工作区中的文件、指令和重要决策。
- 把长期有效的项目事实写进可审查的文件，而不是只留在聊天记录里。对于代码项目，应提交
CLAUDE.md、当前状态说明和决策记录。 - 可以执行导入，也可以等待升级，但在完成验证前不要删除原来的 Project。
- 让目标工作区回答一个具体对应某个文件的事实，并检查它是否引用了预期的来源。
- 询问一个只存在于旧对话中的决策。如果目标工作区答不上来，就把这项决策补充到项目文件或明确指令中。
- 修改一条测试指令，重新打开一个新线程，确认新指令是否可见。
- 对于代码项目，检查分支，运行测试套件，并在合并前审查拉取请求中的差异。
- 除非 Anthropic 明确说明存在实时同步关系，否则应把新旧工作区视为彼此不同步。
上下文是否会保留：不用猜，自己做检查
Anthropic 表示，重构后的线程会从 Project 的文件、代码仓库、指令和记忆开始工作，并且每个线程都会为共享的 Project 记忆贡献内容。但这是产品层面的说明，并不等于所有旧 Chat 或 Cowork 细节都能完美转换。（Claude 帮助中心）
在信任迁移后的工作区之前，可以先完成下面五项检查：
| 检查项目 | 测试提示词或操作 | 通过条件 |
|---|---|---|
| 文件上下文 | 询问某个明确出现在指定源文件中的事实 | 回答指出了正确的文件和值 |
| 指令 | 添加一条有明显特征的输出规则，然后启动新线程 | 新线程遵守了这条规则 |
| 记忆 | 询问一个只记录在此前聊天中的决策 | 只有在该决策被有意迁移，或被重构版保留下来时，系统才能回答 |
| 仓库状态 | 询问当前分支、已修改文件和测试命令 | 工作线程报告的是实际连接的仓库状态 |
| 同步 | 导入后修改源 Project | 只有在存在已说明的同步机制时，目标工作区才会同步变化；否则需要手动更新 |
最容易暴露错误预期的，往往是记忆测试。独立进行的 Chat 到 Cowork 测试发现，Cowork 能够回答基于已转移文件的问题，却无法回答那些答案只存在于聊天记忆中的问题。因此，与其希望界面自动推断历史，不如准备一份简短的决策日志作为迁移材料。
Claude Projects 重构常见问题
Claude Projects 重构版已经向普通 Claude 用户开放了吗？
在最初的推送阶段并不是全面开放。Anthropic 先向使用 Claude Code 云端会话的部分 Pro 和 Max 订阅者提供访问权限，并表示之后会扩展到 Chat、Cowork、Team 和 Enterprise。
我现有的 Project 会被删除吗？
Anthropic 表示，现有 Chat Project 和 Cowork Project 会在过渡期间继续运行，并随着推送扩大而完成升级。不过，仍然建议自行导出数据或保留源文件，因为帮助文档并没有承诺提供详细的回滚方案或迁移报告。
重构后的 Projects 会取代 Cowork 吗？
不会。重构后的 Projects 负责围绕多个并行 Claude Code 会话进行协调；而 Cowork 仍然更适合处理桌面文件、已连接应用、定时任务和常规知识工作。
Project 记忆会在所有 Claude 界面之间保留吗？
不要想当然地认为会。Anthropic 描述的是重构后 Project 内部的共享记忆，而 Chat 到 Cowork 的实测工作流显示，只存在于聊天中的记忆不会随着文件和指令一起转移。
重构后的 Projects 现在能使用本地代码吗？
首批重构版线程运行在云端。Anthropic 表示，未来计划支持本地执行，包括配合本地工具工作，以及在用户网络边界内运行，但公告没有给出明确的发布日期。
并行的 Project 线程会消耗更多用量吗？
会。Anthropic 表示，每个线程都是一个完整的 Claude Code 会话，同时运行多个线程会更快消耗用量。
在持续推送期间，最稳妥的默认选择
需要协调一整套工作时，使用重构后的 Projects；围绕文档和已连接应用进行任务自动化时，使用 Cowork；需要直接控制代码仓库时，则使用独立的 Claude Code。迁移期间，应把文件和决策日志作为事实来源，并分别测试文件访问、指令、记忆、仓库状态和同步情况。剩下的取舍其实很明确：重构后的模式承诺更强的连续性和任务分派能力，但考虑到它仍处于 Beta 阶段，而且会消耗更多会话用量，先完成可验证、可回退的迁移，比立即全面切换更稳妥。