Menü
需把需求拆成可执行任务并排依赖时。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | task-breakdown |
| description | 需把需求拆成可执行任务并排依赖时。 |
把一个需求拆成"今天就能动手、做完就能验证"的小任务。核心：每个任务是一次端到端的价值交付，而不是一层架构的横切——前者让你随时有可验证的进展，后者让你做到最后才看见东西跑起来。
不该用：需求本身已经是一个明确的小改动（直接做）；纯调研性命题（用 spike 流程，见下文）。
与相邻 skill 的衔接：task-breakdown 在"写 spec → 拆任务 → 执行"流水线的中间。理想入口是拿到一份定稿的 spec（用 spec-writing 产出）——方案决策已定，拆出的任务才有稳固依据；只有模糊需求时，先澄清/写 spec 再拆，否则任务建立在假设沙地上。
不是所有需求都该拆，也不是越细越好。拿到需求先问两个方向：
过度拆分比不拆还糟。粒度的尺子：一个任务做完后，能独立验证、独立合并、独立回滚——到这个粒度就停，再大不好做、再小是浪费。
模糊需求直接拆，会拆出一堆基于错误假设的任务。拆之前先把"会影响切片方式的未知"问清楚，不要凭猜往下走。典型该问的：
分优先级问，别一次性甩给用户。未知通常很多，一次列十几条会淹没用户。按"是否阻塞第一刀"分两类：
问的方式：把你的假设显式写出来让用户确认（"我假设 X，不对就纠正我"），而不是连环追问——前者用户一句话就能校正方向，后者消耗耐心。每条最好带一句"为什么问"（这个未知如何影响切片），并在意控量（一次别超 6-8 条）；spec-writing 的"澄清问题怎么问"对此有更细的展开，可参考。
反例：用户说"做个通知系统"，你直接拆成"建表/写 API/写 UI"——所有切片都建立在"通知是什么、发给谁、怎么算成功"都未定义的沙地上。
这是拆任务最关键的决策。有两种切法：
为什么垂直切片更优：
一个完整的垂直切片长这样：选一个最小但真实的数据 → 走通它的 DB schema + API + 业务逻辑 + UI + 测试。第一片可以很糙（hardcode 数据、丑 UI），但要端到端跑通。
重构/迁移场景：价值换成"风险消化"，切片换成"渐进可回滚"。上面定义的切片是"新功能语言"（DB+API+UI+测试、用户可演示的价值）。但重构、迁移、框架升级、性能改造这类任务没有用户可感知的新价值——用户看不到"项目变成了 TS"或"换了状态管理库"。这时机械套用"垂直切片"会卡壳，但别因此退化成横切。
理解垂直切片的本质——它不是"用户价值"，而是 "做完一片就能验证、就能回滚、就把这部分风险消化掉了"。把这点迁移到重构场景：
例：JS→TS 迁移，按 utils → constants → services → components → pages 渐进迁移，每迁一个目录全项目 tsc --noEmit 仍通过、测试仍绿、可独立合并回滚。第一片可以很糙（只迁 utils，且暂时 any 不卡），但要保持项目始终可构建。
用户已有清单时的渐进改法：真实场景里，用户的清单很少是纯横切，往往是横切和合理项的混合。别要求用户推倒重来。先挑出最该改的那一刀——通常是"第一个本该端到端、却被横切的任务"——改给它看，让用户感受到差别，再决定要不要把其余的也改了。一次改太多，用户接不住、也容易引发抵触。
横切任务在垂直切片下会自然消失：用户清单里常见的"联调""写单元测试""部署"单独成项，往往是横切思维的产物——垂直切片每片都端到端跑通，"联调"在每片里就发生了；测试是每片的完成定义的一部分；部署是每片合并时自动发生。改写时把它们并入各切片的完成定义，而不是留作后置任务。
什么时候允许横切：仅当某一层是"所有切片都依赖的公共地基"（如先把 CI 跑起来、先建空项目骨架），且它本身规模小、做完即不再返工。这种横切的"基础设施片"应该很少，且排在最前。
每个任务必须能回答"怎样算做完了"——不是"写完代码"，而是可验证的标准：
完成定义让任务"可验收"，也防止"看起来做完了实际没做完"。一个简单的检查：**任务清单里的每一条，你能不能说出它做完后怎么验证？**说不出来 → 任务定义不清，补完成定义。
有些任务不是"写代码"而是"搞清楚能不能做、怎么做"——这种叫 spike（调研打桩）。比如"缓存方案选 Redis 还是 Memcached"在没调研前，你拆不出执行任务，只能拆出研究任务。
把研究和执行分开标记：
研究任务通常排在执行任务之前，且完成后要回头修订执行计划（因为研究结论可能让原计划失效）。
拆完后检查依赖关系、排出可执行的顺序：
排完序的理想形态：从头到尾做下去，每个任务做完都能验证、都能合并，而不是攒一堆到某个点才能集成。
最终交给用户的是一份精简的任务清单，不是论证长文。规则：
记住：skill 的产出是帮用户决策和执行，不是展示你分析得多彻底。
| 问题 | 修法 |
|---|---|
| 模糊需求直接拆 | 先澄清会影响切片方式的未知，显式写假设让用户确认 |
| 横切层切片（按架构分层） | 改成垂直切片，每个切片端到端走通 |
| 重构/迁移任务一次性横切（"先全局改后缀/换语法/升大依赖"） | 按模块渐进，每片做完项目仍能构建测试全绿、可回滚 |
| 任务无完成定义 | 每个任务写明"做完后怎么验证" |
| 把所有任务都当执行任务 | 区分研究(spike)和执行，研究先行且回头修订计划 |
| 过度拆分（一堆半小时任务） | 合并同一切片内的微步骤，保留可独立验证的粒度 |
| 任务顺序靠直觉排 | 按研究→地基→垂直切片的依赖关系排 |
| 一次甩十几条澄清问题淹没用户 | 分优先级：阻塞项先问，非阻塞项用默认假设推进 |
| 把推理过程当产出倒给用户 | 交付精简任务清单，论证留在工作记录里 |
需求模糊、含隐藏假设或 X-Y problem，需先澄清再动手时。
审查代码（自己的或别人的），需有重点、分层次地看时。
Git 改动需编写规范提交信息时。
遇到 bug、报错、崩溃或行为异常，需定位根因时。
设计或改进错误处理与日志时。
在 Lion-Skills 仓库创建或修改 skill 时。
