任务拆解

何时使用

• 用户说"把这个功能做完"但没说从哪开始;
• 任务包含多个步骤,需要排执行顺序;
• 需要把大任务变成可估算、可验收的小任务;
• 开发前规划 commit 粒度,让每个 commit 对应一个子任务。

使用步骤

第 1 步:明确目标与边界

确认三件事:

1. 最终交付物是什么(代码、文档、部署?);
2. 范围与不做项;
3. 约束(时间、技术栈、依赖)。

第 2 步:自顶向下拆解

按"功能模块 → 子功能 → 单任务"逐层拆解,直到每个任务满足:

• 单一职责:只做一件事;
• 可独立完成:不依赖未完成的他人任务;
• 可验收:有明确的完成标准;
• 可估算:能估计工作量(如 0.5 天、2 小时);
• 可提交:完成后能形成一次有意义的 commit。

第 3 步:确定依赖与顺序

用依赖关系排出执行顺序:

任务 A(定义数据模型)
   ↓
任务 B(编写 API 接口)→ 任务 C(前端页面)
   ↓
任务 D(联调与测试)→ 任务 E(部署)

可并行的任务标注"可并行"。

第 4 步:输出任务清单

模板、判断标准和常见拆法见 references/DECOMPOSE_TEMPLATE.md。

# 任务清单:<目标>

| # | 任务 | 依赖 | 交付物 | 验收标准 | 预估 |
|---|------|------|--------|----------|------|
| 1 | 定义数据模型 | - | schema 文件 | 覆盖全部字段与关系 | 2h |
| 2 | 编写创建接口 | 1 | API + 测试 | 单测通过,文档更新 | 4h |
| 3 | 实现前端表单 | 2 | 页面组件 | 能提交并看到结果 | 4h |

## 推荐提交顺序
1 → 2 → 3(每个任务一个 commit)

写完用 task_checker.py 自查(见下面的辅助脚本),修掉标出的缺口再交付。

输入与输出

• 输入:一个目标或大任务描述;
• 输出:带依赖、交付物、验收标准的任务清单。

示例

用户输入: "做一个用户注册登录功能。"

拆解结果:

| # | 任务 | 依赖 | 交付物 | 验收标准 |
|---|------|------|--------|----------|
| 1 | 用户表设计 | - | 迁移文件 | 含 username、password_hash、created_at |
| 2 | 注册接口 | 1 | API + 测试 | 重复用户名返回 409,密码哈希存储 |
| 3 | 登录接口 | 1 | API + 测试 | 正确密码返回 token,错误密码 401 |
| 4 | 前端注册/登录页 | 2,3 | 页面 | 注册成功跳转登录,错误有提示 |
| 5 | 会话保持 | 4 | 中间件 | 刷新页面不退出登录 |

辅助脚本

scripts/task_checker.py 检查任务清单表:必需列是否齐全、任务编号是否重复、依赖是否存在且无环、验收标准是否为空或含糊、有无占位符:

python skills/task-decomposer/scripts/task_checker.py <任务清单.md>

脚本只做标记,结论需要人确认。模板见 references/DECOMPOSE_TEMPLATE.md。

注意事项

• 拆到可执行为止:如果用户说"不知道怎么开始",就拆到第一个任务可以直接动手;
• 保留弹性:标注不确定的任务为"需调研",不要假装精确;
• 不要过度拆解:单任务小到不需要验收标准就是过度拆解;
• 配合 requirement-clarifier 使用:先澄清需求,再拆任务。

不适用场景

• 任务本身很小、一步可完成;
• 用户只需要粗略的步骤列表,不需要验收标准;
• 目标是开放性研究(如"调研一下"),建议先用调研型技能。

验证方式

1. 触发:"把这个功能拆成任务""帮我规划一下实现步骤";
2. 跑脚本:python skills/task-decomposer/scripts/task_checker.py <任务清单.md>,无"必须"级问题;
3. 检查:每个任务满足"单一职责、可验收、有依赖说明";
4. 走查:按清单顺序执行第一个任务,确认没有前置缺口。