requirement-discovery Skill：在方案设计前先刹车

requirement-discovery 的起点不是“让 AI 多问几个问题”，而是处理一个常见失速：用户只带着模糊方向来，AI 却迅速进入深度追问、功能拆解、PRD 草稿和方案设计。

• AI 很擅长继续往下做，但需求不清时，越深入越可能深入错方向。
• 看似专业的深度提问，会把用户带进还不该讨论的细节。
• 真正要先做的是判断需求是否成立，而不是马上把方案做完整。

这个 skill 的核心是刹车。它要求 agent 先判断自己处在 PRD 前阶段，先识别需求来源、角色、证据和 V0 边界，而不是急着证明自己会设计方案。

• 需求发现阶段要先问背景压力和需求来源，不问功能优先级。
• 如果用户还没有核心需求框架，就不要输出完整 PRD、完整原型或完整 V0 功能清单。
• 这和 reading-dialogue 的产品共创档刹车相呼应：一个防阅读跑偏，一个防需求跑偏。

requirement-discovery 先把对话档位分清：需求发现、需求澄清、方案设计、PRD 写作。只有前一档足够清楚，才能进入后一档。

• 需求发现：判断问题是否真实、来源是什么、谁受影响。
• 需求澄清：把用户、场景、问题、影响和目标压成核心需求框架。
• 方案设计和 PRD 写作必须等需求成形后再交给后续 skill。

它先判断需求来源：组织叙事、真实用户痛点、风险治理、技术包装，还是流程债。来源不同，后续验证方式和是否该做也不同。

• 组织叙事容易把战略目标包装成功能需求。
• 技术包装容易先选 AI，再反过来找场景。
• 流程债和风险治理往往不是缺功能，而是责任、异常和兜底没有显性化。

To B 和组织场景不能只问“用户是谁”。它要拆开决策者、买单者、操作者、日常用户和风险承担者，否则方案会默认所有人目标一致。

• 提出需求的人不一定每天使用。
• 日常用户觉得方便，不代表风险承担者接受。
• 如果 AI 判断会影响责任归属，就必须先知道谁为误判、漏判、投诉和事故负责。

需求发现要把“感觉像需求”转成可验证事实：当前流程、数据证据、角色链路、替代方案、约束条件和成功指标。

• 频次、耗时、损失、投诉、工单和人工成本比抽象痛点更能判断真假。
• 现有替代方案能说明用户到底愿意为问题付出多少成本。
• 证据不足时，下一步是调研或补材料，不是让 AI 补完方案。

核心需求成形后，才进入 V0 收敛。它不是把所有想法做小，而是选择最能验证核心需求、风险可控、边界清楚的第一步。

• 底座优先：先做人、身份、权限、认证接口和治理规则。
• 场景试点优先：先选一个高频、高痛、可控场景打穿。
• 风险治理优先：先处理损失、异常、追责、审计和兜底。

requirement-discovery 不负责把所有事情做完。它的收口是判断下一步该交给谁：PRD Skill、competitive-analysis、原型/spec，还是继续补事实。

• 要写 PRD 时，再交给 prd-skill。
• 需要外部对照时，再交给 competitive-analysis。
• 仍缺证据时，先停在需求发现，不自动切到方案设计。

requirement-discovery 的价值不是让 AI 少做，而是让 AI 在正确阶段做正确的事。它把模糊想法压成可判断的需求，再决定是否进入竞品、PRD、原型或计划。

• 当前形态是 PRD 前需求发现 workflow。
• 团队复用潜力在于把“先别急着写方案”变成稳定协作协议。
• 它和 competitive-analysis、prd-skill 形成完整链路：先判需求，再看竞品，再成文交付。