官方核心能力里有一条常被忽略：「支持同时创建和处理多个任务，适合并行完成不同工作」。这句话看着平淡，实际是效率杠杆——单条任务串行跑三件事，和三条任务并行跑，体感差别很大。但并行不是「无脑多开」，拆错了会互相覆盖、来回返工。本文讲怎么拆、怎么不打架、怎么验收。

🏗️先想清楚：并行的收益与代价

维度	串行（一条任务做完再做下一条）	并行（多条任务同时推进）
总时长	各步耗时相加	取决于最慢的那条
上下文	集中，前后文互相可见	各任务独立，看不到彼此的上下文
风险	低，方向错了随时能改	高，两条任务改同一个文件会互相覆盖
适合	有前后依赖的步骤	彼此独立、可分别验收的产出

结论很直接：并行的前提是「互不依赖 + 不碰同一份文件」。满足这两条，并行几乎只有好处；不满足，并行就是给自己制造返工。

✂️怎么切分：三种可用的切法

按交付物切（最推荐）

以「最终要交付什么」为边界切开，每个任务对应一个清晰产物。这种切法天然独立，验收也简单。

任务A：把 7 月的销售数据整理成 Excel，含环比列
任务B：把 8 月的销售数据整理成 Excel，含环比列
任务C：写一份两月对比的分析结论（Word）

注意 A、B 可以并行，C 必须等 A、B 完成——它依赖前两者的产出。这就是「有依赖的要串行」。

按目录 / 文件范围切

面向代码或文档批量处理时，按互不重叠的路径切。这是避免「互相覆盖」最直接的办法。

任务A：只处理 src/components/ 下的文件
任务B：只处理 src/utils/ 下的文件
任务C：只处理 docs/ 下的文档

反面例子：让任务 A 和任务 B 都去改 package.json——不管它们多聪明，最后写盘的一定覆盖先写的。这类共享文件应该合并成一个任务串行做。

按阶段流水线切（收益有限，谨慎用）

把「收集 → 处理 → 输出」拆成不同任务。听起来像流水线，但实际问题是：后一阶段依赖前一阶段的产出，并不会真的省时间，反而增加了在任务之间搬运信息的成本。只有当每个阶段本身耗时很长、且能被复用（例如「爬取」一次供多个下游用）时才值得。

🎯拆完之后：怎么描述任务

并行任务彼此看不到上下文，所以每条任务的描述必须自包含——不能写「像刚才那样处理」。官方在《创建任务》里建议优先补充四类信息，并行场景下更是必需：

• 目标是什么：要生成什么内容，或要处理什么文件；
• 输入是什么：需要分析的数据、参考的文档；
• 输出格式：Word、Excel、PPT 还是其他；
• 约束条件：风格要求、字数限制、截止时间等。

另外，官方《创建任务》还提供了几个实用手段，在并行场景里能显著降低「指错文件」的概率：

• 指定工作空间：点击输入框左下角的选择工作空间，为任务指定目录，WorkBuddy 会基于该目录读取和处理文件。并行任务务必各自指定清楚——这是避免误动的第一道闸。
• 引用上下文：通过 @ 引用文件、文档、规则等信息，把「要动的东西」明确指出来。
• 粘贴截图：Ctrl/Cmd + V 直接粘贴剪贴板里的图片。
• 上传文件：点上传按钮或拖拽文件到输入框。

🔗汇总与验收

并行任务的产出是分散的，最后必然有一个「收口」动作。建议固定三步：

1. 逐条验收：利用右侧结果区的「产物」页签，把每条任务的产出单独过一遍。别只看对话里的总结——官方把「结果交付与验收」列为核心能力之一，产物才是可验收的东西。
2. 一致性检查：并行任务最容易出的问题是「口径不一致」——同一个指标两种算法、同一种格式两种排版。收口时统一过一遍。
3. 合并成终稿：单独开一条任务做汇总（它能看到你给它的所有材料），或者在原任务里把产物拼起来。

⚠️并行最容易踩的四个坑

• 改同一个文件。最致命的一个。两条任务写同一份文件，后写的覆盖先写的，而且你往往到验收时才发现。解决办法只有一个：共享文件不要并行。
• 任务描述里有「如前所述」。并行任务没有共同上下文，「刚才那份数据」「上面那个方案」它都看不到。必须把输入明确指出来（工作空间 + @ 引用）。
• 把有依赖的步骤硬拆。「先定方案再实施」这种链条拆开并行，只会得到两条互相矛盾的结果。
• 开太多条。任务数量超过你能盯得住的数量，验收成本会超过并行省下的时间。经验值：同时活跃的任务控制在你能逐条复述目标的数量以内。