一个人指挥一支 AI 舰队:多会话并行、Worktree、Fan-out 与自动化

EP4 把一个会话配成了顺手的工作台;但工作台再顺手,产能仍卡在一条串行的线上——再快,一个会话也只是「一个人」——你给一个任务,等它做完,再给下一个。当你眼前堆着五个互不相关的任务,却只能排队,产能就卡在这里。真正的最后一跳,是从「用一个 AI」变成「指挥一支 AI 舰队」:多会话并行、子代理 fan-out、Worktree 隔离、无人值守自动化。

但先说最重要的一句:舰队不是越多越好。这篇既讲怎么把舰队开起来,也讲一个老手才懂的事——什么时候多开,只是在自我消耗。

从一个会话到多个

单会话的瓶颈不是 AI 的速度,而是它的串行:一次只推进一件事。突破口有两个方向:子代理(主会话派下属去并行干活,见 EP3)和多会话(同时开几个独立的 Claude Code,各做各的)。两者共同的前提是:任务彼此独立——这是能不能并行的分水岭。

Fan-out:把独立任务铺开

最典型的并行场景是 fan-out:一批相似又彼此独立的任务,分给多个子代理同时做,再汇总。比如「给这 8 个接口各写一份测试」「把这个 API 改动同步到 5 个调用方」。每个子任务在自己的上下文里跑,互不干扰,wall-clock 时间从「N 件之和」压到「最慢那一件」。这篇文章所在的系列,初稿就是用这种方式铺开的——主会话定结构,子任务并行成稿,主会话统一校验。

Worktree:让并行不打架

Writer / Reviewer:用 AI 审 AI

自动化:headless 与 CI

什么时候并行,什么时候别

这是最容易被忽略、也最值钱的判断。并行省的是 wall-clock 时间,但它加重你的认知负载:你要同时跟踪几条线、合并几份结果、处理几个分支。所以:

• 适合并行:任务彼此独立、各自能自验证、你不需要在中途频繁拍板(fan-out 测试、批量改造、多方案探索)。
• 不该并行:任务强依赖(B 要等 A 的结果)、需要你密集决策、或你自己都还没想清方向。这种时候开第二个、第三个会话,只会让你在几个窗口间疲于奔命——正如社区那句广为流传的话:别为了提效再开一个 cc 并行,会累死自己。

并行是工具,不是目的。 先问一句「这些任务真的独立吗」,再决定开几条线。

当你真的指挥起一支舰队,会发现新的瓶颈不再是 AI 的算力,而是你自己——你能不能把要做的事说得足够清楚,让几条线不会并行地跑偏。下一篇,我们练这门最被低估的功夫:沟通。