# Task Breakdown

> 需把需求拆成可执行任务并排依赖时。

- Skill: `lion-1209/task-breakdown` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add lion-1209/task-breakdown`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lion-1209/task-breakdown/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: Lion-1209 (https://skillmd.com/u/lion-1209)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lion-1209/task-breakdown

---


# Task Breakdown

## 概述

把一个需求拆成"今天就能动手、做完就能验证"的小任务。核心：**每个任务是一次端到端的价值交付，而不是一层架构的横切**——前者让你随时有可验证的进展，后者让你做到最后才看见东西跑起来。

## 何时使用

- 拿到一个需求/用户故事，要转成开发任务
- 面对一个大需求，不知从何下手
- 已有任务清单，想审查拆得对不对
- 要排开发顺序和依赖关系

**不该用**：需求本身已经是一个明确的小改动（直接做）；纯调研性命题（用 spike 流程，见下文）。

**与相邻 skill 的衔接**：task-breakdown 在"写 spec → **拆任务** → 执行"流水线的中间。理想入口是拿到一份定稿的 spec（用 `spec-writing` 产出）——方案决策已定，拆出的任务才有稳固依据；只有模糊需求时，先澄清/写 spec 再拆，否则任务建立在假设沙地上。

## 核心内容

### 先判断任务大小

不是所有需求都该拆，也不是越细越好。拿到需求先问两个方向：

- **拆不够**：它能不能在一次提交里端到端做完、且做完就能验证？能 → 别拆，直接做；不能 → 用下面的流程拆。
- **拆过细**：清单里有没有一堆"半小时以内的微步骤"（如"建表"和"加字段"分开、"写接口"和"加路由"分开）？有 → 合并回可独立验证的粒度。每个任务都有管理开销（上下文切换、状态追踪），碎任务的成本会淹没价值。

过度拆分比不拆还糟。粒度的尺子：**一个任务做完后，能独立验证、独立合并、独立回滚**——到这个粒度就停，再大不好做、再小是浪费。

### 澄清未知

模糊需求直接拆，会拆出一堆基于错误假设的任务。拆之前先把"会影响切片方式的未知"问清楚，不要凭猜往下走。典型该问的：

- **范围边界**：哪些在 scope 内、哪些不在？（"支持邮件通知"——只发交易邮件还是也发营销？）
- **规模/量级**：影响技术选型和切片顺序（日活 100 vs 100 万，缓存策略天差地别）
- **完成标准**：怎样算"做完了"？（性能要求、合规要求、可观测性要求）
- **已知约束**：必须用的技术、不能动的部分、截止时间

**分优先级问，别一次性甩给用户**。未知通常很多，一次列十几条会淹没用户。按"是否阻塞第一刀"分两类：

- **阻塞项**（不答就没法切第一片）——先问。例：通知系统"发什么类型、给谁发"不答，第一刀都没法落。
- **非阻塞项**（先用合理默认假设推进，遇到再问）——后问或直接用假设。例：通知系统"是否多语言"——先用"只做中文"的假设推进，等做到模板那片再确认。

问的方式：把你的假设**显式写出来**让用户确认（"我假设 X，不对就纠正我"），而不是连环追问——前者用户一句话就能校正方向，后者消耗耐心。每条最好带一句"为什么问"（这个未知如何影响切片），并在意控量（一次别超 6-8 条）；`spec-writing` 的"澄清问题怎么问"对此有更细的展开，可参考。

> 反例：用户说"做个通知系统"，你直接拆成"建表/写 API/写 UI"——所有切片都建立在"通知是什么、发给谁、怎么算成功"都未定义的沙地上。

### 选切片方向：垂直切片，别横切

这是拆任务最关键的决策。有两种切法：

- **横切层（糟糕的默认）**：按架构层切——"先建数据库表 → 再写后端 API → 再写前端 → 最后联调"。直觉上像"循序渐进"，实则把价值验证堆到最后：你做完前 3 个任务，**什么可运行的东西都没有**，直到联调那一刻才暴露所有集成错误。
- **垂直切片（推荐）**：按端到端的价值切——"邮件通知：从 DB 读用户 → 调邮件服务发送 → 用户能在收件箱看到"。**每个切片自己走完所有层**，做完就有一个可验证的、跑通的功能增量。

**为什么垂直切片更优**：
1. **早验证**：第一个切片做完就能演示，错也错得早、错得便宜。
2. **早集成**：集成风险被摊到每个切片，而不是堆到最后爆炸。
3. **进度可见**：完成 N 个切片 = N 个可演示功能，而不是"后端 80% 完成"这种无法验证的进度。

**一个完整的垂直切片长这样**：选一个最小但真实的数据 → 走通它的 DB schema + API + 业务逻辑 + UI + 测试。第一片可以很糙（hardcode 数据、丑 UI），但要端到端跑通。

**重构/迁移场景：价值换成"风险消化"，切片换成"渐进可回滚"**。上面定义的切片是"新功能语言"（DB+API+UI+测试、用户可演示的价值）。但重构、迁移、框架升级、性能改造这类任务**没有用户可感知的新价值**——用户看不到"项目变成了 TS"或"换了状态管理库"。这时机械套用"垂直切片"会卡壳，但**别因此退化成横切**。

理解垂直切片的本质——它不是"用户价值"，而是 **"做完一片就能验证、就能回滚、就把这部分风险消化掉了"**。把这点迁移到重构场景：

- **切片单位 = 一个可独立验证、独立回滚的子范围**（通常按模块/目录/路由切），而非"一个用户故事"。
- **每片做完，整个项目仍能构建、测试全绿、可运行**——这是重构可验证的等价物（新功能的"能演示"= 重构的"仍能构建且测试绿"）。
- **顺序按依赖图从叶子往根部**（叶子 = 被依赖多、本身不依赖别人的基础模块），让每一片的影响范围可控。
- **典型反模式（必踩的坑）**："先全局改后缀/先全局换语法/先一次性升级大依赖"——改完整个项目编译不过、无法验证、无法回滚，等同于新功能里"先建完所有表再联调"的横切。

例：JS→TS 迁移，按 utils → constants → services → components → pages 渐进迁移，每迁一个目录全项目 `tsc --noEmit` 仍通过、测试仍绿、可独立合并回滚。第一片可以很糙（只迁 utils，且暂时 `any` 不卡），但要保持项目始终可构建。

**用户已有清单时的渐进改法**：真实场景里，用户的清单很少是纯横切，往往是**横切和合理项的混合**。别要求用户推倒重来。先挑出**最该改的那一刀**——通常是"第一个本该端到端、却被横切的任务"——改给它看，让用户感受到差别，再决定要不要把其余的也改了。一次改太多，用户接不住、也容易引发抵触。

**横切任务在垂直切片下会自然消失**：用户清单里常见的"联调""写单元测试""部署"单独成项，往往是横切思维的产物——垂直切片每片都端到端跑通，"联调"在每片里就发生了；测试是每片的完成定义的一部分；部署是每片合并时自动发生。改写时把它们并入各切片的完成定义，而不是留作后置任务。

**什么时候允许横切**：仅当某一层是"所有切片都依赖的公共地基"（如先把 CI 跑起来、先建空项目骨架），且它本身规模小、做完即不再返工。这种横切的"基础设施片"应该很少，且排在最前。

### 每个任务带完成定义

每个任务必须能回答"怎样算做完了"——不是"写完代码"，而是**可验证的标准**：

- **差的完成定义**："实现邮件发送接口"（写完？跑通？测过？）
- **好的完成定义**："在测试环境调用 POST /notify/email，能在 Mailtrap 收件箱看到测试邮件，且失败时有日志"

完成定义让任务"可验收"，也防止"看起来做完了实际没做完"。一个简单的检查：**任务清单里的每一条，你能不能说出它做完后怎么验证？**说不出来 → 任务定义不清，补完成定义。

### 研究和执行分开

有些任务不是"写代码"而是"搞清楚能不能做、怎么做"——这种叫 **spike**（调研打桩）。比如"缓存方案选 Redis 还是 Memcached"在没调研前，你拆不出执行任务，只能拆出研究任务。

把研究和执行分开标记：
- **研究任务（spike）**：产出是结论/决策/技术选型，不是代码。例："调研三家短信服务商的送达率和价格，给出选型建议"。完成后可能改变后续执行任务的结构。
- **执行任务**：产出是可验证的代码/配置变更。

研究任务通常排在执行任务之前，且完成后要**回头修订执行计划**（因为研究结论可能让原计划失效）。

### 依赖排序

拆完后检查依赖关系、排出可执行的顺序：

- **研究 → 执行**：执行依赖研究的结论，研究先行
- **地基 → 上层**：基础设施片排在垂直切片之前
- **解耦的任务可并行**：**主动标出来**——哪些切片之间无依赖、可以并行推进（如多个独立通道、多个独立查询接口）。并行机会不标出来，团队就会串行做完、白白浪费并发空间

排完序的理想形态：**从头到尾做下去，每个任务做完都能验证、都能合并**，而不是攒一堆到某个点才能集成。

### 产出形态

最终交给用户的是一份**精简的任务清单**，不是论证长文。规则：

- **清单优先**：用户要的是"做什么、什么顺序"，给编号任务清单 + 每条的完成定义。别把推理过程、skill 原文引用、为什么这样切的论证全倒给用户——那是你的工作记录，不是交付物。
- **澄清要精炼**：澄清问题用编号列表，阻塞项在前、非阻塞假设在后（"以下我用默认假设推进，不对请纠正"）。一次别超过 6–8 条，多了用户接不住。
- **改写要有对照**：审查已有清单时，给"原条目 → 改写"的对照，让用户看到具体差异，而非抽象批评。

记住：skill 的产出是**帮用户决策和执行**，不是**展示你分析得多彻底**。

## 常见错误

| 问题 | 修法 |
|------|------|
| 模糊需求直接拆 | 先澄清会影响切片方式的未知，显式写假设让用户确认 |
| 横切层切片（按架构分层） | 改成垂直切片，每个切片端到端走通 |
| 重构/迁移任务一次性横切（"先全局改后缀/换语法/升大依赖"） | 按模块渐进，每片做完项目仍能构建测试全绿、可回滚 |
| 任务无完成定义 | 每个任务写明"做完后怎么验证" |
| 把所有任务都当执行任务 | 区分研究(spike)和执行，研究先行且回头修订计划 |
| 过度拆分（一堆半小时任务） | 合并同一切片内的微步骤，保留可独立验证的粒度 |
| 任务顺序靠直觉排 | 按研究→地基→垂直切片的依赖关系排 |
| 一次甩十几条澄清问题淹没用户 | 分优先级：阻塞项先问，非阻塞项用默认假设推进 |
| 把推理过程当产出倒给用户 | 交付精简任务清单，论证留在工作记录里 |