# Unpack Requirements

> 当用户消息包含以下任一触发词时，必须使用本 skill，不要自行手动做需求分析："拆解需求"、"理清需求"、"捋一捋需求"、"盘需求"、/unpack-requirements。当用户描述的需求包含两个以上歧义点或明显缺口时同样触发。单个模糊点只需一句话确认，不启动完整流程。苏格拉底式提问逐层对齐需求：一次一个问题，从核心目标深入到边界情况和隐含假设。适用于功能设计、技术方案、项目规划、问题分析。

- Skill: `musicjayzhou/unpack-requirements` (Agent Skill)
- Install (CLI): `npx skillmds@latest add musicjayzhou/unpack-requirements`
- Raw SKILL.md: https://api.skillmd.com/api/skills/musicjayzhou/unpack-requirements/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: musicJayzhou (https://skillmd.com/u/musicjayzhou)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/musicjayzhou/unpack-requirements

---


# Unpack Requirements：苏格拉底式需求拆解

## 核心规则（ABSOLUTE）

1. **一次只问一个问题** — 绝不批量提问。即使想到了三个，只问当前最关键的那个。
2. **不问显而易见的问题** — 用户已说过的、代码/上下文能推断的，不重复问。每个问题必须需要真正的人类判断。
3. **每个问题基于前序回答** — 不是预设清单的第 N 项，而是对话链的自然延伸。
4. **主动 pushback** — 发现矛盾、过度工程、遗漏的边界情况时，直接指出。不让问题溜走。
5. **用户随时可以退出** — 当用户说"直接做吧"、"够了"、"跳过"时，立即基于现有信息收敛，不再追问。在摘要中标注尚未覆盖的维度作为风险提示。提问超过 4 轮时，在提问末尾附一句轻提示：`（随时可以让我跳过提问直接开始）`，让用户知道有这个选项。

## 自适应深度

判断锚点：**需求中涉及几个独立决策点**——1-2 个是简单，3-5 个是中等，6+ 个是复杂。第一个问题前信息不足时，先提一个最关键的问题，根据回答深度动态判断。

| 复杂度 | 信号 | 深度 |
|--------|------|------|
| 简单 | 改名、小 bug fix、单行配置 | 0-2 轮，确认后直接行动 |
| 中等 | 新功能模块、组件重构、流程变更 | 3-5 轮，聚焦核心歧义和最大风险 |
| 复杂 | 新项目、架构决策、跨系统集成 | 6+ 轮，多维度展开 |

简单任务过度提问是对用户时间的不尊重。

## 提问层次

从浅到深，根据对话进展选择层次：

| 层次 | 目的 | 触发时机 |
|------|------|----------|
| **澄清** | 消除歧义 | 用户用了模糊词汇，同一表述有多种解读 |
| **补全** | 发现信息缺口 | 用户描述中缺少关键信息（失败处理、性能要求等） |
| **挑战** | 暴露隐含假设 | 发现用户可能没意识到的假设 |
| **激发** | 拓展思考边界 | 核心需求已清晰，但有未考虑的维度或长期影响 |

最有价值的问题在「补全」和「激发」层——它们引入用户思维盲区中的信息。

**层次过渡信号：** 当某个层次连续两轮没有发现新信息，或用户对澄清类问题回答干脆无犹豫时，升级到下一层。

提问技巧：用具体场景锚定抽象问题（"如果同时有 100 个请求" 远胜 "高并发时"）；当用户思路不清晰时给 2-3 个选项而非开放式提问。

## 回响策略

根据用户的回答质量调整下一步：

- **回答清晰具体** → 简短确认，推进到下一个维度
- **回答模糊** → 用具体场景或选项帮助用户聚焦
- **回答与之前矛盾** → 直接引用前后两处回答，请用户澄清
- **"没想过这个"** → 这正是提问的价值。简要说明为什么这个角度重要，再引导思考
- **"你觉得呢"** → 给出你的分析和倾向性建议，但最终决定权交给用户

## 覆盖维度与进度追踪

在对话中跟踪已覆盖的维度。**不机械遍历**——根据需求性质选择最相关的跳转：

- **核心价值** — 到底在解决什么问题？谁受益？为什么是现在？
- **范围边界** — 明确不做什么？什么是非目标？
- **成功标准** — 怎么判断"做好了"？能否客观验证？
- **约束条件** — 有哪些硬限制？（时间/技术/资源/合规）
- **边界与异常** — 失败/极端情况下期望什么行为？
- **优先级** — 如果只能做一半，砍掉什么？
- **隐含假设** — 我们在假设什么但没说出口？

**进度展示：** 每轮提问前用一行展示覆盖状态，给用户掌控感：

```
✓ 核心价值  ✓ 范围边界  ◉ 成功标准  ○ 约束条件  ○ 边界与异常  ○ 优先级
```

**中途小结：** 每覆盖完 3 个维度后，用 1-2 句话回顾已达成的共识，再继续提问。

## 收敛条件

当以下条件满足时，主动提出收敛（核心价值 + 范围边界必须满足，成功标准和风险讨论满足其一即可）：

- ✓ 核心价值清晰
- ✓ 范围边界明确（至少明确了第一版范围）
- ✓ 成功标准可验证 **或** 最大的 1-2 个风险已被讨论
- 或提问已达当前复杂度上限轮数（兜底）

收敛时按复杂度分级输出：

**简单任务** — 一句话确认即可，无需摘要。

**中等任务** — 精简摘要：

```
**目标：** ……
**范围：** ……（明确不包含：……）
**关键决策：** ……
```

**复杂任务** — 完整摘要：

```
## 需求对齐摘要

**核心目标：** ……
**范围内：** ……
**范围外：** ……
**关键决策：** ……
**风险与应对：** ……
**成功标准：** ……
```

如有未覆盖的维度，在摘要末尾标注：`⚠ 尚未覆盖：[维度名]，可能存在未讨论的风险。`

请用户确认或修正。确认后才进入执行阶段。

## 反模式（NEVER）

- ❌ 一次抛出多个问题（"你想用 A 还是 B？另外目标用户是谁？"）
- ❌ 问用户已经回答过的内容
- ❌ 问从代码/上下文能推断的信息
- ❌ 问 agent 自己应该通过分析得出的问题（如"你觉得用 React 还是 Vue？"——agent 应该分析后给建议，而非把技术选题甩给用户）
- ❌ 对简单任务进行 5+ 轮提问
- ❌ 只在「澄清」层打转，不深入到「挑战」和「激发」
- ❌ 机械遍历所有维度，不顾需求性质
- ❌ 问题停留在抽象层面，不用具体场景锚定
- ❌ 忽视用户的退出信号，继续追问