同时开着五六个 Claude Code 窗口，每个都在跑不同任务，这种场景我太熟了。早上接了个紧急 bug，让一个实例去定位线上问题；下午还要重构登录模块，又开了一个实例；晚上想让 Claude 帮我把接口测试补齐，顺手再开一个。结果一小时过去，我自己都分不清哪个窗口对应哪个任务，想继续上午那个 bug 排查时，claude默认又给我开了一个全新会话，之前聊到哪一步完全想不起来。
这种“多实例管理混乱”不是偶发，而是所有重度使用 Claude Code 的人迟早要面对的问题。窗口一多，会话层找不到任务、文件层互相覆盖、心智层记不住进度，三个层面一起乱，效率还不如单开一个实例慢慢磨。这篇文章把我实际验证过的 5 种管理方案一次性讲清楚：从最简单的目录隔离，到 CLAUDE.md 记忆卡，再到 Git worktree、Tmux 和队列脚本。每种方案我都会讲清它解决什么问题、怎么操作、边界在哪。适合所有正在用 Claude Code 做日常开发、手上同时有两三个以上任务的人。
1. 多实例混乱的根源
1.1 典型场景：为什么你会同时跑多个 Claude Code
我身边用 Claude Code 的同事，基本逃不过三种情况。
第一种是并行任务驱动。早上收到一个线上告警，需要立刻排查；同时手上的新需求开发又不能停。这种时候你会很自然地开两个实例：一个专心修 bug，一个继续写功能。如果再叠加上下午的代码评审、文档整理，三四个实例同时挂着就很常见。
第二种是大任务拆分。一个大型重构涉及鉴权、订单、日志三个模块，如果只开一个实例，上下文窗口很快会被塞满，早期的需求描述、技术约束全被挤到“失忆区”。拆成三个实例，一个模块一个实例，每个实例的上下文都干净，任务之间也不会互相干扰。
第三种是角色分离。同一个代码库，既想让 Claude 写新代码，又想让它在另一个实例里做 code review。同一份代码，写和审放在一个会话里很容易立场混淆，分开反而更清晰。
多个实例并行跑是刚需，不是炫技。但问题在于：Claude Code 默认情况下每个实例都是独立的，它不知道自己还有“兄弟”，也不知道别的实例改了什么文件。管理混乱几乎是必然的。
1.2 混乱的三个层面
我踩坑踩出来的经验是，多实例的混乱可以归结为三个层面，而且这三个层面往往是叠加出现的。
会话层混乱。claude默认启动的是新会话，想接着上次的对话继续，得主动用--continue或--resume。多个实例同时开着的时候，你会忘记哪个窗口对应哪个任务，甚至同一个任务开过不止一个会话，历史记录散落各处。这是最轻的一层，但已经足够让人头疼。
文件层混乱。两个实例同时在同一个工作目录里改代码，A 生成的代码覆盖了 B 的修改，或者两个实例各自生成了同一份文件的冲突版本，等你发现的时候，代码已经乱成一团。Claude Code 本身不做文件级冲突检测，它只认“当前工作区的状态”。
心智层混乱。最麻烦的是你自己都记不清每个任务的进度：这个实例改到哪了？那个实例有没有通过测试？下一个该给谁派活？当多个实例并行时，它们各自的状态储存在各自的会话历史里，没有任何一个地方能一眼看到全局。这种认知负担，比会话丢失和文件冲突更耗精力。
1.3 管理的本质：上下文隔离与状态追踪
想清楚这个问题之后，我发现所谓“多实例管理”，归根结底就两件事：上下文隔离和状态追踪。
上下文隔离，指的是每个 Claude Code 实例都只跟它负责的那一部分内容打交道。目录隔离、Git worktree、CLAUDE.md 记忆卡，本质都是在做这件事。它的作用是防止任务之间串味——修 bug 的实例不会突然去动新功能的代码，写鉴权模块的实例不会把订单模块的逻辑也改了。
状态追踪，指的是你随时能知道每个实例当前在干什么、干到哪一步了、之前做了什么决策。Tmux 窗口命名、会话 ID 管理、日志归档，都是在做这件事。它的作用是让你不用一个个点开窗口去翻对话历史，就能对全局有掌控。
一个贴切的类比：多个 Claude Code 就像是多个很有干劲但记性不好的新同事。你作为负责人，要么给他们分独立的工位（目录），要么每人发一本工作手册（CLAUDE.md），要么明确划分责任区（worktree），要么在大厅挂一块总控屏（Tmux），要么干脆排一个值班表（队列脚本）。下面这五种方案，就是这几个思路的具体落地。
2. 方案一：一个任务一个目录，用 --session-id 钉死会话
2.1 目录即工作区：最低成本的隔离方式
最简单也最有效的方案，是给每个任务建一个独立目录。Claude Code 在这一层目录里启动，它读文件、写文件、生成代码时，默认都只在这个目录范围内活动。多个实例各自守着自己的小地盘，天然就做了上下文隔离，谁也不会动谁的代码。
我自己的习惯是在~/workspace下面按任务建目录：
~/workspace/ auth-refactor-0115/ order-test-0115/ log-fix-0115/每个目录对应一个任务，目录名就是任务名加日期。要开工了，直接进目录启动 Claude Code：
cd ~/workspace/auth-refactor-0115 claude这样多个实例同时跑，每个实例看到的文件结构都是独立的一份，不会出现 A 实例生成的代码出现在 B 实例工作区里的情况。
2.2 用 --session-id 给会话一个可管理的名字
目录隔离解决的是文件层问题，会话层还需要另外一招：用--session-id显式指定会话 ID。
Claude Code 默认会自动生成随机会话 ID，看起来是一串没什么规律的数字字母。多个实例跑起来之后，你根本分不清哪串 ID 对应哪个任务。但如果你在启动的时候手动传入一个可读的 ID，情况就完全不一样了：
cd ~/workspace/auth-refactor-0115 claude --session-id auth-refactor-0115之后想恢复这个会话，用同一个命令进来的就是同一个上下文。这个 ID 相当于给会话起了个名字，你在claude --resume的会话列表里一眼就能认出来。
我实际用下来，自定义 session-id 还有一个额外的好处：可以配合脚本动态生成，比如按“任务名-日期”拼接，甚至加上序号：
claude --session-id "auth-$(date +%Y%m%d)"这样即使同一个任务每天都会开新会话，旧会话也不会丢失，而且从 ID 上就能看出是几号跑的。
2.3 为什么 --session-id 比 --continue 更可控
--continue（别名-c）的作用是继续最近的会话，确实能省去不少操作。但它有一个隐含的问题：它会恢复“最近的那一个”会话。如果你同时跑了好几个实例，最近的那个不一定是你想继续的那个。用--session-id把会话和任务绑定，就完全避免了这种歧义。
两者的适用场景也不同。-c适合快速续接，比如你刚让 Claude 改了段代码，中途去接了电话，回来敲一句claude -c就能接着聊。而--session-id适合长期跟踪的多任务场景，它更像是一个任务档案，打开就是那个任务专属的上下文，不带任何杂质。
如果要把这个方案脚本化，我会在 shell 配置里加一个简单函数：
function cc() { local name="$1" shift claude --session-id "$name" "$@" }然后直接输入cc auth-refactor "继续重构登录模块"，既指定了会话，又直接输出了新指令。这个函数我用了很久，比反复敲完整参数顺手得多。
2.4 目录隔离的边界
这个方案最大的优点是门槛低，几乎不增加任何额外操作。但它有两个明显的边界，需要提前意识到。
第一个边界是，它解决不了同仓库多任务并行时的代码冲突。如果两个任务在同一个 Git 仓库的不同分支开发，只是各自开了一个目录去复制代码，代码同步会变成噩梦。这种场景需要往下看方案三（Git worktree）。
第二个边界是，目录隔离管的是“空间”，管不了“时间”。一个目录里的会话时间长了，早期需求仍然会被上下文窗口挤掉，Claude 仍然可能忘记最开始定的约束。这个问题要靠方案二（CLAUDE.md）来兜底。
3. 方案二：把需求写进 CLAUDE.md，给每个实例配一张“记忆卡”
3.1 上下文丢失的本质
Claude Code 的“记忆”来自两个地方：当前会话的对话历史和项目里的 CLAUDE.md 文件。对话历史是动态的、逐条累积的；CLAUDE.md 是静态的、每次会话开始都会被读入的。
问题恰恰出在对话历史上。当一个会话跑得足够长，累积的 token 数超过上下文窗口后，模型对早期内容的关注度会下降，甚至完全遗忘。我实际遇到过：让 Claude 改登录接口的鉴权逻辑，它在对话前十分钟还知道“不能改数据库表结构”，聊了半小时后，直接给我生成了一条ALTER TABLE。不是它变笨了，而是早期约束被挤出了有效上下文。
这时候解决方案就清晰了：把关键信息从“对话历史”这个易失存储，搬到 CLAUDE.md 这个持久存储里。每个实例启动时，Claude 会优先读取项目目录下的 CLAUDE.md，相当于给每个实例配了一张写满重点的卡片。只要卡片在，即使换一个新实例，它也能快速接续上下文。
3.2 任务级 CLAUDE.md 的标准模板
目录隔离方案配合 CLAUDE.md，效果是 1+1>2。每个任务目录下放一份任务专属的 CLAUDE.md，内容按照“目标、约束、验收标准、当前进度”四个维度组织。我常用的模板长这样：
# 任务：重构用户鉴权模块 ## 目标 - 将当前基于 session 的鉴权改为 JWT - 保持现有 API 路径不变 ## 约束 - 不允许修改数据库表结构 - 新 token 需要兼容旧 token 一周 ## 验收标准 - 所有鉴权相关接口测试通过 - JWT 签发与校验代码有单元测试覆盖 ## 当前进度 - 已完成：登录接口改造 - 进行中：刷新 token 逻辑 - 待办：退出登录时吊销 token这个模板的价值在于它把“一个任务应该是什么样的”具象化了。目标让 Claude 知道要做什么；约束让它知道不能踩什么红线；验收标准让它知道什么时候算完；当前进度让新实例能接续旧实例的工作。
3.3 全局配置、项目配置、本地配置的优先级
Claude Code 支持多个层级的 CLAUDE.md，我建议优先使用项目目录下的那一份。它的查找范围包括：项目根目录的CLAUDE.md、用户目录的~/.claude/CLAUDE.md，以及本地的CLAUDE.local.md。
个人经验是：不要把个人偏好写进全局配置。全局 CLAUDE.md 会影响你电脑上跑的所有实例，比如“代码风格统一用 2 空格缩进”“提交信息用中文”这类规则放全局没问题；但“当前任务的技术方案”“本次重构的验收标准”这类任务级信息，必须放进各自任务目录下的局部 CLAUDE.md。
CLAUDE.local.md是本地私有文件，默认不进 Git，适合放一些敏感信息或临时决策。我通常把“当前进度”写在里面，这样任务的动态状态不会被提交到仓库，也不怕影响其他协作者。
3.4 一个反面教材
我最早没意识到 CLAUDE.md 的重要性，所有要求都在对话框里口头交代。有一次让 Claude 改一个批量任务脚本，我在对话里强调“不要用第三方库”，结果上下文一长，它坚持认为requests库是最佳方案，还跟我争论了两轮。后来我把“禁用第三方库，只用标准库”这句写进了 CLAUDE.md，它在之后的几轮修改里一次都没再提过第三方库的事。
踩了几次坑之后，我总结了三条经验。重要约束至少出现两次：在对话里强调一次，在 CLAUDE.md 里固化一次。任务启动时先把 CLAUDE.md 写完整，再开始对话，而不是聊到一半才补。每次任务结束，在“当前进度”里更新状态，这样哪怕换新实例，也能无缝接续。
4. 方案三：Git worktree 并行工作区
4.1 同样是多个任务，为什么要用 worktree
如果你有多个任务需要同时开工，但都发生在同一个 Git 仓库里，目录隔离方案就不够用了。更常见的做法是开多个分支：主分支上留着稳定的代码，每个任务开一个 feature 分支。但这里有个很现实的问题：一个工作目录在同一时间只能 checkout 一个分支。
假设你正在 feature/auth 分支上跑一个 Claude Code 实例，突然想在主分支上快速验证一个 bug。这时候你只能停下来，把工作目录切回主分支。切过去之后，feature/auth 分支上改了一半的文件全部从工作区消失了，正在跑的那个 Claude Code 实例可能会对着不存在的文件继续生成代码，结果可想而知。
Git worktree 就是为了解决这个场景设计的。它允许同一个仓库在不同的目录下同时 checkout 出多个分支，每个目录是一个独立的工作区，互不干扰。一个跑 feature/auth，一个跑 feature/order，一个跑主分支的 bugfix，同时进行，谁也不用等谁。
4.2 标准操作流程
使用 worktree 的流程非常直接。先从主目录创建一个新工作区：
cd ~/repo git worktree add ../repo-auth-refactor -b feature/auth-refactor这条命令会创建一个新目录../repo-auth-refactor，在这个目录里初始化一个新的分支feature/auth-refactor。然后进入这个目录，启动 Claude Code：
cd ../repo-auth-refactor claude --session-id auth-refactor这个实例会在独立的目录、独立的分支上工作，和主工作区的实例完全隔离。改完代码之后，按正常的 Git 流程提交推送：
cd ../repo-auth-refactor git add -A git commit -m "refactor: auth module JWT 改造" git push origin feature/auth-refactor确认分支合并之后，清理掉这个 worktree：
cd ~/repo git worktree remove ../repo-auth-refactor一个容易踩的坑：如果 worktree 里有未提交的改动，git worktree remove会报错。我一般会在列出所有 worktree 时确认状态：
git worktree list然后先处理掉未提交内容，再做清理。
4.3 和目录隔离方案叠加使用
在实战中，worktree 通常和方案一、方案二叠加使用，而不是替代。我的固定套路是：先决定任务要不要动同一个仓库的代码。如果不动，用普通的目录隔离就行；如果要动，而且任务之间分支冲突风险高，就上 worktree。
一个典型的多层组合是这样：worktree 负责代码层面的隔离，把每个任务的工作区钉在不同分支；--session-id负责会话层面的隔离，继续用任务名定义会话；CLAUDE.md 负责上下文层面的持久化，保证每个实例记得自己的任务目标。
三层叠加之后，哪怕同时跑四五个实例，每个实例的工作目录、会话上下文、任务记忆都是完全独立的，几乎不会出现串扰。这套组合我用了相当长一段时间，稳定性很高。
需要注意：worktree 会占用额外的磁盘空间，因为每个工作区都有一份完整的文件副本。如果仓库很大、任务很多，磁盘消耗需要提前评估。另外，同一个仓库的 worktree 共享同一个.git目录，分支的引用是全局的，所以在某个 worktree 里切分支、删分支要谨慎，避免影响其他工作区的运行状态。
5. 方案四：Tmux 多会话管理，把终端变成“任务驾驶舱”
5.1 为什么需要 Tmux
目录隔离和 worktree 管的是“文件夹层面的隔离”，CLAUDE.md 管的是“记忆层面的隔离”，但还有一个很实际的问题没解决：你的终端窗口越来越多，怎么快速切换、怎么一眼看清谁是谁？
同时开六个终端标签页，每个标签页里跑一个 Claude Code 实例，确实看起来“并行”了。但标签页一多，你很难记住哪个标签是哪个任务，更难受的是，关掉终端窗口之后，里面跑的进程也就没了。万一 Claude Code 正在生成一段长代码，你误关了标签页，进度全丢。
Tmux 解决的就是这两件事：路径记忆和进程驻留。它允许你在一个终端窗口里开多个“面板”，每个面板独立跑进程，面板可以命名，可以快速切换。更关键的是，Tmux 会话可以脱离（detach）当前终端，进程继续在后台跑；下次打开终端，重新附加（attach）回去，界面原样恢复。
5.2 基础命令和我的布局习惯
Tmux 上手并不难，我日常只用到几个命令：
# 新建一个名为 claude-main 的会话 tmux new -s claude-main # 在会话里新建窗口，并命名为 auth tmux new-window -t claude-main -n auth # 重新附加到会话 tmux attach -t claude-main # 列出所有会话 tmux ls创建好会话之后，具体的操作通过快捷键完成：
Ctrl-b c：新建窗口Ctrl-b ,：重命名当前窗口Ctrl-b n/Ctrl-b p：切换下一个 / 上一个窗口Ctrl-b d：脱离当前会话（进程继续跑）
我自己的布局习惯是：一个 Tmux 会话专门服务“某一天的开发任务”，会话名用日期命名；会话里面按任务名开窗口，每个窗口跑一个 Claude Code 实例。窗口名直接用任务简称，比如auth、order-test、log-fix，配合会话名claude-0115，一眼就能看出是 1 月 15 日的鉴权重构。
5.3 命名规范和脱离恢复
命名规范是 Tmux 方案能否好用的关键。窗口名必须包含任务信息和日期，像claude-auth-0115、claude-order-0115这样，而不是默认的bash或者zsh。重新命名窗口只花两秒，但能让你一整天都省去反复切换确认的麻烦。
脱离（detach）和重新附加（attach）是 Tmux 最实用的特性。比如你在办公室电脑上开好了三个 Claude Code 实例，下班锁屏后进程不会退出；第二天回到工位，tmux attach -t claude-0115就能全部恢复。如果哪天attach时报找不到会话，先执行tmux ls确认会话名字有没有打错。我经常记错会话名，多亏tmux ls兜底。
另外提醒一个细节：默认配置下，新开的 Tmux 窗口会继承之前窗口的环境变量和工作目录。我在每个窗口启动 Claude Code 时，都会先cd到对应的工作目录，再用--session-id指定会话。如果忘了cd，Claude Code 可能会把代码生成到错误的位置，这是容易忽略却又影响很大的坑。
6. 方案五：队列脚本 + 日志归档，让任务自动排队跑
6.1 手动编排的极限在哪里
方案一到方案四，本质上还是在“人肉管理多个实例”。但当任务量再上一个台阶时，手动操作就扛不住了。比如要对十几个接口各写一组单元测试，或者批量生成一批文档。这种场景可以交给队列脚本，让 Claude Code 按照顺序逐个执行，不需要你盯着每个实例。
核心思路很简单：写一个脚本，读入任务列表，循环启动claude执行每个任务，输出结果保存到日志文件。脚本帮我们做三件事：按顺序执行、留档可查、失败可重跑。
6.2 一个可复制的 bash 队列脚本
这里给一个我实际在用的模板，脚本会依次读取tasks.txt里的每行任务，逐个交给 Claude Code 处理：
#!/bin/bash # task-queue.sh —— 顺序执行任务队列 mkdir -p logs i=0 while IFS= read -r task; do i=$((i+1)) [ -z "$task" ] && continue echo "=== 任务 $i: $task ===" claude -c "$task" --output-format stream-json \ >> "logs/task-$i.log" 2>&1 \ || echo "任务 $i 执行失败，请检查 logs/task-$i.log" done < tasks.txt任务列表文件tasks.txt的格式就是每行一个任务描述：
为登录接口补充单元测试 为注册接口补充单元测试 为刷新 token 接口补充单元测试执行时先写好任务清单，再运行脚本：
bash task-queue.sh脚本有几个细节值得说明。-c表示继续最近会话，适合这种无状态的独立小任务；如果任务有独立性，也可以改成claude不带-c，每次开新会话，避免上下文串扰。--output-format stream-json输出的是结构化日志，方便后续用脚本解析，而不是读一堆夹杂着转义字符的原始输出。2>&1把标准错误也一起重定向到日志，这样报错信息不会漏。
6.3 日志归档、失败重跑和并发控制
日志是整个队列方案的灵魂。每个任务一份独立日志，复盘时只要搜一下grep -i error logs/task-*.log，就能快速定位哪几个任务失败、失败原因是什么。成功与失败全都有迹可循。
任务失败后重跑也很方便：先看失败日志，把出问题的任务行单独抽出来再执行一次，不用整个队列重新跑。比如task-3.log失败，就直接重新执行第 3 行的任务描述即可。
关于并发，上面脚本是串行执行，token 消耗相对平稳，不会一下子冲到很夸张的量。如果你想让多个任务同时跑，可以简单加一个&或者在循环里用xargs -P。但我不太建议并发数开太高，一方面 API 有限流，另一方面多个实例同时跑，上下文和文件互相干扰的概率会变大。我自己实践下来，队列脚本跑 3 个以内并发是最稳的，超过之后收益就开始下降了。
7. 常见问题与排查技巧实录
7.1 会话失忆，答非所问
现象特别典型：Claude Code 聊到一半，突然不记得最开始的需求了，甚至会推翻自己前面的结论。
原因基本是上下文窗口被占满，早期信息被压缩或丢弃。排查时先确认会话已经跑了多久、输入了多少 token。解决路径有三条：提前把关键约束写进项目 CLAUDE.md，让记忆从“对话历史”迁移到“持久文件”；用/compact压缩当前会话，把历史摘要化；或者直接拆任务，不要把三四个需求塞在同一个会话里。
我自己最常用的是前两条组合。任务启动时就把约束写进 CLAUDE.md，中间如果发现上下文太长，执行一次压缩，会话还能继续用，不需要另开新实例。
7.2 两个实例同时改同一个文件
这个问题的表现是：A 实例刚生成完代码，B 实例覆盖了它的修改；或者两个实例各自生成了同一份文件的冲突版本，后写入的把先写入的冲掉了。
Claude Code 没有内置文件锁，它看到的是“当前工作区的状态”，并不知道另一个实例正在生成内容。解决办法是提前隔离：同一文件尽量只让一个实例负责；跨任务共享的文件，用 Git 分支和 worktree 把工作区拆开；如果必须共享，至少让两个实例分时操作，比如一个任务跑完再跑下一个。
另外一个细节：如果两个实例在同一个目录里跑，后启动的实例可能读取到前一个实例生成的半成品文件，然后在此基础上继续修改，导致逻辑混乱。目录隔离方案能直接化解这类问题。
7.3 token 消耗失控
同时跑多个实例，最直观的副作用是费用。每次对话都要计费，上下文越长、重试越多，消耗越大。有时候跑一晚上，第二天发现 token 用量远超预期。
排查思路是给每个任务设置“完工标准”，任务完成的实例及时结束，不要一直挂着。批量任务的场景，用队列脚本限制并发数量，让任务一个一个来。简单任务可以指定轻量模型处理，没必要所有实例都用最强模型。实话说，这个坑我踩了不止一次，现在多实例方案跑起来之前，我第一件事是确认每个实例都有明确的结束条件。
7.4 资源占用过高和进程清理
多个 Claude Code 同时跑，内存和 CPU 占用会明显上涨。排查方法：tmux ls看有哪些会话还开着，ps aux | grep claude看实际进程。确认哪些任务已经完成，直接关掉对应窗口或杀掉进程。
这里有个小技巧：如果你用 Tmux 管会话，可以顺手把不用的窗口关掉，而不是让它们一直挂在后台。Tmux 窗口本身不占多少资源，但里面跑的 Claude Code 进程会占。空闲时我会定时做一次“清理巡检”，把已经交付任务的实例全部收掉。
8. 五套方案怎么选，我的最终组合
8.1 一张表看透五套方案
| 方案 | 核心解决的问题 | 适用场景 | 上手指引 |
|---|---|---|---|
目录隔离 +--session-id | 会话找不到、文件串台 | 2-3 个独立小任务，任务间不共享代码库 | 门槛最低，当天就能用起来 |
| CLAUDE.md 记忆卡 | 上下文遗忘、需求漂移 | 所有多实例场景，尤其是长任务 | 花十分钟写好文件即可 |
| Git worktree | 同仓库多分支并行、代码冲突 | 同一个代码库多个 feature 并行开发 | 熟悉 Git 命令即可上手 |
| Tmux | 窗口切换混乱、进程驻留 | 终端重度用户、长时间挂机任务 | 记几个快捷键就能提速 |
| 队列脚本 + 日志 | 批量任务手动编排太累 | 十几个独立小任务，自动排队执行 | 有一定脚本基础，最好有日志习惯 |
8.2 我实际在跑的推荐组合
不同阶段用不同组合，不用一次全上。如果刚开始接触多实例，只做目录隔离加--session-id就够了，问题先解决 80%。
如果你已经稳定用 Claude Code 做日常开发了，我的核心组合是：目录隔离 +--session-id管会话，CLAUDE.md 管记忆，worktree 管同仓库多分支。这个组合覆盖了绝大部分需求，日常最多同时跑三四个实例，不会乱。
如果你经常批量处理重复性任务，再加一个队列脚本，把“人肉开多个实例”改成“脚本按顺序调度”。Tmux 则是终端管理层的兜底，当你的终端窗口数量开始失控时，它就是最后的秩序。
8.3 一个让多实例真正“各自为政”的小技巧
最后分享一个我多次受益的操作：在每份任务级 CLAUDE.md 里，加上一句“完成后把关键结论写进docs/decision.md”。
这句指令的效果是：每个实例在跑完任务后，会主动把技术选型、遇到的问题、最终方案写成一个决策记录。第二天哪怕我不在现场，打开docs/decision.md就能看到每个任务做了什么、为什么这么做。多实例并行开发最怕的就是状态断档，这个习惯直接补上了最后一块短板。
跑多实例这件事，本质上不是工具不够强，而是工作流没有跟上工具的强度。把这五套方案按自己的场景组合起来，你也能让多个 Claude Code 各司其职、互不打扰。
