Anthropic 重构 Claude Code 的 Projects，用户设定目标后由 Claude 拆解任务、并行调度多个线程、审查输出并汇总结果，线程本质上是各自独立分支的 Claude Code 云端会话。
上周某团队用 Claude Code 重构一个遗留调度模块，开发者在同一个会话里既要改代码、又要跑测试、还要追报错，来回切换上下文花了四十分钟。Boris 看完说，你其实可以拉三个终端同时干。
传统单会话模式的瓶颈在哪里
单会话模式下，所有操作共享同一个对话历史和上下文窗口。问题在于上下文窗口是有限的，Claude 在 Sonnet 4.6 上大约能处理 200 条指令后出现遵循能力下降\[3]。更关键的是，单线程操作意味着等待。
开发者在等 AI 生成代码、等测试运行、等报错分析。这些等待时间里，开发者并没有在做其他有价值的工作，而是在盯着进度条。某团队 2026 年的一次复盘显示，传统 AI 辅助编程中，开发者约 50% 的时间花在等待响应或代码运行结果上\[6]。
另一个隐性成本是上下文污染。当你在同一个会话里完成重构、测试、Bug 修复后，历史对话会越来越长，模型在做新决策时会受到旧上下文的干扰。这不是精度问题，而是注意力分配问题。
多会话并行是什么，解决了什么
多会话并行的核心思路很简单：把不同性质的任务分配到不同的独立会话中。一个会话负责写测试，一个负责修 Bug，一个负责重构。每个会话有独立的上下文窗口、独立的对话历史、独立的 Claude Code 实例。
这种模式直接消除了等待时间。当测试会话在跑用例时，重构会话可以同时修改代码结构，Bug 修复会话可以追踪报错源头。三个线程并行推进，总耗时不再是三者之和，而是接近最长的那一条。
更准确地说，它解决的不是算力问题，而是并发问题。Claude Code 的线程本质上是云端会话，各自消耗独立的 API Token 和上下文配额\[5]。这意味着你可以在用户离线的状态下让 AI 继续工作\[2]。
你以为是你在用AI，其实是AI在帮你干活
方案 A：传统 AI 编程 --- 单线程对话模式
你问、它答、你改、再问的循环
传统 AI 辅助编程的工作方式可以被简化为一个固定循环：开发者提出问题，模型给出代码，开发者发现 bug 或需求变更，再问一遍。
循环本身不是问题。问题在于，这个循环里每一个环节都在消耗开发者注意力。
让我用一个具体例子。假设你要把某个 611 行的调度方法重构。按照传统模式，你可能先问 Claude「帮我分析一下这个方法的问题」，得到一堆建议；然后你说「先提取辅助函数」，它改完；接着你说「设计管道架构」，它又改一轮；最后你跑测试，发现某个依赖没处理好，再回来问它「为什么这里报错了」。
整个过程中，你的上下文在两个地方来回切换：大脑里的任务状态，和对话里的历史。每一次切换都带成本。
更关键的是，Claude 的上下文窗口虽然大，但不是无限。某团队 2026 年在大型项目上的复盘显示，LLM 在指令总数达到 150--200 条时，遵循能力开始下降。
这不是模型变笨了，是注意力机制的物理限制。上下文越长，每个 token 获得的注意力越稀释。
上下文溢出与切换成本
上下文溢出是单线程对话最常见的结构性问题。
它的表现通常有三种。
第一种是历史污染。你在同一个会话里做了五个不相关的任务，第六个任务需要前三个任务的知识，但 Claude 会把后面两个任务的信息也带进来。你的问题被噪音包围，回答质量下降。
第二种是回滚困难。Claude 在一个会话里改了大量文件，突然发现方案不对，想回到二十步之前的状态。/rewind 命令可以解决，但它只能回滚到对话历史里的某个点，无法让你同时保留两个并行的探索路径。
第三种是任务切换成本。开发者常用 /clear 清空对话换任务，但这等于扔掉所有上下文。或者用 /compact 压缩历史，这会丢失细节。两种方式都是在「保上下文」和「保内存」之间做取舍，没有好的答案。
坦白讲，如果你还在一个对话框里串行推进多个任务，你买的是旗舰款，实际用的是平替套餐。
更狠的是，这种模式下开发者 50% 的时间花在等待响应或手动整理上下文上，而不是真正做工程决策。
单线程对话上下文压力机制
单线程对话的核心矛盾是：你试图让同一个对话历史承载多个独立任务的上下文，但对话历史是一个线性结构，天然不适合并行。
这个问题不是 Claude Code 独有的。所有基于对话的 AI 编程工具都有这个结构性约束。Claude Code 的 Projects 重构，本质上是在承认这个约束的基础上，寻找工程化的解法。
多会话并行：每个会话独立上下文与工作目录
Claude Code 的多会话并行不是概念，是具体可操作的机制。Desktop 版的 Code 选项卡中，每个对话都是一个独立会话，有自己的聊天历史、项目文件夹和代码更改，完全隔离于其他会话。
侧边栏列出所有会话，你可以同时启动多个。比如一个会话跑单元测试，一个会话处理重构，第三个会话专攻 Bug 修复。每个会话消耗独立的上下文窗口，互不影响。
/add-dir 跨目录操作与共享任务看板
Claude Code 支持在单会话内通过 /add-dir 命令添加额外的工作目录。这让模型能够在不切换会话的情况下，跨多个项目或文件夹操作和分析代码。
更关键的是共享任务看板功能。当 Claude 以团队模式运行时，它会维护一个 Task List，负责人将大任务拆解并指派给特定子会话，所有人实时更新进度。各个 Claude Code 实例在终端中自发调用 SendMessage 互发消息，后台讨论接口定义、校验判断、同步代码更改。
Claude Code Projects 多线程架构
独立上下文与历史隔离机制
每个子会话都有独立的上下文窗口，并加载项目本地上下文（如 CLAUDE.md、MCP 服务等）。但负责人（主会话）的对话历史不会传递给子会话，子会话只能感知到负责人传达的启动提示和直接消息。
这种隔离设计有明确的权衡：优点是上下文不交叉污染，每个子会话可以专注单一任务；缺点是子会话之间无法自动共享中间推理过程，需要通过共享文件或显式消息传递信息。
Plan 模式与权限控制的配合
Plan 模式是权限控制的关键配合机制。通过 Shift+Tab 可以循环切换 Claude 的执行模式：Manual（默认）、acceptEdits（允许文件编辑和常见文件系统命令）、Plan（触碰任何文件前先提案）。
在重构或多文件改动场景下，从 Plan 模式开始是最佳实践。Claude 会在单文件移动前给出完整提案，你确认后再执行。这避免了「先改后问」导致的连锁返工。
Plan模式权限流程
这套机制的价值在于把「信任」变成了可配置参数。对于低风险的小改动，可以用 acceptEdits 模式减少交互摩擦；对于影响面大的重构，强制走 Plan 模式确保每步可控。
方案 C：Git Worktree + 多实例 Claude 并行
Boris 团队的「养蛊式」开发策略
Gen AI 研究者 Boris 团队的做法简单粗暴：直接拉 3--5 个 Git Worktree，每个 Worktree 独立运行一个 Claude Code 实例。
一个跑测试，一个追 bug，一个做重构，另一个先写实现再等审查。四个线程同时推进，你不需要在它们之间手动切换上下文。
坦白讲，50% 的时间花在等待 AI 响应或代码运行结果，这是单线程编程最蠢的地方。
Boris 的解法只有两个字：并行。
每个 Worktree 是一个独立的 Git 分支快照，Claude Code 在其中运行时会加载各自的 CLAUDE.md 和项目上下文。不同实例之间互不干扰，你可以让它们各自推进，定期合并或比较结果。
这种「养蛊式」开发的核心理念是：让多个 agent 在同一代码库的不同分支上独立工作，最终由人类评审决定保留哪些产出。
Git Worktree + 多 Claude 并行架构
成本在于 API Token 消耗。三个实例同时运行，各自独立消耗上下文窗口，高频互调工具时费用是单实例的 3 倍左右。
但从效率看，原本需要 3 小时串行完成的任务，可以压缩到 1 小时内并行完成------前提是你有足够耐心做最终合并。
与 Claude Code Projects 的架构对比
Claude Code Projects 的重构（2026 年 9 月推出）把原来的「基于单一文件夹的对话」升级为「可托管多线程的协作架构」。
核心区别在于上下文管理方式。
Git Worktree 方案需要开发者手动维护多个工作目录，每个目录对应一个独立分支，Claude 实例之间没有内置通信机制。你需要自己处理冲突、协调进度、决定何时合并。
Projects 方案则不同：用户在单一项目内设定目标，Claude 自动拆解任务、并行调度多个线程、审查输出并汇总结果。线程本质上是各自独立分支的 Claude Code 云端会话，但共享同一个项目知识库和任务看板。
Claude Code Projects 多线程架构
Projects 引入了跨线程通信机制：线程之间可以通过共享任务看板同步进度，负责人可以查看各线程状态并干预。但这并不意味着完全自动化------最终合并仍需要人工判断。
两种方案的边界条件不同：
- Git Worktree + 多实例：适合熟悉 Git 工作流、需要完全控制每个实例行为的场景。成本透明，灵活性高，但协调负担重。
- Claude Code Projects：适合希望减少手动协调、接受一定黑盒调度的场景。上手成本低，但并发度和自定义程度受平台限制。
更狠的是，前者让你理解自己在做什么，后者让你忘记自己在做什么------两者都能干活，但出问题时 debugging 的难度天差地别。
如果你追求可解释性和可控性，选 Worktree；如果你追求交付速度和低摩擦，选 Projects。
这一改动解决了一个老问题：过去你让 Claude 帮你同时做三件事，它只能一件事一件事来，每切一次都要重新加载上下文，成本和时间都不划算。
选型决策：什么时候用哪种方案
决策矩阵：项目规模、风险容忍度、协作需求
三种方案各有适用场景，不要一概而论。
单会话 Claude Code 适合个人开发者处理小规模任务。上下文切换成本低，交互简单，适合快速验证想法或小型脚本编写。但当代码库超过两万行，或者需要同时进行多个不相关任务时，单会话的上下文溢出问题会迅速显现。
Git Worktree + 多实例方案适合高风险、高复杂度的大型重构。Boris 团队的做法是把同一个仓库克隆到三个独立的 Worktree，分别跑测试、追 Bug、做重构，互不干扰。这样做的代价是磁盘占用三倍，且需要手动同步修改。但你获得的是完全独立的上下文和随时回滚的能力。
Claude Code Projects 多线程方案适合大多数日常开发场景。它提供了类似多实例的隔离能力，但不需要管理多个文件夹。线程之间可以通过共享任务看板协调，适合团队协作或单人多任务切换。
选择的核心维度有三个。项目规模决定上下文管理的复杂度，代码量越大并行方案的优势越明显。风险容忍度决定你是否愿意接受潜在的上下文污染或同步冲突，高风险任务更倾向隔离方案。协作需求决定你是否需要多人共享同一个任务看板，Projects 方案在这方面有明显优势。
架构演进路径建议
如果你刚接触 Claude Code，建议从单会话开始，用/clear清上下文，用/compact压缩历史。习惯后再尝试/add-dir添加多目录，观察多上下文管理的实际痛点。当痛点出现时，再考虑升级到 Projects 多线程或 Git Worktree 方案。
这种渐进式路径避免了一开始就过度工程化，也让你对每个方案的边界有切身体会。
Mermaid 架构对比图
Claude Code 多会话方案架构对比
方案 B 的核心价值在于它把多线程调度从手动操作变成系统行为，你只需要描述目标，具体怎么拆分和执行由 Claude 完成。
三种方案的取舍结论很直接。单会话用于小型任务， Projects 多线程用于日常多任务开发，Git Worktree 用于高风险重构。不要为了并行而并行，合适才是关键。
参考文献
1 Projects redesigned: from folder to conversation | Claude by Anthropic. claude.com/blog/projec... 2 Claude Code推出Projects：一個對話拆出並行線程 - 富途资讯. news.futunn.com/hk/post/794... 3 Claude Code 支持在单会话中添加多个工作目录. [www.oschina.net/news/REDAC...](https://link.juejin.cn?target=https%3A%2F%2Fwww.oschina.net%2Fnews%2F%255BREDACTED "https://www.oschina.net/news/%5BREDACTED") 4 Claude Code代码生成调试重构一键搞定-腾讯云开发者社区-腾讯云. cloud.tencent.com/developer/a... 5 tutorials. www.huaxiaozhuan.com/claude_code... 6 Claude Code之父首曝：「养蛊式」开发，质量碾压老架构师 - 智源社区. hub.baai.ac.cn/view/52820 7 Desktop application - Claude Code Docs. code.claude.com/docs/zh-CN/... 8 Claude Code 的常用技巧. labuladong.online/zh/ai-codin...
延伸入口
- 原文归档：tobemagic.github.io/ai-magician...
- 公众号：计算机魔术师
