# Customer Requirement Discovery

> 客户需求发现与澄清助手：当用户是销售、客户成功或售前，拿到客户模糊、宽泛、缺少产品边界的需求，需要先在内部最多五轮补齐关键事实，再生成一次性客户澄清问题清单、需求摘要与通用技术可行性判断时使用；当确认需求将落入 StyleWork 时加载可选产品与 UI 上下文，并可在信息足够或明确要求时输出带假设标记的轻量 Demo。不要用于直接报价、承诺交期、替代正式 PRD 或在信息不足时假装已有能力。

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

---


# 客户需求发现与澄清助手

## 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 StyleWork Context

只有在用户或客户明确提到 StyleWork，或内部用户确认需求要落入 StyleWork 时，才读取：

- `references/stylework-product-context.md`
- `references/stylework-ui-baseline.md`
- `references/stylework-source-manifest.md`

StyleWork 场景必须把两类判断分开：

- **通用技术可行性**：不依赖某个产品，判断数据、模型、集成、流程、合规和验收是否成立。
- **StyleWork 适配判断**：映射为现有能力、直接复用、配置、扩展、新建或技术验证，并指出依据版本。

StyleWork 适配不能反向改写通用可行性。未经版本证据确认的 UI、菜单、数据源和第三方连接不得写成现有能力。

## Lightweight Demo

满足以下任一条件时才进入 Demo：

- 目标用户、核心任务、主要输入、关键处理、期望输出和 Demo 验证目标已基本明确；
- 用户明确要求在信息不足时先做概念 Demo，并接受显式假设。

先使用 `assets/demo-brief-template.md` 生成并展示 Demo Brief，再制作线框或带模拟数据的 HTML。信息不足但被要求立即制作时，必须在 Brief 和 Demo 中标记显式假设、待确认项、模拟数据和非生产边界。

Demo 不接生产后端，不暗示已接真实客户数据、外部平台或模型效果，不构成交付承诺。StyleWork 场景必须沿用现有 workspace/session/conversation 产品壳、资源选择卡、任务状态和 artifact 交互基线；不要凭空另造传统多菜单后台。

## Handoffs

- 需要只读排期建议时，交给 `stylework-requirement-planning`；需要正式 PRD 时交给 `prd-architect`。本 Skill 不再拆出一次性的独立报价/方案 Skill。
- 需要正式 PRD 时，交给适用的 PRD 工作流。
- 需要生产级 UI、接口和研发计划时，先完成正式需求与技术方案，不以轻量 Demo 替代。

交接时携带：客户原始表述、需求台账、客户回答、确认版摘要、可行性判断、风险、待验证项和 Demo Brief（如有）。

## Definition of Done

- 内部访谈未超过五轮，每轮 1-3 个高价值问题。
- 最终客户清单可一次回答，必答与选答数量受控。
- 事实、假设、未知项、冲突和风险没有混写。
- 通用技术可行性与产品适配判断分离。
- StyleWork 资料仅条件加载并标明证据版本。
- Demo 有明确验证目标、显式假设、模拟数据与非生产说明。
- 没有价格、工期、准确率、外部数据稳定性或现有能力的虚假承诺。

## Resource Guide

- `references/discovery-playbook.md`：内部访谈、问题选择和成熟度判断。
- `references/feasibility-and-boundaries.md`：通用技术可行性分级与承诺边界。
- `references/output-templates.md`：内部台账、客户清单和回收摘要模板。
- `references/stylework-product-context.md`：条件加载的产品能力与适配规则。
- `references/stylework-ui-baseline.md`：条件加载的产品结构与 Demo UI 规则。
- `references/stylework-source-manifest.md`：StyleWork 证据版本、可信度与更新规则。
- `assets/demo-brief-template.md`：轻量 Demo 开始前的必填 Brief。
- `evals/evals.json`：触发、非触发与历史失败回归场景。