# Requirement Decomposer

> 将模糊、不完整的用户需求结构化拆解为可执行的任务。提取关键信息→识别歧义→分类模糊点→分解子任务→输出澄清问题与假设声明。⚠️ 一定要用！只要用户的需求描述中有模糊词汇（大概/尽量/适当/等等/之类的/视情况），或者只说了目标没说输入输出约束，或者需求缺少关键信息需要进一步明确——立即触发先拆解再动手。不要等到开始写代码/做方案才发现理解偏差。适用于：编程作业、产品PRD、技术方案、面试题、'帮我做个XX'类请求。当需求已经非常清晰明确时不要用。

- Skill: `morning-start/requirement-decomposer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add morning-start/requirement-decomposer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/morning-start/requirement-decomposer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: morning-start (https://skillmd.com/u/morning-start)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/morning-start/requirement-decomposer

---


# 需求分解器 (Requirement Decomposer)

## ⚡ Quick Reference

当需求模糊、不完整或有歧义时，按此流程执行。**有经验的模型可以先看这段速查，确认流程后再决定是否需要细读各 Phase。**

```
1️⃣ RESTATE  — 复述需求，标注已理解/不确定的部分
2️⃣ EXTRACT  — 提取 7 维信息：目标/角色/输入/输出/约束/非功能/上下文
3️⃣ CLARIFY  — 三分类模糊点：🔴必须确认 / 🟡可以假设 / 🟢可忽略
4️⃣ DECOMPOSE— 拆解为 P0/P1/P2 任务树 + 依赖关系 + 技术选型
5️⃣ PLAN     — 行动计划 + 风险 + 成功标准
```

详细说明和示例见下方对应 Phase。

## When to use

用户给出的需求**不完整、有歧义、或需要进一步明确**时使用。核心价值：在动手之前先确保理解正确。

**典型场景：**
- 编程作业/面试题（故意模糊，考察理解能力）
- 产品需求文档（PRD）片段
- 技术方案/架构设计要求
- "帮我做个 XX" 类模糊请求
- 任何需要「先想清楚再动手」的任务

**不要用的情况：** 需求已经非常清晰明确，可以直接执行；简单的单步查询或事实性问题。

**触发信号：** 用户需求中出现"大概"、"差不多"、"适当"、"等等"、"之类"、"视情况"等模糊词；或只有目标没有输入/输出/约束说明。

## Workflow

### Phase 1: 接收与复述 (RESTATE)

**🎯 为什么重要：** 复述是对齐理解的第一个检查点。你理解的和用户说的可能是两回事——复述给用户一个反驳的机会。跳过这步，后续所有分析都可能建立在错误的基础上。

1. **完整接收**用户的原始需求文本
2. **用自己的话复述**需求的核心内容
3. 标注**已理解的部分**和**不确定的部分**

**示例：**
> 用户说："帮我写一个任务管理工具"
> 你的复述："你的目标是做一个任务管理工具。我理解核心功能应该是创建任务、标记完成、查看列表。但我不确定：这是单人使用还是团队？需要 Web 界面还是命令行？数据要持久化吗？"
>
> 注意：不要凭空添加原文没有的信息（如"应该要甘特图/看板"），除非你在假设中显式声明。

**输出格式：**
```
## 📥 原始需求
> [粘贴用户的原始输入]

## 🔄 我的理解
[用一句话概括目标]
[列出已确认的关键要素]
```

### Phase 2: 结构化提取 (EXTRACT)

**🎯 为什么重要：** 人容易只关注目标而忽略约束和上下文。7 维框架确保你没有遗漏关键维度——特别是那些用户觉得"理所当然"没说出来的信息。

从需求中提取以下维度。**每一个维度都努力想一想：用户说的是否够具体？如果不够，这就是一个模糊点，留到 Phase 3 处理。**

| 维度 | 提取内容 | 示例 |
|------|----------|------|
| **目标 (Goal)** | 要达成什么？一句话说清 | "实现一个文件搜索功能" |
| **角色 (Actor)** | 谁在使用/谁关心结果？ | "终端用户 / 管理员" |
| **输入 (Input)** | 给了什么数据？格式？量级？ | "文件路径列表 + 关键词" |
| **输出 (Output)** | 期望什么结果？给谁？格式？ | "匹配的文件列表 + 高亮位置" |
| **约束 (Constraint)** | 有哪些硬性限制？ | "时间复杂度 O(n)、内存 < 100MB" |
| **非功能需求 (NFR)** | 性能/安全/可用性？ | "支持并发、需处理大文件" |
| **上下文 (Context)** | 为什么有这个需求？背景故事？ | "编程作业、考察需求理解能力" |

**技巧：** 如果一个维度原文完全没有信息，不要留空——标注为"未提及"，这本身就是 Phase 3 的输入。

### Phase 3: 歧义识别与分类 (CLARIFY)

**🎯 为什么重要：** 不是每个模糊点都需要追问用户。过度追问让用户烦，该问的不问导致返工。三分类帮你在"追问成本"和"理解风险"之间找到平衡。

对每个模糊点进行三分类。**分类原则记住一句话：如果不同答案会导致不同的技术方案，这就是 🔴；否则看有没有合理默认值。**

```
## ❓ 澄清问题清单

### 🔴 必须确认（Blocker）
| # | 模糊点 | 为什么重要 | 建议提问方式 |
|---|--------|-----------|-------------|
| 1 | ... | 不确认会导致... | "您希望...？" |

### 🟡 可以假设（Assumption）
| # | 模糊点 | 我的假设 | 假设理由 |
|---|--------|---------|---------|
| 1 | ... | 我假设... | 因为... |

### 🟢 可忽略/延后（Defer）
| # | 模糊点 | 为什么可忽略 |
|---|--------|-------------|
| 1 | ... | 不影响核心流程... |
```

**分类原则：**
- 🔴 **必须确认**：不同答案会导致完全不同的技术方案
- 🟡 **可以假设**：有合理默认值，且可以事后调整
- 🟢 **可忽略**：不影响当前阶段的核心决策

**提问技巧：** 优先封闭式提问（Yes/No 或二选一），降低用户回答成本。把所有 🔴 问题一次性列出，避免反复打扰用户。🟡 的假设直接给出默认值和理由，用户只需说"不对"即可。

### Phase 4: 子任务分解 (DECOMPOSE)

**🎯 为什么重要：** 大任务看起来让人生畏，拆成小步骤才知道从哪里开始。同时，拆解过程中会发现隐藏的依赖关系——"啊，要先做这个才能做那个"——避免执行到一半发现卡住。

将需求拆解为**可执行的子任务树**。选择适合场景的分解方法（流程拆解/数据流拆解/模块拆解/分层拆解）。

```
## 🧩 任务分解

### 任务树
[根任务]
├── [子任务 1] ⭐ P0（必须做）
│   ├── [步骤 1.1]
│   └── [步骤 1.2]
├── [子任务 2] ⭐ P0
│   └── ...
├── [子任务 3] ⭐ P1（应该做）
└── [子任务 4] ⭐ P2（可以做）

### 依赖关系
- [子任务 2] 依赖于 [子任务 1]
- [子任务 3] 和 [子任务 4] 可并行

### 技术选型建议
| 决策点 | 选项 A | 选项 B | 推荐 | 理由 |
|--------|--------|--------|------|------|
| 语言 | Python | JavaScript | 视场景 | ... |
| 数据结构 | 数组 | 哈希表 | 哈希表 | O(1)查找 |
```

**分解原则：**
- 每个**叶子节点**应该是**可直接执行的单一步骤**
- 标注**优先级**（P0/P1/P2）
- 标注**依赖关系**（`→` 阻塞依赖、`↔` 互相依赖、`||` 可并行）
- 给出**技术选型建议**——至少 2 个选项，附理由

**示例叶子节点（好的）：** "创建用户注册的表单组件：包含用户名、密码、邮箱三个输入框 + 提交按钮"
**示例叶子节点（坏的）：** "实现用户系统"——这个还可以继续拆！

### Phase 5: 行动计划 (PLAN)

**🎯 为什么重要：** 拆解只是分析，行动计划才是动手的起点。明确"现在能做什么"和"需要等什么"，让用户知道下一步怎么走。

```
## 🚀 建议行动计划

### 立即执行（本轮）
1. [第一步具体操作]

### 等待确认后执行
1. [依赖澄清问题的步骤]

### 风险点
- [风险1]: [缓解措施]
- [风险2]: [缓解措施]

### 成功标准
- ✅ [可验证的标准1]
- ✅ [可验证的标准2]
```

## 拆解深度控制

**拆到什么时候停？** 用一个简单检验：

- 这个子任务能**独立完成**吗？
- 预计 **30 分钟以内** 能搞定吗？
- 执行者看到这个任务不需要再问"这个具体怎么做"？

三个都是 Yes → ✅ 停在这里
任何一个 No → 继续往下拆

**反例：** "实现用户系统"（No, 需要再拆）
**正例：** "创建用户注册表单：包含用户名/密码/邮箱输入框 + 表单验证 + 提交按钮"

注意：不要过度拆解到实现细节级别（如"用 for 循环遍历数组"）——那是执行阶段的事，不是需求拆解阶段的事。

## Output contract

**每次运行的必需输出（按顺序）：**

1. **📥 原始需求 + 🔄 理解复述** — 确认没跑偏
2. **📊 结构化提取表** — Goal / Actor / Input / Output / Constraint / NFR / Context
3. **❓ 澄清问题清单** — 🔴必须确认 / 🟡可以假设 / 🟢可忽略
4. **🧩 任务分解树** — 子任务 + 优先级 + 依赖关系 + 技术选型
5. **🚀 行动计划** — 立即执行项 + 风险 + 成功标准

**质量标准：**
- 复述中不能引入原始需求没有的信息（除非在假设中显式声明）
- 每个假设必须说明理由
- 每个技术选型建议必须有理由
- 叶子节点必须是单一步骤（不可再分）
- 澄清问题要具体到用户可以直接回答 Yes/No 或给简短值

## Interaction mode

根据用户的原始意图选择模式：

### 模式 A：纯拆解（默认）
- 只做需求拆解，不执行实现
- 输出上述 5 个部分后等待用户反馈
- 用户补充信息后 → 切到模式 C 迭代精化
- 适用：用户说"帮我分析一下这个需求"

### 模式 B：拆解 + 引导执行
- 完成拆解后，主动按 P0→P1→P2 顺序推进执行
- 对 🟡 假设项逐一确认（"我假设了 X，对吗？"）
- 对 🔴 必须确认项等待回答后再继续
- 适用：用户说"帮我做这个"

### 模式 C：迭代精化
- 用户补充信息后，更新拆解结果
- 用 diff 标注变化部分（哪些理解变了/新增了/删除了）
- 重新输出完整的 5 个部分（不只是变化部分——给用户一个完整的更新画面）
- 适用：多轮对话中需求逐步清晰的过程

## Failure handling

| 场景 | 处理方式 |
|------|----------|
| 需求完全空白 | 请用户提供至少一句话描述 |
| 需求过于宽泛（如"做一个好的系统"） | 反问 3 个聚焦问题缩小范围 |
| 需求自相矛盾 | 列出矛盾点，请用户选择 |
| 无法判断技术可行性 | 标注为风险项，给出可行/不可行两种路径 |
| 用户对拆解结果不满意 | 询问哪部分不准确，针对性修正 |
| 需求在对话中变化 | 记录版本变更，切换到模式 C，输出 diff |
| 用户明确说"先做再说" | 切换到模式 B，但标注未确认的风险点，执行时保持警惕 |

## Tips & Anti-patterns

**✅ Do:**
- 先复述再分析，避免过早下结论
- 对每个假设显式声明
- 把"我不知道"转化为具体的澄清问题
- 用表格和树形结构呈现，比纯文字更清晰
- 给出技术选型建议时至少提供 2 个选项
- 检查"用户没说的信息"——缺失本身就是一个发现

**❌ Don't:**
- 不要替用户做业务决策（如"我觉得你应该做 X 功能"）
- 不要在没确认前就选定唯一技术方案
- 不要忽略模糊点假装一切都清楚
- 不要把一个叶子节点写成"实现 XXX"这种还需要拆解的大步骤
- 不要只输出不解释——每条结论都要有理由
- 不要过度拆解到"用 for 循环"这种实现细节级别

## References

详细的方法论指南（模糊度矩阵、模糊点检测模式、各 Phase 追问技巧、完整示例）见 `references/methodology.md`。