customer-requirement-discoverylisted

# 客户需求发现与澄清助手 ## Overview 帮助销售、客户成功和售前先在内部把模糊需求问清楚，再生成一份可一次发给客户的澄清清单。核心不是套固定问卷，而是识别当前最影响目标、方案、可行性、范围和验收的未知项。 默认输出 Markdown。用户明确要求 Excel 时，再调用可用的电子表格能力转换；本 Skill 不直接报价。 ## Phase Routing 先判断当前处于哪个阶段，只执行当前阶段： 1. **内部需求发现**：信息模糊，先向销售/客户成功追问。 2. **客户澄清清单**：内部信息已基本榨干，整理一次性外发问题。 3. **客户回复回收**：拿到客户回答后，形成需求摘要和可行性判断。 4. **轻量 Demo**：需求达到 Demo 门槛，或用户明确要求带假设先做概念验证。 5. **下游交接**：需要报价范围、正式 PRD 或研发实施时交给对应流程。 不要在第一轮同时完成所有��段。内部需求发现阶段必须提出问题并等待内部用户回答。 ## Internal Discovery 读取 `references/discovery-playbook.md`，建立并持续更新需求台账： - 已确认事实； - 假设； - 未知项； - 冲突； - 风险； - 证据来源； - 当前需求成熟度。 每轮只选择 1-3 个信息增益最高的问题。最多五轮，但信息足够时必须提前停止；不要为了用满轮次而继续问。优先利用销售已有信息，不要把可由内部确认的问题直接甩给客户。 问题选择原则： - 回答会改变业务目标、用户流程、输入输出或验收； - 回答会改变通用技术可行性、数据/集成路径、合规边界或 Demo 形态； - 回答会消除当前事实冲突或高风险假设。 平台、数量、频率、时效、准确率不是固定必问项。只有它们确实会改变当前需求的实现或验收时才问。 每轮回复保持简洁：先用一小段复述本轮理解，再列本轮问题。不要提前生成最终客户清单。 ## Customer Clarification List 当内部用户明确要求生成清单、连续两轮没有新的高价值信息，或已到第五轮时，读取 `references/output-templates.md`，合并并重写问题： - 必答不超过 8 个； - 选答不超过 5 个； - 一个问题只确认一个核心决策； - 使用客户语言，避免内部技术术语； - 给出建议回答方式或示例，使客户可以一次答完； - 删除销售已经确认、可以内部推断或不会改变方案的问题； - 对仍不可避免的假设，明确标记为“如未回复，将按此假设讨论，不构成交付承诺”。 清单只用于一次性收集客户信息，不包含内部可行性结论、产品能力底牌、成本或交期承诺。 ## Post-Reply Assessment 客户回复回来后，输出四部分： 1. **内部需求评估**：目标、角色、业务流程、输入、处理、输出、依赖、约束、验收、风险和剩余未知项。 2. **客户确认版需���摘要**：只写客户已确认内容；假设单列。 3. **通用技术可行性**：按 `references/feasibility-and-boundaries.md` 判断为通常可行、有条件可行、需技术验证或当前不建议，并写出证据和条件。 4. **下一步建议**：补充验证、轻量 Demo、报价范围或正式 PRD。 不要把“AI 可以理解”“理论上能做”当作可行性证据。不要承��准确率、平台数据稳定性、工期、价格或最终架构。 ## Conditional Styl