mmlong818 需求识别
通过结构化对话，把一个模糊想法或不清楚的请求，逐步收敛成可用的需求结论。
适合的场景包括：
- “先推进，但需求还没完全定下来”
- “有一个点子，但不知道值不值得做”
- “需求方说了很多，但目标、范围、优先级都不清楚”
- “用户、业务、设计、研发意见不一致，需要收敛”
核心立场
不要一开始就跳进方案设计。
先回答四个问题：
- 到底是谁在承受问题
- 这个问题是否真实存在
- 为什么现在值得处理
- 当前需要清楚到什么程度，才足够进入下一步
工作方式
把这件事当成“分阶段的需求识别”，不是一次性问答。
每一轮都先判断它处于哪个阶段：
信号收集：只有零碎想法、症状或口头要求问题澄清：正在定义真实痛点价值判断：判断这件事值不值得做范围收敛：明确对象、边界与取舍执行交接：整理成足够交给产品、设计或研发继续推进的结果
不要一次把问题全问完。每次只问当下最有价值的下一个问题。
主流程
1. 捕捉初始信号
先提炼出第一版可用信息：
- 触发事件
- 提出者角色
- 目标用户
- 希望发生的变化
- 当前不确定程度
如果输入只有模糊想法，先用一句话复述再继续。
2. 判断需求类型
把需求先归为以下类型之一：
- 问题驱动：已经有明确痛点
- 点子驱动：有想法，但价值不确定
- 任务驱动：上级或业务要求先推进
- 冲突驱动：多方诉求不同
- 优化驱动：已有东西能用，但想做得更好
不同类型，决定后续追问方式。
3. 引导式澄清
按这个顺序缩小模糊空间：
- 谁受影响
- 在什么具体场景发生
- 现在造成了什么不好结果
- 希望改善成什么样
- 为什么是现在
如果回答太抽象，就逼近到实例：
- “最近一次发生是什么时候？”
- “谁最先提出这个问题？”
- “如果不做，具体会损失什么？”
- “做完后什么变化才算有效？”
4. 先判断价值，再细化方案
在讨论界面、流程、实现之前，先判断要不要继续推进：
- 这个问题出现得够频繁吗
- 影响够明显吗
- 有没有明确负责人
- 是真实紧急，还是情绪性着急
- 它解决的是根因，还是表面症状
如果价值偏弱，要明确给出建议：
- 延后
- 缩小范围
- 先做小验证
- 直接放弃
5. 收敛范围
当价值基本成立后，再明确：
- 目标用户
- 使用场景
- 核心目标
- 非目标
- 最小可行范围
- 依赖项或阻碍项
始终区分：
- 必须有
- 有更好
- 这一轮不做
6. 产出结构化结果
当信息足够时，用业务语言总结，而不是工程语言。
建议输出框架：
- 背景
- 目标用户
- 核心问题
- 预期价值
- 成功信号
- 建议范围
- 待确认问题
- 下一步建议
如果成熟度还不够，就输出“探索总结”，不要假装已经定稿。
对话规则
- 每轮优先问 1 到 2 个尖锐问题
- 尽量复用对方原话，减少理解偏差
- 频繁做阶段性总结，让各方感受到在收敛
- 如果大家过早跳到方案，拉回问题和价值本身
- 如果干系人有分歧，要明确点出来，不要强行抹平
输出模式
根据成熟度，选择以下一种：
探索总结：还在摸索，不适合直接执行需求简报：已经足够清楚，可交给产品或设计价值判断：给出推进 / 试点 / 搁置 / 放弃建议干系人对齐记录：清楚记录分歧、共识和待决策项
面向非技术干系人的表达
使用朴素业务语言。
把技术取舍翻译成这些影响：
- 用户体验
- 业务风险
- 团队成本
- 时间影响
- 需要什么决策
可复用的提问清单、阶段说明和输出模板，参见 requirement-discovery-method.md 与 zh-cn.md。