第 10 章的批量 fan-out 侧重脚本与子代理自动并行;本节聚焦由人协调的多个会话:何时并行、如何隔离改动、如何让各会话产出可合并且不冲突的结果。
一、适合并行的任务类型
| 适合并行 | 不适合并行 |
| 彼此独立的子功能、独立模块改造 | 强耦合、共享同一可变文件/接口的改动 |
| 一路调研探索、一路实现编码 | 需要连续上下文逐步推理的复杂调试 |
| 作者实现与独立审查(新鲜上下文复核) | 多个会话同时争抢同一分支或工作区 |
| 多份文档、多个目录的同类处理 | 尚未稳定、提示与方案仍在快速变化的早期探索 |
二、隔离手段:独立工作副本是关键
- 不同并行任务使用独立工作副本(worktree)或独立分支/目录,使文件改动互不覆盖;这是并行不冲突的前提。
- 每个会话有自己的上下文历史,避免把互不相关的探索结果塞进同一会话导致互相干扰与上下文膨胀。
- 会话之间需要交换结论时,用文件、清单或明确的中间产物传递,而不是依赖人工转述全部细节。
- 可按主题给会话命名(交互中使用命名命令),便于在多个会话间快速识别职责。
三、分工模式:Writer / Reviewer 分离
- 会话 A(作者)按方案实现并自测;会话 B(审查者)在新鲜上下文中针对指定范围审查缺陷、边界条件与一致性,不继承作者的思路倾向。
- 审查结论回传作者会话修订;也可让一个会话编写测试、另一个会话实现通过测试,形成双向校验。
- 审查会话应保持只读或受限权限,只产出意见,不直接改动作者分支。
四、避免冲突的协作约定
- 先切分边界:开始前明确每个会话负责的目录、文件与职责,边界不重叠。
- 各自验证:每个会话在自己的副本内跑通测试/构建,再进入合并环节。
- 统一基线:并行开始前基于同一最新代码基线;避免长时间分叉导致合并冲突放大。
- 产物落点清晰:约定中间结果、报告、清单写入固定位置,便于汇总去重。
- 收口合并:汇总阶段统一处理交叉引用、命名一致与集成测试,发现冲突回到对应会话解决,不现场拼凑。
五、何时应收敛为单会话
当多个任务开始争抢同一文件、需要频繁互相同步状态、或并行会话结论出现矛盾时,说明切分粒度过细或耦合度被低估;此时应收敛到单一主会话统一决策,再把可独立部分重新拆出。并行是手段,清晰、可合并的结果才是目标。
六、会话命名、接续与产物归档
- 并行会话职责不同时及时命名(交互中使用命名命令给会话起主题名),避免在多个会话间靠时间顺序辨认;需要恢复历史时,最近会话可用接续方式进入,历史会话可在会话列表中选择恢复。
- 每个并行会话的结论以文件落盘(调研笔记、改动清单、审查意见、测试结果),会话历史用于过程追溯,关键事实以文件为准,会话压缩或关闭后不丢失。
- 作者会话与审查会话分别建立、分别命名,审查只针对作者提交的改动范围;审查意见回写固定清单文件,供作者逐条关闭。
- 非交互批量调用默认仍会生成可恢复会话;若任务无需留存过程历史,可按需要关闭会话持久化以减少堆积(具体开关以当前版本官方文档为准)。
七、FAQ
| 问题 | 处理建议 |
| 两个会话都改了同一个共享文件导致冲突 | 并行前按文件/模块切边界,共享契约层由主会话统一;出现重叠改动先保留各自版本,回主会话合并评审,不在多个会话里互相覆盖。 |
| 审查会话看不出问题、作者自查又漏 | 审查限定明确范围(指定文件清单与验收点),并以只读方式运行测试/静态检查提供客观信号;人工审查与自动验证结合,不依赖单一视角。 |
| 会话开太多,上下文与时间成本上升 | 只对真正独立、可判定的单元并行;串行依赖、强耦合任务保持单会话;定期合并、归档并清理完成会话。 |
| 并行基线不一致导致合并后行为漂移 | 开始前统一到最新绿色基线,并行期间主分支有更新时先同步各副本再实现,减少长时间分叉带来的合并代价。 |
八、动手练习
- 练习:把一个中型任务拆成"调研 / 实现 / 审查"三个相互独立的角色,约定各自文件边界与产物落点,跑完后检查是否出现跨职责改动与合并冲突,复盘切分是否合理。
本节小结与下一节预告
本节掌握了并行会话的适用判断、隔离手段、命名与归档、冲突避免约定与 FAQ。下一节系统梳理权限模式、命令白名单与安全审计方法,把"能做什么"管清楚。