需求调研与澄清
目标与边界
将“想做一个功能”转成双方共同理解、证据可追溯的需求基线，按以下顺序推进：
现状与需求调研 → Grill Me 分轮澄清 → 需求基线确认。
本 Skill 提取自 prd-demo 的“建立需求基线”和“Grill Me需求澄清”环节，并将调研过程与确认成果独立整理。Grill Me 的决策树、问题前沿、分轮追问及最终确认规则已内置，可独立使用。
成果服务于后续产品方案设计。本 Skill 的范围止于需求基线，不自动制作原型、编写完整PRD或更新项目上下文。
启动与续接
- 用户要求完整需求澄清时，先调研，再分轮提问，最后确认。
- 用户只要求现状或需求调研时，完成调研并交付发现与待决策问题，停在该范围内。
- 用户已有调研资料或已确认决策时，先核对并复用，只补充影响本次需求的缺口；不要重复询问已明确的内容。
- 用户要求继续此前澄清时，从最新决策记录恢复。用户明确跳过或终止追问时，记录未确认假设及影响，交付当前基线并注明状态。
一、现状与需求调研
1. 读取材料并建立证据清单
优先阅读用户提供和当前环境可访问的业务需求、现网PRD、页面截图、已有原型、产品说明、业务数据及用户反馈。
- 为关键事实记录来源位置、版本或时间及适用范围；链接、文件章节或截图位置应能帮助复查。
- 区分文档描述、演示行为和已核验的现网行为；旧PRD或原型不能直接证明当前生产状态。
- 自行检索可从文件、原型、系统或工具获取的事实，不把可查的问题推给用户。
- 无法访问或核验的内容标为“待核实”，说明缺少什么材料；其他不依赖该事实的工作继续推进。
- 只有用户掌握的线下流程或经验可向用户了解，但记录为“用户陈述”，不要伪装成独立验证的事实。
- 需要外部研究时，按本次问题选择资料并标明来源与时间。尚未开展的访谈只能交付提纲，不能写成访谈结论；联系他人须有明确授权。
2. 梳理现状、问题与原始诉求
围绕本次需求整理以下内容，缺少证据的部分保留缺口：
- 现状：谁在什么场景下，按什么流程完成什么任务；有哪些入口、能力、规则、限制及系统分工。
- 问题：在哪一步受阻，造成什么用户或业务影响；影响哪些人，是否有频率、规模或数据证据。
- 原始诉求：提出了哪些新增、修改、替换或删除要求，诉求来自谁，其背后希望实现什么结果。
- 已有能力：哪些必须保留，哪些可能复用，哪些已被其他系统承担，避免将已具备的能力误当成新增需求。
把“增加一个按钮”等方案描述与背后的问题分开记录。没有证据时，不预设解决方式，也不编造指标基线、调研结论或目标值。
3. 建立需求基线草稿
始终区分四类信息：
| 类型 | 记录内容 | 处理方式 |
|---|---|---|
| 现状事实 | 现有流程、能力、规则及证据 | 注明已核验、文档描述或用户陈述 |
| 本次需求 | 原始诉求、问题及期望变化 | 作为调研输入，不自动视为已确认方案 |
| 已确认决策 | 用户明确选择的目标、范围或规则 | 记录对应问题、确认轮次或时间 |
| 待确认事项 | 缺失事实、材料冲突、待决策问题及假设 | 写明影响和依赖，不混入已确认内容 |
材料相互冲突时先核对来源、版本和适用场景；仍无法解释的差异列为待确认事项。新反馈与既有决策冲突时，明确指出变化，按用户最新明确确认更新并重开受影响的问题。
调研完成后先给出简短现状结论、主要问题和证据缺口，再进入澄清。需要整理书面成果时，读取 调研与确认成果模板，按实际需求选用章节。
二、建立 Grill Me 决策树
业务提问前读取 需求澄清提问库，将问题作为候选分支，按本次需求取舍，不机械地问完清单。
将相关决策组织为有依赖关系的树：
- 根决策通常包括要解决的问题、业务目标、成功标准、用户场景和本次范围。
- 下游决策可包括对象维度、主流程、关键状态、数据口径、系统职责及约束。
- 只有需求涉及运营配置、任务、奖励或权益时，才展开相应分支。
- 不将页面样式、原型交付格式或完整后台字段设计提前变成必答问题。
为问题记录编号、上游依赖及状态。状态可为“待取证”“待决策”“已确认”“不适用”或“用户明确延后”；延后项须注明影响和后续确认条件。
当前问题前沿：所有必要事实已具备、上游决策已明确，且仍需用户作出选择的问题。
事实检索未完成是一项未满足的前提，只阻塞依赖它的分支。可独立查证的工作可并行进行；有可用且获授权的子代理时，可将事实检索委派给子代理。最终业务选择仍交给用户。
例如：先确认需求是长期能力还是限时活动，再询问有效期、跨周期保留及到期规则。不能把这个前置选择和依赖它的规则放在同一轮。
三、按轮次澄清与压力测试
每轮执行以下协议：
- 重算当前前沿，合并重复问题，移除已确认或不适用的分支。
- 一次提出当前前沿的全部问题，逐题编号，给出推荐答案及理由。用户指定其他问法或节奏时按其要求调整，仍保留依赖约束。
- 提问只要求用户作决策或补充其独有信息；已有材料能回答的事实先自行查找。
- 发送本轮问题后等待回答，不自行代答，不提前展开依赖尚未明确的分支。
- 根据回答更新决策记录，重算下一轮前沿；用户只回答部分问题时，保留未答项并推进已解锁的独立分支。
- 回答改变上游决策时，重新核对下游结论，避免沿用已经失效的口径。
严格使用 Grill Me 的提问格式：
❓ **Q1** - **问题标题**：说明要确认的决策、必要背景及可比较的选项。
➡️ 推荐选择及理由；说明它成立所需的条件或主要取舍。
后续新问题连续编号，补答沿用原编号，便于回查。推荐答案只是建议；沉默、未回答或接受其他题目的推荐，都不能视为对此题的确认。
追问应检验会改变目标、范围或核心规则的假设，例如：
- 用户提出的是实际问题，还是未经验证的解决办法？不做本需求会有什么影响？
- 成功标准是否可判断？多个目标冲突时哪个优先？
- 多用户、多对象、时间边界、失败或重复操作是否会改变结果？
- 系统职责及数据来源是否明确？是否重复建设现有能力？
- 本期必须完成什么，哪些内容明确排除或延后？
保持直接、具体的追问，给出有依据的建议。压力测试用于暴露假设和取舍，不替用户作决定，也不为穷举无关场景增加问题。
四、需求确认与收口
当前前沿为空不自动代表澄清完成。先检查所有相关分支是否已有明确状态，且不存在“上游未回答，所以下游暂时未出现”造成的假收口。
收口前检查：
- 问题、目标、用户场景、成功标准及本次范围已明确。
- 影响范围或核心业务结果的关键规则与职责已明确；后续设计细节可以留在后续阶段。
- 需要保留的现有能力和证据缺口已记录，推荐答案与用户确认已分开。
- 延后事项已说明影响、确认条件及可知的责任方；仍阻塞核心判断的事项不能包装成“已完成澄清”。
按照 调研与确认成果模板 整理《需求调研与澄清确认单》，向用户展示完整基线并明确请求确认：
> 请确认这份需求基线是否准确反映我们的共同理解。如有偏差，请指出对应条目；确认后可将它作为后续方案设计的输入。
用户修改任何条目时，更新基线并重新检查受影响分支。确认单发生实质变化后，针对变化后的版本再次确认。
- 用户明确确认后，记录确认对象、版本或时间及保留项，状态为“已确认”。
- 尚未确认的文档，状态为“待确认”；用户终止追问或要求跳过时，状态为“部分澄清”，列出剩余假设及风险。
- 只有用户明确允许核心未决项延后，并确认受限范围时，才能标为“已确认（含保留项）”；不得暗示这些未决项也已确认。
- 逐题确认不替代对最终整合基线的确认。需求确认不等同于PRD定稿，不触发项目上下文更新。
交付与衔接
默认在对话中交付与当前阶段对应的成果；用户要求文件或需要交接时，输出Markdown文档：
- 调研成果：现状、问题、原始诉求、来源证据及待核实事项。
- 澄清过程：分轮问题、用户回答和关键决策记录。
- 确认成果：需求基线、范围、关键规则、保留项及确认状态。
交付时说明确认状态及影响后续工作的缺口。用户要求继续产品思路、原型或PRD时，将基线交给对应阶段；在使用 prd-demo 的环境中，可从其“产品思路”阶段续接，无需重复已完成的澄清。
