task-decomposition

任务分解

概述

任务分解是将复杂任务拆分为易于管理、定义明确的子任务，并明确其依赖关系、工作量估算和并行化机会。它涵盖层级式工作分解结构（WBS）、依赖关系图构建、关键路径分析、任务规模评估，以及并发执行机会识别。对于规划多步骤实现、项目估算和自主循环中的任务选择，这一方法必不可少。

开始时宣布：“我正在使用任务分解技能，将这项工作拆分为结构化层级，并明确依赖关系和工作量估算。”

触发条件

• 复杂任务需要拆分为子任务
• 需要梳理工作项之间的依赖关系
• 规划需要工作量估算
• 需要识别并行化机会
• 调用了 /decompose 命令
• 从规划技能切换到复杂计划
• 自主循环需要任务选择指导

---

阶段 1：范围定义

目标： 为分解明确界定范围。

1. 定义总体交付成果和验收标准
2. 确定范围边界（哪些在范围内，哪些不在范围内）
3. 确定分解的粒度级别
4. 识别利益相关者及其需求
5. 确立约束条件（时间、资源、依赖关系）

粒度决策表

情境	目标级别	典型时长	原因
自主循环（Ralph）	L3-L4（任务/子任务）	15 分钟 - 4 小时	每次循环迭代仅处理一个任务
冲刺规划	L2-L3（故事/任务）	0.5-2 天	适合冲刺规模的工作项
路线图规划	L0-L1（史诗/功能）	2-8 周	跟踪高层里程碑
Bug 修复	L3-L4（任务/子任务）	15 分钟 - 2 小时	专注于具体修复

粒度级别

级别	名称	典型时长	示例
L0	史诗	2-8 周	“用户身份验证系统”
L1	功能	2-5 天	“OAuth2 登录流程”
L2	故事	0.5-2 天	“Google OAuth 提供方集成”
L3	任务	1-4 小时	“实现 Google 回调处理程序”
L4	子任务	15-60 分钟	“解析 OAuth 令牌响应”

停止 — 在进入阶段 2 之前，不要继续：

• 已定义交付成果和验收标准
• 范围边界明确（范围内/范围外）
• 已选定目标粒度级别
• 已识别约束条件

---

阶段 2：层级拆分

目标： 将工作分解为符合 INVEST 标准的树形结构。

1. 识别顶层工作流（史诗或主要组件）
2. 将每个工作流拆分为功能或里程碑
3. 将功能分解为可实施的任务
4. 遵循“2 小时规则”——任何任务的专注工作时长都不应超过 2 小时
5. 确保每项任务都有明确的完成定义
6. 验证是否符合 MECE（相互独立，完全穷尽）原则

任务的 INVEST 标准

标准	问题	不佳示例	良好示例
Independent（独立）	这项工作能否在不等待他人的情况下完成？	“等数据库就绪后再实现身份验证”	“使用模拟数据库实现身份验证”
Negotiable（可协商）	实现方式是否灵活？	“使用 Redis 进行缓存”	“为用户会话添加缓存层”
Valuable（有价值）	完成这项工作是否能带来价值？	“设置文件夹结构”	“创建用户注册端点”
Estimable（可估算）	能否估算所需工作量？	“提升性能”	“为用户查询添加数据库索引”
Small（规模小）	一个人能否在 2 小时内完成？	“构建仪表板”	“创建用于展示收入数据的仪表板图表组件”
Testable（可测试）	能否验证任务是否完成？	“让它变得更好”	“/api/users 的响应时间 < 200ms”

MECE 验证

检查项	问题
相互排斥	是否有任务与其他任务重叠？（不应重叠）
集体穷尽	所有任务合在一起是否涵盖了完整的交付成果？（应该涵盖）
无孤立项	每项任务是否都对交付成果有所贡献？
无遗漏	是否有尚未分配任务的必要工作？

停止 — 在满足以下条件之前，请勿进入第 3 阶段：

• 已识别所有工作流
• 任务符合 INVEST 标准
• 已验证 MECE 覆盖情况
• 每项任务的耗时均不超过 2 小时

---

第 3 阶段：依赖关系映射

目标： 构建任务依赖关系的有向无环图（DAG）。

1. 确定任务之间的输入／输出依赖关系
2. 对依赖类型进行分类
3. 构建有向无环图（DAG）
4. 确定关键路径（最长依赖链）
5. 将循环依赖标记为需要解决的错误
6. 标记外部依赖（API 访问、审批、第三方）

依赖类型

类型	符号	含义	示例
完成到开始（FS）	A -> B	B 只有在 A 完成后才能开始	“构建通过”后再“部署”
开始到开始（SS）	A => B	A 开始时，B 即可开始	“编写代码”开始时“编写文档”
完成到完成（FF）	A =>> B	B 只有在 A 完成后才能完成	“测试”在“开发”完成后结束
开始到完成（SF）	A ~> B	B 只有在 A 开始后才能完成	较少见 — 交接班场景

依赖关系标注格式

Task 1: Set up database schema
Task 2: Create data access layer         [depends: 1]
Task 3: Implement API endpoints          [depends: 2]
Task 4: Write unit tests for DAL         [depends: 2]
Task 5: Write API integration tests      [depends: 3, 4]
Task 6: Create frontend components       [depends: none]
Task 7: Connect frontend to API          [depends: 3, 6]
Task 8: End-to-end testing               [depends: 5, 7]

Parallel tracks:
  Track A: 1 -> 2 -> 3 -> 5 -> 8
  Track B: 1 -> 2 -> 4 -> 5 -> 8
  Track C: 6 -> 7 -> 8
  Critical path: 1 -> 2 -> 3 -> 7 -> 8

循环依赖解决方案

检测到的情况	解决方案
A 依赖 B，B 依赖 A	拆分为更小的任务以消除循环
A 依赖 B 的接口，B 依赖 A 的接口	将接口定义作为单独任务优先完成
组件之间紧密耦合	增加一个抽象层任务

停止 — 在满足以下条件之前，请勿进入第 4 阶段：

• 已映射所有依赖关系
• 不存在循环依赖
• 已确定关键路径
• 已标记外部依赖

---

第 4 阶段：并行化规划

目标： 识别可并发执行的独立任务集群。

1. 识别独立任务集群（彼此之间没有依赖关系）
2. 按资源类型对任务分组（读取、写入、构建、测试）
3. 根据资源限制确定最大并行度
4. 为每条并行轨道安排任务顺序
5. 规划同步点（合并关卡）

基于资源的并行限制

资源类型	最大并行数	原因
代码阅读／分析	不限	无副作用
文件创建／编辑	3-5	避免合并冲突
构建／编译	1	资源争用
测试执行	1-2	共享状态、端口
数据库迁移	1	本质上必须按顺序进行
文档	不限	文件相互独立

并行化模式决策表

模式	适用场景	示例
独立集群	工作流之间没有共享状态	后端、前端、基础设施
按层划分	各层涉及不同文件	API、服务、数据
按功能领域划分	彼此独立的纵向切片	身份验证、个人资料、账单
按任务类型划分	代码、测试、文档涉及不同文件	实现、测试、编写文档

同步点

  +------+     +------+     +------+
  |Task A|     |Task B|     |Task C|
  +--+---+     +--+---+     +--+---+
     |            |            |
     v            v            v
  ======================================
     SYNC GATE: All Complete
     Verify: no conflicts, tests pass
  ======================================
                 |
                 v
          +----------+
          |Next Phase|
          +----------+

停止 — 在满足以下条件之前，请勿进入第 5 阶段：

• 已识别独立集群
• 已考虑资源限制
• 已定义同步点
• 已确定最大并行度

---

第 5 阶段：估算与优先级排序

目标： 估算每项任务的工作量并制定执行时间表。

T 恤尺码与工时

尺码	工时	置信度	示例
XS	0.5-1h	高	重命名变量、修正拼写错误
S	1-2h	高	添加简单的端点、编写测试
M	2-4h	中	按已知模式实现功能
L	4-8h	低	需要研究的新功能
XL	8h+	极低	必须进一步拆分

估算启发式规则

场景	倍数	理由
已知模式	基础估算的 1.2x	为未知因素预留 20% 缓冲
未知模式	基础估算的 2x	先添加研究探索任务
集成工作	各组件总和的 1.5x	集成比单个部分更难
首次使用某项技术	“如果我会做”的估算值的 3x	学习曲线
Bug 修复	调查限时 2h	然后重新估算

三点估算法

Expected = (Optimistic + 4 * Most Likely + Pessimistic) / 6

Example:
  Optimistic:  2 hours (everything goes smoothly)
  Most Likely: 4 hours (normal development pace)
  Pessimistic: 10 hours (major unexpected issues)
  Expected:    (2 + 16 + 10) / 6 = 4.7 hours

优先级决策表

因素	权重	评估方法
位于关键路径上	最高	此处延迟会导致所有工作延迟
阻塞其他任务	高	解除阻塞可提升整体吞吐量
业务价值	高	对用户的影响
降低风险	中	尽早消除未知因素带来的风险
快速见效	中	工作量低、士气提升大
锦上添花	低	仅在核心工作完成后进行

---

工作分解结构模板

# WBS: [Project Name]

## 1. [Work Stream A]
### 1.1 [Feature]
- [ ] 1.1.1 [Task] — Est: 2h — Deps: none — Priority: P0
- [ ] 1.1.2 [Task] — Est: 1h — Deps: 1.1.1 — Priority: P0
- [ ] 1.1.3 [Task] — Est: 3h — Deps: 1.1.1 — Priority: P1

### 1.2 [Feature]
- [ ] 1.2.1 [Task] — Est: 1h — Deps: none — Priority: P0
- [ ] 1.2.2 [Task] — Est: 2h — Deps: 1.2.1, 1.1.2 — Priority: P1

## 2. [Work Stream B]
### 2.1 [Feature]
- [ ] 2.1.1 [Task] — Est: 1h — Deps: none — Priority: P0
- [ ] 2.1.2 [Task] — Est: 4h — Deps: 2.1.1 — Priority: P0

## Summary
- Total tasks: N
- Estimated total effort: Xh
- Critical path duration: Yh
- Max parallelism: Z tracks
- External dependencies: [list]

---

关键路径分析

如何找到关键路径

1. 列出所有任务及其工期和依赖关系
2. 正向推算：计算最早开始时间（ES）和最早完成时间（EF）
3. 反向推算：计算最晚开始时间（LS）和最晚完成时间（LF）
4. 浮动时间 = LS - ES（浮动时间为零的任务位于关键路径上）
5. 关键路径是依赖关系图中最长的任务链

优化策略

策略	适用情况	效果	风险
并行化	关键路径上相互独立的任务	缩短日历工期	低
快速跟进	重叠执行顺序任务	缩短工期	中 — 可能导致返工
赶工	为关键任务增加资源	缩短工期	中 — 协调成本
缩减范围	移除非必要任务	减少总工作量	低 — 前提是对“非必要”的判断正确
先做探索	阻塞路径的未知任务	降低估算风险	低

---

反模式 / 常见错误

反模式	失败原因	正确做法
任务过大，无法估算	“构建后端”不是一个任务	拆分到可估算的粒度（< 2h）
缺少依赖关系	实现时才暴露，导致返工	提前梳理所有依赖关系
循环依赖	表明架构不清晰	通过接口任务打破循环
所有任务都按顺序执行	无法并行	找出相互独立的任务组
未经拆分就估算	在 L0 层级猜测，结果总是错误	在叶级任务上估算，再汇总
忽视外部依赖	可能意外阻碍进展	标记这些依赖并做好规划
过度拆分	产生噪声而非信号（一个表单拆成 50 个子任务）	在达到有意义且可测试的单元时停止
忽视关键路径	优先处理非关键任务	始终优先处理关键路径
不重新估算	随着认知增加，估算会偏离实际	每个阶段结束后重新估算
任务没有验收标准	无法验证是否完成	每个任务都要有完成定义

---

防合理化防护措施

不得跳过依赖关系映射。不得留下耗时超过 2 小时的任务。不得在拆解之前估算。每项任务都必须包含依赖关系、估算和验收标准。

如果你发现自己在想：

• “我可以不拆解就估算整个项目……”——不行。先拆解。
• “依赖关系很明显，没必要映射……”——要映射。隐藏的依赖关系会导致失败。
• “这个任务用 8 小时完成没问题……”——要拆解。XL 任务必须拆分。
• “小项目不需要关心关键路径……”——需要。它能告诉你应该优先处理什么。

---

子 Agent 分派机会

任务模式	分派给	时机
拆解过程中识别出的可并行叶子任务	通过 Agent 工具分派给并行子 Agent	任务之间没有共享依赖关系时
任务边界的架构分析	planner Agent	拆解发现横切关注点时
验证拆解是否完整	spec-reviewer Agent	任务树已完成但尚未验证时

在输出表格中，为每个拆解后的任务标注 parallelizable: yes/no。分派时遵循 dispatching-parallel-agents 技能协议。

---

集成点

技能	关系	时机
planning	上游 — 提供待拆解的计划	复杂计划需要工作分解结构（WBS）时
task-management	下游 — 接收拆解后的任务	跟踪执行情况时
dispatching-parallel-agents	下游 — 接收可并行任务集	并发执行时
autonomous-loop	下游 — 从 WBS 中选择任务	Ralph 选择任务时
executing-plans	下游 — 根据 WBS 创建批次	执行计划时
subagent-driven-development	下游 — 将独立任务交给子 Agent	委派实施工作时
spec-writing	互补 — 规格说明为拆解提供依据	理解需求时

---

具体示例

示例：拆解“添加用户身份验证”

# WBS: User Authentication

## 1. Core Auth
### 1.1 Token Management
- [ ] 1.1.1 Implement JWT generation — Est: 1h — Deps: none — P0
- [ ] 1.1.2 Implement JWT validation — Est: 1h — Deps: 1.1.1 — P0
- [ ] 1.1.3 Implement refresh token rotation — Est: 2h — Deps: 1.1.2 — P1

### 1.2 Auth Middleware
- [ ] 1.2.1 Create auth middleware — Est: 1h — Deps: 1.1.2 — P0
- [ ] 1.2.2 Add role-based access control — Est: 2h — Deps: 1.2.1 — P1

## 2. Auth Endpoints
### 2.1 Registration
- [ ] 2.1.1 POST /auth/register endpoint — Est: 1h — Deps: 1.1.1 — P0
- [ ] 2.1.2 Email validation — Est: 30m — Deps: none — P0

### 2.2 Login
- [ ] 2.2.1 POST /auth/login endpoint — Est: 1h — Deps: 1.1.1, 1.2.1 — P0
- [ ] 2.2.2 POST /auth/refresh endpoint — Est: 1h — Deps: 1.1.3 — P1

## Summary
- Total tasks: 8
- Estimated total effort: 10.5h
- Critical path: 1.1.1 -> 1.1.2 -> 1.2.1 -> 2.2.1 (4h)
- Max parallelism: 3 tracks (Token, Middleware, Endpoints)
- External dependencies: none

---

技能类型

严格型 — 按顺序遵循拆解阶段。每项任务都必须符合 INVEST 标准，并明确列出依赖关系、估算和验收标准。对于持续多日的工作，依赖关系图和关键路径分析是必需的。