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 的产出是帮用户决策和执行，不是展示你分析得多彻底。

常见错误