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"或"换了状态管理库"。这时机械套用"垂直切片"会卡壳，但别因此退化成横切。