任务分解粒度

用途：把大任务切成子任务时，决定切多细、按什么切

分解的三个维度

维度	问什么	典型切法
依赖	哪些子任务可并行，哪些必须串行	按数据依赖建 DAG
验收	每个子任务能否独立判定成功	每片都有可执行判据（测试、检查命令）
上下文	每个子任务需要的信息能否自包含	按知识边界切，避免跨片共享隐式假设

好的分解标准：每个子任务的输入、输出与验收判据都能在一句话内说清，且不需要读其他子任务的推理过程。

粒度权衡

过粗	过细
单 Agent 上下文超载、失败时全部重做、无法并行	协调开销与总成本上升、接口不一致风险增加、局部最优损害整体一致性

经验信号：

需要为子任务写超过一段说明才能讲清 → 太粗。
两个子任务之间必须频繁互查中间推理 → 太细（它们本是一个任务）。
子任务无法独立验证 → 切分线画错了（切在了职责中间）。

按什么切（有效切法）

按可独立验证的产物切：一个模块 + 它的测试；一份数据迁移 + 校验脚本。
按知识边界切：前端契约、后端实现、文档各自成片，接口处定义清楚。
按变更面切：不同目录/模块并行，避免同文件冲突（与 diff 归属直接相关）。
按角色切：探索（找方案）→ 实现 → 评审 → 集成，各阶段目标不同、验收标准不同。
按风险切：高风险部分单独成任务并要求更高证据等级（先写复现用例、再实现）。

无效切法

切法	问题
按行数平均切	逻辑耦合被切断，接口不一致
把“设计”和“实现”交给两个互不通气的 Agent	实现偏离设计，返工
并行修改同一文件的不同部分	合并冲突与语义冲突（见“冲突与 diff 归属”）
用子任务数量当进度指标	数量增长不代表进展

契约先于分解

分解前必须先定接口契约：模块边界、数据结构、命名、错误语义。多个 Agent 并行实现的前提是契约稳定；否则每片都“符合自己那份理解”，集成时全面冲突。

实践顺序：契约（含验收标准）→ 分解 → 并行实现 → 集成验证（集成验证的权重高于任何单片自检）。

常见误区

误区	修正
先并行再想接口	契约先行
子任务无验收判据	没有判据的任务不派发
一个任务同时改语义与格式	拆分：行为变更与格式化分开
分解由 Agent 自由决定	分解方案本身需要评审（人或主管 Agent + 门禁）
集成留到最后一次性做	早集成、频繁集成，降低冲突面

延伸阅读

本站：编排拓扑、冲突与 diff 归属、上下文传递与共享状态
敏捷与持续集成中关于小批量提交的公开实践资料