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。