morning-start 需求分解器 (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)
🎯 为什么重要： 复述是对齐理解的第一个检查点。你理解的和用户说的可能是两回事——复述给用户一个反驳的机会。跳过这步，后续所有分析都可能建立在错误的基础上。
- 完整接收用户的原始需求文本
- 用自己的话复述需求的核心内容
- 标注已理解的部分和不确定的部分
示例：
用户说："帮我写一个任务管理工具" 你的复述："你的目标是做一个任务管理工具。我理解核心功能应该是创建任务、标记完成、查看列表。但我不确定：这是单人使用还是团队？需要 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
每次运行的必需输出（按顺序）：
- 📥 原始需求 + 🔄 理解复述 — 确认没跑偏
- 📊 结构化提取表 — Goal / Actor / Input / Output / Constraint / NFR / Context
- ❓ 澄清问题清单 — 🔴必须确认 / 🟡可以假设 / 🟢可忽略
- 🧩 任务分解树 — 子任务 + 优先级 + 依赖关系 + 技术选型
- 🚀 行动计划 — 立即执行项 + 风险 + 成功标准
质量标准：
- 复述中不能引入原始需求没有的信息（除非在假设中显式声明）
- 每个假设必须说明理由
- 每个技术选型建议必须有理由
- 叶子节点必须是单一步骤（不可再分）
- 澄清问题要具体到用户可以直接回答 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。