# Requirement Discovery

> 通过多轮对话澄清模糊需求、判断点子价值，并推动用户、业务、产品、设计、交付等多方完成需求识别与收敛。适用于需求尚不明确、干系人存在分歧、一个想法是否值得做仍不确定，或需要把零散讨论整理成清晰目标、范围和下一步计划的场景。

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

---


# 需求识别

通过结构化对话，把一个模糊想法或不清楚的请求，逐步收敛成可用的需求结论。

适合的场景包括：

- “先推进，但需求还没完全定下来”
- “有一个点子，但不知道值不值得做”
- “需求方说了很多，但目标、范围、优先级都不清楚”
- “用户、业务、设计、研发意见不一致，需要收敛”

## 核心立场

不要一开始就跳进方案设计。

先回答四个问题：

1. 到底是谁在承受问题
2. 这个问题是否真实存在
3. 为什么现在值得处理
4. 当前需要清楚到什么程度，才足够进入下一步

## 工作方式

把这件事当成“分阶段的需求识别”，不是一次性问答。

每一轮都先判断它处于哪个阶段：

- `信号收集`：只有零碎想法、症状或口头要求
- `问题澄清`：正在定义真实痛点
- `价值判断`：判断这件事值不值得做
- `范围收敛`：明确对象、边界与取舍
- `执行交接`：整理成足够交给产品、设计或研发继续推进的结果

不要一次把问题全问完。每次只问当下最有价值的下一个问题。

## 主流程

### 1. 捕捉初始信号

先提炼出第一版可用信息：

- 触发事件
- 提出者角色
- 目标用户
- 希望发生的变化
- 当前不确定程度

如果输入只有模糊想法，先用一句话复述再继续。

### 2. 判断需求类型

把需求先归为以下类型之一：

- 问题驱动：已经有明确痛点
- 点子驱动：有想法，但价值不确定
- 任务驱动：上级或业务要求先推进
- 冲突驱动：多方诉求不同
- 优化驱动：已有东西能用，但想做得更好

不同类型，决定后续追问方式。

### 3. 引导式澄清

按这个顺序缩小模糊空间：

1. 谁受影响
2. 在什么具体场景发生
3. 现在造成了什么不好结果
4. 希望改善成什么样
5. 为什么是现在

如果回答太抽象，就逼近到实例：

- “最近一次发生是什么时候？”
- “谁最先提出这个问题？”
- “如果不做，具体会损失什么？”
- “做完后什么变化才算有效？”

### 4. 先判断价值，再细化方案

在讨论界面、流程、实现之前，先判断要不要继续推进：

- 这个问题出现得够频繁吗
- 影响够明显吗
- 有没有明确负责人
- 是真实紧急，还是情绪性着急
- 它解决的是根因，还是表面症状

如果价值偏弱，要明确给出建议：

- 延后
- 缩小范围
- 先做小验证
- 直接放弃

### 5. 收敛范围

当价值基本成立后，再明确：

- 目标用户
- 使用场景
- 核心目标
- 非目标
- 最小可行范围
- 依赖项或阻碍项

始终区分：

- 必须有
- 有更好
- 这一轮不做

### 6. 产出结构化结果

当信息足够时，用业务语言总结，而不是工程语言。

建议输出框架：

- 背景
- 目标用户
- 核心问题
- 预期价值
- 成功信号
- 建议范围
- 待确认问题
- 下一步建议

如果成熟度还不够，就输出“探索总结”，不要假装已经定稿。

## 对话规则

- 每轮优先问 1 到 2 个尖锐问题
- 尽量复用对方原话，减少理解偏差
- 频繁做阶段性总结，让各方感受到在收敛
- 如果大家过早跳到方案，拉回问题和价值本身
- 如果干系人有分歧，要明确点出来，不要强行抹平

## 输出模式

根据成熟度，选择以下一种：

- `探索总结`：还在摸索，不适合直接执行
- `需求简报`：已经足够清楚，可交给产品或设计
- `价值判断`：给出推进 / 试点 / 搁置 / 放弃建议
- `干系人对齐记录`：清楚记录分歧、共识和待决策项

## 面向非技术干系人的表达

使用朴素业务语言。

把技术取舍翻译成这些影响：

- 用户体验
- 业务风险
- 团队成本
- 时间影响
- 需要什么决策

可复用的提问清单、阶段说明和输出模板，参见 [requirement-discovery-method.md](./references/requirement-discovery-method.md) 与 [zh-cn.md](./references/zh-cn.md)。