从需求到 feature 的分解流
一坨需求摆在面前——一份 PRD、一句”把这个做了”、一个 bug——在判它走哪一档、动手写规格之前，先要把它切成能一个一个交付的单元。这一步叫分解。分解做错，后面每一步都在错的粒度上使劲：要么一个单元大到写不出清晰的规格，要么切出来的”单元”根本不是用户能用的东西。
分解不是一次把需求拆到底，而是按规模分层下钻：大的先分组，再切成可交付的 feature，feature 内部的实现任务留给后面的流程。多数需求用不到全部层级——这一章先讲清楚层级和每层的判断，下一章再讲每个 feature 定档后怎么走。
10.1 分解的四层：PRD → Epic → Feature → Task
业界拆分需求有一条相对稳定的层级链，从大到小是四层：
| 层级 | 是什么 | 能不能直接开发 | 谁来切 |
|---|---|---|---|
| PRD / 需求 | 一整坨待开发的东西，还没有边界 | 否 | 人写 / 产品给 |
| Epic | 面向用户的粗粒度能力分组，跨多个 feature | 否，它只是容器 | /td-epic-discovery（需要时） |
| Feature | 可独立交付、用户能感知的纵向切片 | 是 | /td-feature-discovery |
| Task | feature 内部的实现步骤 | 是 | spec-kit 的 tasks 阶段 |
关键是看清哪一层由谁负责，不要越层：
- Epic 不可直接开发。它是一个分组容器，你没法”实现一个 Epic”，只能实现它下面的 feature。把 Epic 直接拿去写规格，等于让规格去描述一个没有边界的大筐。
- Feature 是可交付的最小单元。分解的落点是 feature——它可独立交付、用户能看到或做到新东西。规格、计划、实现都围绕一个 feature 展开。
- Task 不归分解管。把 feature 拆成实现步骤是 spec-kit 在
tasks阶段做的事（见下一章），不要在分解时提前拆实现任务。
按规模缩放，不是人人走全程
四层是能力清单，不是固定流程。真正要做的判断是”这次需要走到哪一层”：
- 一个 bug、一个小改动：根本不用分解，直接就是一个单元，去判档。
- 一个中等需求：直接切成几个 feature，不需要 Epic 层。
- 一个新项目、一次大改版、跨多个能力域的初始：才需要先分 Epic，再逐个 Epic 往下切 feature。
层级是给”大到握不住”的需求准备的脚手架；需求不大时，跳过上面的层，直接落到 feature 甚至直接一个单元。为了凑齐层级而硬分 Epic，只会凭空多一层维护负担。
10.2 Epic 层：什么时候需要先分组
Epic 是一个选择性工具。大多数变更不需要它。判断要不要先分 Epic，由人决定——你觉得这坨大，才运行 /td-epic-discovery；觉得不大，直接去切 feature。
倾向需要 Epic：需求跨几个不同的能力领域或用户群；明显是多阶段、多月的规模；直接切成 feature 会切出十几个以上、而且没有自然归类的一堆。
倾向不需要 Epic：一个内聚的能力；围绕单一工作流的一小把 feature；一个 bug 或单模块的迭代。
运行 /td-epic-discovery 时，它先过这道判断——不够大就直说”不必分 Epic”，并把你导向 /td-feature-discovery，不写任何文件。够大才进入分组。
分组时还有一个要人来定的选择：按什么轴分 Epic。同一坨需求可以沿不同的轴切，哪种合适取决于项目，所以提示词给候选、让人选，不自己替你定：
- 能力域 / 功能模块：每个 Epic 是一块面向用户的内聚能力。内容型、工具型项目通常最合适，是默认推荐。
- 用户旅程阶段：按用户走过的大步骤分。强交互、有明确流程的系统（如交易、审批类）更适用。
- 发布里程碑：按交付阶段分组。只在确实想按发布节奏组织、且项目没有现成的阶段规划时用——否则会和已有的阶段计划重复。
Epic 切出来是一张”选哪个往下做”的薄菜单，每个 Epic 带一句面向用户的目标和几条”大致包含什么”的提示，不写验收条件、不写设计。真正的 feature 切分是下一层的事。
10.3 Feature 层：切成可独立交付的纵向切片
选定一个 Epic（或需求本来就不大、直接从这里开始）后，运行 /td-feature-discovery 把它切成 feature。它先判断这坨是一个、多个，还是太模糊：
- single：就是一个边界清楚的 feature，不写文件，直接往下走。这是合法且常见的结果。
- multi：切成一组纵向 feature，排好依赖和顺序。
- foggy：信息不足以找到边界，先做一次探索性澄清，补清了再回来切。
single 和 foggy 都不产文件；只有 multi 才写一张 feature 菜单。需求本来清楚时，不因为流程”应该”切分就硬切。
纵切，不要横切
这是整个分解里最常做错、也最值得讲清的一条。
一个 feature 必须是纵向切片：用户能感知的一个结果，端到端穿过它需要的所有层。只上这一个 feature，用户就能多做到或多看到一件事。
反过来，按技术层切是横切，是反模式。“数据层""接口层""页面层""后端”——这些单独拿出来，用户什么也感知不到，也没法独立验证它带来了什么价值。如果你发现自己在用一个技术层给 feature 命名，那就是在横切，停下来，改成”用户能做什么”重新切。
判断一个候选 feature 是不是纵切，用一句话试金：“只上这一片之后，用户能多做到或多看到什么？” 如果诚实的回答是”还看不到什么，这是给后面打的地基”，那它就是横切，应该并进第一个真正用到它的纵向 feature，而不是单独成为一个 feature。
场景对比（中性化）。 一个把文档内容渲染成可浏览网站的应用，第一期要做”内容能展示、能按状态发布、读起来顺、能在条目间跳转”。
横切的切法（错）：切成”数据模型层 / 渲染层 / 样式层”三块。每一块单独交付，用户都看不到任何可用的东西——数据层做完，屏幕上什么都没有。这三块是技术分层，不是 feature。
纵切的切法（对）：切成”能打开并读到一篇内容 / 发布状态真正生效（草稿不出现、已发布可见）/ 读起来是规整的阅读排版 / 条目之间能导航”。每一片上线后，用户都能实实在在多做到一件事；而且第一片（能读到一篇）天然是其余几片的共享地基，排在最前。
同一坨需求，横切出”三个技术层”，纵切出”四个用户能用的结果”。数量相近，性质完全不同：前者没有一片能独立交付价值，后者每片都能。
切出来的每个 feature 要有：面向能力的名字（不是层的名字）、一句话意图、范围边界（哪些在内、哪些挪给兄弟片）、依赖关系。把多个片共用的底层能力挑出来、作为最早交付的那一片，避免每片各搭一遍地基——但只在共享需求真实存在时才这么做，不要为了有个”地基片”而硬造一个。
粒度：太大沿用户旅程再切，不要切回层
- 太大：描述它就变成一张路线图 → 拆开，但沿用户旅程的步骤拆（先能做什么、再能做什么），不要拆回技术层。
- 太小：单独交付没有用户能感知的价值 → 并进相邻的片。
- 合适：端到端、可独立交付、几天能做完。
10.4 切完之后：怎么接上后面的流程
/td-feature-discovery 的 multi 结果是一张薄菜单，每个 feature 带两样接下去要用的东西：一句可以直接喂给 /specify 的草稿，和一个清晰度判断。
挑一个 feature，照它的清晰度走：
- 清晰（意图、边界、例外、领域术语都没有歧义）→ 直接把那句草稿喂给
/specify。 - 不清晰 → 先用
/grill-with-docs把它那句草稿打磨清楚，再喂/specify。
这句草稿是初稿、起点，不是终稿。需求本就不清晰时，grill 正是用来打磨它的——所以不清晰的 feature 不要跳过 grill 直接 specify。打磨过程中产生的、需要长期保留的术语和决策，写进术语表或 ADR。
还有两件事决定要不要先绕一下：是否值得投入尚未决定时，先走 /speckit.assess 评估，得到放行再往下；是否先做一层轻架构或 UX 草图，由改动的性质决定——交互密集、信息架构还没谱的 feature，先定设计再 specify 更稳。
接的时候守两条：一次一个 feature，不要把整张菜单一起丢给 specify；按依赖顺序，先做被别人依赖的地基片。每个 feature 各自走一遍下一章的定档与交付流程。
命令名注意：菜单里写
/specify，实际项目里 spec-kit 命令通常带前缀（如/speckit.specify）。按你项目里的实际命令名用。
10.5 分解不替后面的步骤做决定
分解只回答”这坨是几个可交付单元、各自边界在哪、谁先谁后”。它不澄清领域细节（那是 grill）、不判断值不值得做（那是 assess）、不决定每个单元走多重的流程（那是下一章的任务分档）、不拆实现任务（那是 spec-kit 的 tasks）。
把这些下游责任留在下游，分解这一步才能保持薄和快。切出来的是一张”接下来一个一个做什么”的地图，不是设计文档。一张画过头的地图——提前写进验收条件、实现方案、任务清单——反而会在后面真正做每个 feature 时变成要不断返工的噪声。
本章小结
分解是把一坨需求按规模分层切成可交付单元：大的先用 /td-epic-discovery 分成面向用户的 Epic（分组容器，不可直接开发，人选分组轴），每个 Epic 再用 /td-feature-discovery 切成 feature。feature 必须是纵向切片——用户能感知的端到端结果，不是技术层；判断就问”只上这片用户能多做什么”。切出的每个 feature 带一句 specify 草稿和清晰度判断：清晰的直接 specify，不清晰的先 grill，一次一个、按依赖顺序接上后面的流程。Epic 层是选择性的，需求不大就跳过——分解覆盖的是能力，不是每次都走全程。
参考与出处
- 纵切优先、横切（按技术层切）是反模式：
docs/research/2026-10-26-vertical-vs-horizontal-story-slicing.md（Atlassian、Reddit r/agile 等多源一致） - PRD → Epic → Feature → Task 的分层分解链、Epic 的选择性与”不可直接开发”性质、三种分组轴：
docs/research/2026-10-26-prd-to-features-decomposition-methods.md（含 Atlassian 权威定义、BMAD 完整链） - 提示词正本：
template/.kiro/prompts/td-epic-discovery.md、td-feature-discovery.md