大任务编排·免费版

红线

• 接口先定死再并行：子任务的输出格式、命名、字段必须先约定，否则汇总时必然对不上。
• 不制造重复劳动：每个子任务必须有明确且不重叠的边界。
• 不丢失上下文：每个子任务都要带上足够的背景（子任务执行者看不到主会话）。
• 汇总不是拼接：必须去重、消解冲突、检查覆盖度，不能把结果直接堆在一起。
• 不引用任何付费端点/专有服务。

何时使用

• 任务范围明显超过单次处理能 comfortably 完成的量（如几十个文件、十几篇报告）。
• 子任务之间相对独立，可以并行推进。
• 一次做完容易后半段质量下降（上下文挤占/注意力衰减）。

反触发（不要用）：

• 任务本身不大 → 直接做，编排是额外开销。
• 子任务高度耦合、后一步完全依赖前一步结果 → 串行做完更简单。
• 需要严格一致性的创作（如一部小说的连贯叙事）→ 并行会风格割裂。

职责边界

• 做：拆分任务、画依赖图、定义接口、派发执行、汇总质检。
• 不做：替用户决定要不要拆、在信息不足时硬拆。

主流程

第 1 步：判断该不该拆（质检闸 A）

三个信号，满足两个就该拆：

> 质检闸 A：若子任务高度耦合 → 明确不建议并行，改建议分阶段串行。

第 2 步：定义统一接口（最关键，质检闸 B）

在派发前必须定死：

【输入契约】每个子任务拿到什么
  - 目标对象：<文件/主题/范围>
  - 背景包：<必须带上的上下文，子任务看不到主会话>

【输出契约】每个子任务交回什么
  - 格式：<如 Markdown，固定字段>
  - 字段：<如：结论 / 证据 / 风险 / 待确认>
  - 命名：<如 001_<对象名>.md>
  - 长度：<如有约束>

背景包必须自足：假设执行者对这个项目一无所知，把项目背景、
术语表、已有约定、质量标准全部写进去。

> 质检闸 B：输出契约没定死 → 不许派发。
> 这是并行任务最常见的失败原因：各子任务格式五花八门，汇总时全得重做。

第 3 步：拆分与画依赖图

拆分原则：

1. 按对象拆（最常见）：文件 A / 文件 B / 文件 C …
2. 按层拆：数据采集 → 处理 → 输出
3. 按视角拆：功能 / 安全 / 性能 / 文档

依赖图标注：

任务1（无依赖）──┐
任务2（无依赖）──┼──→ 汇总任务
任务3（依赖任务1）┘

• 标出哪些可并行（无依赖）、哪些必须串行（有依赖）
• 批次数 = 依赖图的层数

第 4 步：分批派发

• 同一批内的任务并行派发
• 每批完成后检查产出是否符合输出契约，不符合的重做/补齐
• 下一批依赖上一批结果时，先把上一批结论压缩成摘要再传入

批次规模：建议每批 3–7 个。太少效率低，太多难以把控质量。

第 5 步：汇总质检（质检闸 C）

汇总不是拼接，必须做四件事：

1. 去重：不同子任务可能产出重复内容 → 合并
2. 消解冲突：两份结论矛盾时，不各打五十大板，
   而是指出矛盾点、给出判断依据、标明哪一方更可信（或标注需人工裁决）
3. 检查覆盖度：对照原始任务清单，确认没有子任务遗漏/失败
4. 统一口径：术语、格式、深度是否一致

> 质检闸 C：
> - 有未完成的子任务 → 明确列出，不允许静默跳过。
> - 有冲突未消解 → 显式标注，不允许让矛盾结论共存。
> - 汇总后长度失控 → 提供摘要版。

第 6 步：交付

输出：

• 主结论（先给，别让人读完所有细节才知道结论）
• 完整结果（按统一结构）
• 遗留项（没做的、失败的、需人工确认的）

常见坑

• 接口没定死：各子任务输出格式不一，汇总比重做还累。
• 背景包太薄：子任务执行者缺上下文，产出偏离需求。
• 边界重叠：两个子任务做了同一件事，或都以为对方会做。
• 依赖没识别：以为能并行，结果 B 其实依赖 A 的结论。
• 汇总时偷懒：直接粘贴拼接，重复和矛盾原样保留。
• 批次太大：一次性派 20 个，质量失控且难以定位问题。

失败降级

• 子任务之间边界模糊、难以切分 → 先做 1–2 个试点，摸清模式后再批量。
• 汇总后发现质量参差 → 明确标注哪些子任务质量不足，建议重做。
• 任务其实不大但用户坚持要拆 → 提示编排开销可能大于收益，尊重用户决定。

依赖

• Read / Write / Grep / Glob 处理文件。
• 无外部服务依赖，纯方法论 + 本地文件操作。

致谢

• 原创免费技能，基于公开通用的任务分解与并行协作方法，
  由本技能作者重新组织与本地化撰写。
• 灵感参考 GitHub 社区 "advisor-orchestrator-worker" 类技能理念，内容全部原创重写。
• 采用 MIT 许可，不依赖任何专有实现或付费服务。