| name | product-discovery |
| description | 知识先行的产品需求发现与分析技能。从用户描述中提炼完整、可测量、无歧义的需求集合。 包含质量属性场景六要素、MoSCoW 优先级、需求 Rubric 评估。 基于 SAiP + Clean Architecture 方法论，配合 Generator-Evaluator 反 LLM 缺陷协议。 触发词：需求分析、需求发现、产品需求、质量属性、非功能需求、MoSCoW、用户故事、QAS。 当用户说"分析需求"、"整理需求"、"我要做一个 XXX 系统"时触发。
|
Product Discovery — 产品需求发现与分析
核心理念
知识先行，角色后置。
每个需求决策必须引用 knowledge/ 中的决策框架 [K]，不凭直觉。
生成（Generator）和评估（Evaluator）由不同角色执行。
文件结构
.claude/skills/product-discovery/
├── SKILL.md ← 你在这里
├── knowledge/requirements-quality.md ← SAiP+Clean Arch: QAS/ATAM/分层
├── knowledge/theory-of-constraints.md ← TOC: 五聚焦步骤/瓶颈/吞吐量会计
├── roles/product-analyst.md ← Generator: 需求发现 + 优先级
├── roles/reviewer.md ← Evaluator: 对抗性评估
├── references/PROTOCOL.md ← 反 LLM 缺陷协议（全程约束）
└── templates/
├── checkpoint.md ← 阶段检查点格式
├── progress.md ← design-progress.json 格式
└── requirements.md ← 需求规格输出格式
启动步骤
- 读取本文件 — 了解工作流
- 读取
.claude/skills/product-discovery/references/PROTOCOL.md — 了解反 LLM 缺陷约束
- 创建
design-progress.json — 格式见 .claude/skills/product-discovery/templates/progress.md
- 加载
.claude/skills/product-discovery/knowledge/requirements-quality.md — 需求分析的核心知识
- 加载
.claude/skills/product-discovery/knowledge/theory-of-constraints.md — TOC 约束理论
- 走收敛循环 — GENERATE → EVALUATE → RESOLVE → CHECK
- 产出 checkpoint — checkpoint-1-discovery.yaml
Sprint 契约
- 输入： 用户的产品描述
- 产出： 结构化需求列表（FR-xxx / NFR-xxx）+ checkpoint-1-discovery.yaml
- 收敛标准： Rubric 每项 ≥ 7/10
- 迭代： 持续直到收敛（不限轮次）
- Generator：
.claude/skills/product-discovery/roles/product-analyst.md
- Evaluator：
.claude/skills/product-discovery/roles/reviewer.md（或独立 Subagent）
收敛循环
┌─────────────────────────────────────────────────┐
│ GENERATE → EVALUATE → RESOLVE → CHECK │
│ (生成方案) (独立评估) (修正) (收敛检查) │
│ ▲ │ │
│ │ 未收敛 │ │
│ └──────────────────────────────────┘ │
│ 已收敛 ↓ │
│ CHECKPOINT（固化 + 交接） │
└─────────────────────────────────────────────────┘
步骤 1：收集原始输入
- 用户描述产品想法 → 提取关键词 → 识别领域
- 向用户提问（最多 5 个高质量问题，聚焦于消除歧义）
步骤 2：知识匹配
- 读取
.claude/skills/product-discovery/knowledge/requirements-quality.md
- 读取
.claude/skills/product-discovery/knowledge/theory-of-constraints.md — 用五聚焦步骤识别系统约束，指导优先级
- 用"质量属性场景六要素"检查每个非功能需求
- 用 TOC 五聚焦步骤识别系统瓶颈，高优需求必须针对约束
- 用"需求优先级矩阵" + TOC 吞吐量思维排序
步骤 3：GENERATE（product-analyst 角色）
- 整理出结构化需求列表（FR-xxx / NFR-xxx）
- 每个需求标注来源 [U]/[K]/[E]
- NFR 必须包含六要素：刺激源/刺激/环境/制品/响应/度量
步骤 4：EVALUATE（reviewer 角色，独立评估）
| 维度 | 权重 | 评估问题 |
|---|
| 完整性 | 35% | 核心流程是否覆盖？NFR 有六要素？ |
| 可测量性 | 30% | 每个 NFR 有具体数字？有无模糊词？ |
| 优先级清晰 | 20% | MoSCoW 是否合理？Top 3 是否针对系统约束？ |
| 排除项 | 15% | 显式声明不做什么？边界清晰？ |
强制找到 ≥2 个问题。向用户展示评估报告。
步骤 5：RESOLVE + CHECK
收敛条件（全部满足才可退出）：
- ✓ 每个 NFR 有六要素（刺激源/刺激/环境/制品/响应/度量）
- ✓ 需求按 MoSCoW 分类
- ✓ 无 [UNCERTAIN] / [A] 标记
- ✓ 用户确认 Top 3 优先级
- ✓ Rubric 每项 ≥ 7/10
步骤 6：产出 checkpoint-1-discovery.yaml + 更新 design-progress.json
关键规则
- GENERATE 和 EVALUATE 由不同角色执行
- EVALUATE 必须找到 ≥ 2 个问题
- 迭代不限轮次，持续直到 Rubric 收敛；仅当超出 LLM 能力时标
[ESCALATE]
- 所有决策标注来源：
[K] 知识 / [V] 已验证 / [E:置信度] 经验 / [U] 用户 / [A] 假设
[A] 必须在本阶段内消解，不允许 [A] 支撑 [A]- 角色 = 视角过滤器，不是人格模拟
与 domain-modeling 的衔接
本 skill 的 checkpoint-1-discovery.yaml 是 domain-modeling skill 的输入。
完成需求发现后，建议用户继续使用 domain-modeling skill 进行限界上下文划分。
