接着之前的Claude Code使用笔记这篇单独聊聊多任务并行开发。先说一个真实场景有段时间我习惯一个会话把所有需求都聊完让它先实现模块A的新功能再修模块B的报错最后补一轮测试。听着很合理实际跑起来却越改越偏——模块A的需求还没收口模块B的代码已经被顺手改了一半等回到模块A它又开始纠结刚才那个旧方案要不要保留。后来我终于意识到这不是模型能力的问题是我把本该并行的工作硬塞进了串行会话里。这篇笔记的核心思路是既然工具本身支持独立会话那就把任务拆开同时跑多个会话。适合谁看如果你也在多个需求之间来回切换、感觉Claude Code越用越笨或者经常改着A把B弄乱这篇就是一次完整的经验复盘和避坑记录。1. 串行排队到并行开发我在单会话里浪费掉的时间1.1 一个会话排队跑多个任务实际耗时比想象中高得多先说为什么我一开始会习惯串行。打开一个claude会话把任务清单丢进去连续对话看起来非常自然就像和一个线上同事对接一样。但自然不等于高效。我统计过一次三个任务分别是给某个服务补一个查询接口、修正一个校验逻辑的边界条件、给已有脚本补单元测试。这三个任务理论上互相独立但我在同一个会话里按顺序跑整个下午只完成了两个半。问题出在隐性开销上。任务A做完之后它的所有中间讨论、尝试过的错误方案、以及我随口提过但最后没有采纳的思路全都留在这个会话的上下文里。当会话切换到任务B时这些历史内容并不会自动消失它们会成为模型判断的背景噪音。我观察到的典型现象是明明是在修校验逻辑它会突然建议那要不要把A模块的导出结构也一起调整一下因为它检测到上下文里有一段关于A结构不够合理的讨论——那是我在任务A早期随口说的根本不在当前交付范围里。更麻烦的是时间评估。串行模式下的总耗时不是三个任务耗时的简单相加而是会产生严重的边际膨胀。任务与任务之间的上下文切换会让后面的任务反复确认你到底要什么。我甚至遇到过一种情况到第三个任务时Claude Code 开始遗漏我在第一个任务开头给出的全局约束比如不要改公共工具类然后自作主张动了不该动的文件。后来我做了一次对照实验同样三个任务拆成三个独立会话并行跑只花了原来六成左右的时间而且每个任务的产出边界都清晰得多。1.2 上下文污染改任务B时任务A的旧想法反复冒出来这是串行模式里最隐蔽的坑。上下文污染的表现形式很多最轻微的是多余的关心——比如你在做任务B它提醒你任务A还有遗留问题最严重的是静默扩散——它把任务A的临时方案当成既定结论直接套用到任务B的实现里。我踩过一次比较重的坑当时任务A讨论过某个接口参数要不要改名没有结论切换到任务B时我让它实现一个新的调用逻辑结果它默认使用了改名后的参数名而那个改名方案根本还没落地。查了十分钟才发现源头——不是代码逻辑错是上下文里的旧讨论污染了当前决定。这种问题在串行会话里很难完全规避因为上下文本身就是连续的你没法精准告诉模型现在忘掉前面的讨论只看下面这份需求。而会话一旦拆分每个会话从零开始污染问题天然就少了一大半。2. 会话独立性、CLAUDE.md 与上下文窗口并行方案的三个地基概念2.1 每个终端会话都是独立工作台并行开发之所以可行最根本的原因是在终端里打开的多个Claude Code会话彼此是相互独立的。每个会话有独立的历史记录、独立的上下文积累也独立地读取项目文件。用大白话说每个终端窗口等于给了一个单独的工作台工作台之间的草稿纸不会混在一起。这个特性带来的直接好处是任务边界可以通过会话边界来强制。我在模块A的会话里聊再多模块A的历史包袱也不会影响模块B会话的判断。并行开发其实是在利用这种隔离性把一堆任务之间的复杂关系简化成多个独立小任务的各自闭环。但也别高兴太早独立性不等于完全隔离。会话之间共享的是磁盘上的项目文件和 git 仓库状态。也就是说它们在思考层面互不干扰在落盘层面却可能打架。这一点放到后面第五部分细说并行开发的大部分翻车事故都发生在这个交叉地带。2.2 CLAUDE.md 是并行开发的共享工位牌也是潜在雷区Claude Code 支持在项目根目录放一个CLAUDE.md文件相当于项目约定文档每个新会话启动时会自动读取。它对并行开发有两面性。正面作用很明确全局性的规定适合放在这里。比如本项目使用 TypeScript 严格模式公共模块不允许随意修改测试文件统一放在 tests 目录下。只要这些约定进了CLAUDE.md每个并行会话开工时都会自动载入省得我在每个终端里重复敲一遍约束条件。相当于在各个独立工作台之间贴了一张共享的工位牌所有人都能看到。反面作用在于如果你在并行开发进行到一半时修改了CLAUDE.md那么已经启动的会话不会重新读取新启动的会话却会按新规矩办事。两个会话对同一项目的认知基线就不一致了。我有一次在并行过程中往里面加了一条日志统一走 logger 封装结果一个会话遵守了新约定另一个会话还在大量使用console.log最后合并代码时多花了二十分钟统一风格。所以我的经验是并行期间尽量冻结CLAUDE.md真要改得主动去所有会话里人工补一句提示。2.3 上下文窗口是白板不是无限内存理解并行开发的第三个地基概念是上下文窗口的有限性。把你和模型的这次对话想象成一块白板白板面积就是窗口大小已经写过的内容不会自动消失直到窗口满了早期内容才会被擦掉或压缩。这解释了好多怪现象为什么一个会话跑得越久越容易忘记早期指令为什么任务一多、聊天一长回答质量会下降因为白板被占满了新写入的有用信息没有足够空间。而并行开发的隐藏红利就在这里——多个会话等于多块白板每块白板只写各自任务的内容单块白板的信息密度高得多模型对任务重点的把握也稳得多。我自己用过最有说服力的对照同样一个半小时的连续开发单会话跑了四个小需求到后面它甚至开始重复问这个函数的返回类型你确认过吗拆成两个会话各跑两个需求几乎没出现这种反复确认的情况。原因很简单每块白板上的内容都更干净模型不需要在噪音里捞重点。3. 拆任务的三条标准什么活适合并行什么活必须排队3.1 标准一文件边界清晰改动的代码集合不重叠拆任务前先问自己如果让两个开发者同时开工他们会改同一批文件吗如果答案是会这个任务就不能简单拆开并行。文件边界越清晰并行越安全。举例来说一个任务是给用户服务的 DTO 加字段并调整序列化另一个任务是重构支付回调模块的日志记录。这两个任务涉及的文件集合基本不重叠并行起来很舒服。反之如果两个任务都要改同一个核心服务类的构造函数那就别并行或者先约定一个人改另一个等合并后再动。判断文件边界有个土办法先手动列一下每个任务预计会触碰的目录和文件然后画两张清单看看交集部分大不大。有交集能接受但交集必须是双方都能独立处理的比如都新增文件不互相改对方已有的代码如果交集集中在同一个核心文件且逻辑深度耦合就老老实实排成先后顺序。3.2 标准二依赖方向明确接口先行还是实现先行有些任务表面上文件不重叠但存在逻辑依赖。比如任务A要新增一个对外提供数据的接口任务B要根据这个接口写前端展示。两者文件不重叠但B依赖A的接口定义。这种依赖不处理好并行就是灾难——B做完了A突然说字段名要改B全部返工。处理办法有两种。第一种是接口先行先把接口契约定了两个会话都基于同一个契约开工A实现后端B mock 数据写前端。第二种是明确的先后顺序让A先做一小步把接口定义落盘B的会话再启动。我倾向于第二种因为消息落盘之后B会话读到的就是真实代码而不是对话里的口头约定。另外描述任务的时候要把依赖关系写清楚。比如B的启动指令里我会写明前端请求的字段以 auth-service 中已定义的 UserProfile 结构为准这样B即使在A还没完成实现时启动也知道该去找哪个定义而不是凭空发明字段。3.3 标准三变更可以隔离git 分支能兜住第三条标准是为突发情况兜底并行任务在版本控制层面要能隔离。我的常规操作是每个并行任务开一个独立分支。分支名直接对应任务名比如feature/user-profile-fields、fix/payment-logger。这不仅是管理习惯更是隔离风险的保险丝。有了分支兜底某个会话真的搞砸了直接把分支弃掉重来不会污染其他任务的进展。同时分支也能当多人协作的替身每个会话在自己分支上的改动一目了然合并前可以逐个分支git diff检查完了再合并到主分支。这里要注意分支隔离必须在会话启动之前就做好。我见过有人先在一个分支上启动了三个会话才想起来要建分支已经晚了——三个会话在工作目录里拿到的是同一批文件其中一个会话的改动就是其他会话工作区里的当前状态。隔离的底线是会话启动时工作目录必须是干净的基线分支上是各自任务的起点而不是别人改到一半的状态。4. 三路并行实操从启动指令到合并验证完整走一遍4.1 启动指令怎么写划定范围、约定输出、给验收标准并行开发里每个会话的启动指令决定了这个工作台的边界。我的写法分四段背景一句、任务范围、明确禁止项、交付验收标准。以前我经常只写帮我实现一下xx功能后来发现范围不够明确时它会自由发挥把相邻模块一起改了。现在我会写得更死板比如本次只处理 src/modules/order 目录下的订单状态流转逻辑。目标补充 inventory 扣减失败的补偿处理。禁止修改 payment、user 模块的任何文件禁止调整现有数据库结构。完成后列出改动文件清单并说明补偿逻辑的触发条件。我会给每个会话都起一个清晰的项目名当记忆锚点然后在所有会话的交流里反复使用同一个措辞。比如A会话每次提到任务都说订单补偿B会话说库存快照这样模型不容易把两个任务的概念搞混。虽然没有夸张到形成记忆隔离但至少语义上把会话引到各自的频道里了。实际启动时我在终端里分别开三个窗口进入同一个项目目录确认当前都在目标分支上再分别敲claude进入交互模式。这一步没啥技术含量但胜在仪式感干净的起点、清楚的口令、各自的分支后面所有问题都是从这个基线上长出的小分支好回溯。4.2 并行期间怎么同步不靠肉眼靠 git diff并行开发进行中我基本不依赖会话之间的实时沟通——因为我就是唯一的连接点。与其频繁把A会话的进度口头转述给B会话不如让进度沉淀到代码仓库里用git diff去看每个分支的状态。我习惯在每个子任务完成一个相对完整的阶段时让对应会话先停一下我在终端里跑一次git diff --stat看看改动文件列表再重点看几个关键文件的git diff全文。这一步有两个作用一是检查有没有越界改动比如明明说好只改 order 模块结果 auth 目录下多了文件二是提前发现可能冲突的信号趁改动小解决成本低。同步的节奏也有讲究。不用每隔十分钟就看一次那会打断你自己的状态比较好的节奏是按任务里程碑看比如当前阶段的接口定义完成核心逻辑写完自测通过这三个节点各看一次。这三个节点基本能覆盖掉大部分风险和冲突窗口。4.3 合并验证先把三份改动合起来再跑一次全量检查三路并行收尾时合并顺序很关键。我的顺序是先合并改动范围最小、确定性最高的分支再合并改动范围大的每个分支合并完立刻跑一次针对性的编译或单测确认没问题再合并下一个。避免三个分支一次性合进来出了问题根本不知道该往哪个分支追溯。全部合并到主干之后还要做一次全量验证。并行开发里最怕的就是分开都对合起来炸。比如A分支引入了一个新工具函数B分支恰好也在同一个文件里加了一个同名函数——单个分支上编译没问题合并后函数命名冲突直接崩在集成阶段。全量检查就是把这些问题暴露出来的唯一手段全量编译、全量测试、关键路径手工回归一个都不能省。如果是带交互界面的项目我会额外跑一遍手动冒烟测试把A、B、C三个任务相关的页面各点一遍重点看跨模块跳转有没有异常。这步没有捷径自动化测试覆盖率再高也覆盖不到三个功能在同一个页面上相遇的视觉与交互问题。5. 最容易翻车的两个点同文件冲突和上下文失控5.1 翻车A两个会话改了同一段逻辑并行最大的翻车现场就是同文件冲突。我自己遇到过两个任务一个要改订单状态机的状态枚举另一个要扩展订单查询的过滤条件看起来八竿子打不着实际都碰了同一个模型文件——一个改了字段定义一个改了查询映射合并的时候冲突提示密密麻麻。这类冲突的本质是文件边界清单画得不够细。我只写了目录级别的边界没精确到文件。后来我学乖了拆任务时把核心文件也列进边界说明里。比如订单状态机涉及models/order.ts、services/orderStatus.ts这两个核心文件我会让A任务只碰状态流转逻辑限制它改services下的文件B任务只碰查询映射限制它改repositories下的文件。边界画到文件级之后冲突率明显下降。真碰上冲突了也别慌。我的处置顺序是先在主干上合并之前分别跑git log --oneline确认每个分支的提交点然后打开发生冲突的文件按谁的改动更基础谁优先的原则手工整理。注意手工整理时千万别图省事直接把某一方的整块代码删掉要逐段看保留两边都合理的部分。5.2 翻车B会话越长越蠢最后忘掉约束第二个高频翻车点是上下文失控。表现非常典型一开始很听话各种约束都记得跑了一个多小时后开始频繁反问一些启动指令里已经写明的问题再过一阵它甚至会把另一个任务里的技术方案当成当前任务的方案来用因为那些内容可能出现在当前项目文件里被它误读为需求。我清楚记得有一次一个会话明明在启动指令里写了不要动公共类型定义结果跑着跑着它主动去改了一个公共接口文件理由是日志格式需要调整。改完还把测试跑绿了——但它根本不该碰那个文件。这个问题的根因还是白板被写满了早期的约束指令被挤出窗口模型只能靠当前环境的线索做判断。处理方式是防患于未然如果预感到会话要长跑我就把关键约束定期在对话中重申一次或者更干脆——在任务到一个阶段时主动清理上下文。/clear或/compact这类操作能显著改善后续质量代价是模型会忘掉细节所以清理前要让它把当前进展和结论先写到一个文件里等于把白板内容导出成磁盘笔记换一块新白板继续写。5.3 冲突排查链路从 git diff 倒推到初始指令当问题真的出现乱猜没意义按链路排查最省时间。我的固定顺序是先看git diff定位改动来源再对每个diff判断它属于哪个任务的预期产出如果diff里有明显不该出现的改动就打开对应会话的启动指令看看是边界描述不清还是这个会话压根没遵守边界。有一次我发现主分支上混进了一处不该有的配置项修改三个会话都声称不是自己改的。用git log -p -- 配置文件路径查提交历史马上定位到是B会话在完成分支合并前顺手改的。为什么它会改翻它的启动指令才发现我在指令里写了一句顺便把缓存配置检查一下这句模糊描述被它理解成了把缓存配置调整为更推荐的方式。从那以后我启动指令里的任何非核心语句都写得非常克制避免出现顺便如果可以这类开放描述。排查链路里的核心原则是代码问题先归因到会话会话问题先归因到指令。不要上来就怪模型笨绝大多数翻车都能倒推回一句边界模糊的话或一个没分开的分支。6. 复盘一次三任务并行省了多少时间又踩了什么坑6.1 实际收益时间账和心理账拿最近一次小改造当例子。任务A给用户资料接口增加两个可选字段任务B修复导出功能在空数据时的报错任务C给新增字段补上测试用例。三个任务在一个下午内并行完成串行估算大约需要一个半工作日。时间账是最直观的拆成三个会话后真正高效的并行窗口大约3小时。A和B在互相不干扰的目录里推进C在A的字段定义落盘后启动等于一条小流水线。我在三个窗口之间切换的等待时间加起来不到二十分钟整个下午几乎没有干坐着等AI的空档。心理账比时间账更值钱。串行的时候任务列表像一根绳子上拴着的三个球前一个不落地后一个就无法安心并行的会话给我一种工作台各自运转的感觉每个任务都有自己的进度即使某一个卡住了另外两个还在推进焦虑感明显降低。这在多需求并行冲刺时是很实际的情绪价值。6.2 后续改进先拆任务再开会话最后才写指令复盘下来我自己最大的改进是流程顺序。以前是打开终端一边想一边把任务扔给会话现在是先在纸上拆任务再画文件边界再决定分支策略最后才写启动指令。拆任务的时间成本大概多花10到15分钟但对后面节省的时间来说回报非常高。另外我养成了一个习惯每个并行会话结束时都让它把最终结论、改动文件清单、以及哪些地方按直觉做了决定写进一段短记录里。这既方便我合并时对照检查也为后面万一要重开会话留下了可读的交接材料。记录不需要长一屏以内最好核心是让结论脱离会话本身存活。6.3 什么场景不建议并行也不是所有任务都适合并行。探索性任务要谨慎如果一个需求连你自己都没想清楚到底要什么指望并行会话帮你试错往往是一个会话试一个方向最后合并时发现方向互相矛盾。我自己踩过一次浪费时间的探索型并行同一个页面的改版两个会话给出了两套完全不同的信息架构最后我不得不二选一另一套方案白做。反过来确定性任务——实现方案清楚、输入输出可预期、代码边界明确的活——才是并行开发的最佳对象。如果需求还在摸索期先串行试一个小方向等方案定型了再拆分并行效率和结果都会更好。另一个不建议并行的情况是你需要和模型进行深度连续讨论一个问题的答案会不断修正你对下一个问题的提问方向。这种边聊边想的任务拆开会话等于拆断了思考的连续性并行没有任何优势老老实实开一个长会话聊透再说。在实际操作里我越来越觉得多任务并行开发拼的不是工具技巧而是任务拆解能力。Claude Code 只是把能不能同时开工这件事变成了现实但拆得好不好、边界画得清不清楚、分支兜不兜得住全靠开发者在开工前那十分钟的准备。下一篇笔记我打算整理一套自己的任务拆分检查清单把这次的经验固化成可复用的模板免得每次全靠感觉来。