需求开发（Requirement Development）

任务目标

把模糊的、一句话的、自相矛盾的原始需求，加工成研发可直接开工的标准化需求交付物。

核心不是「把用户说的话抄成文档」，而是在写文档之前先把需求想清楚。判断标准很简单：如果一份 PRD 交给研发，研发还要回头问「这个状态到底怎么流转」「异常了怎么办」「这个字段从哪来」，那这份文档就是失败的。

交付物三件套：

核心方法：金字塔原理 + MECE

需求分析的本质是结构化思考。本 skill 用麦肯锡金字塔原理做骨架：

四个基本原则

SCQA 定锚（第 1 轮必做）

> S 情境：业务/用户现在是什么状态（公认事实，不含判断）
> C 冲突：出现了什么变化或痛点（现状与期望的落差）
> Q 疑问：因此我们要解决什么问题
> A 答案：我们的核心主张（一句话结论，即需求的顶层）

MECE 拆解（第 2 轮必做）

把需求拆成互不重叠、无遗漏的维度树。软件产品需求的标准一级维度固定为 7 个：

需求（顶层）
├─ 1. 用户与角色 Who        —— 谁用、谁管理、谁受益
├─ 2. 场景与流程 When/How   —— 什么时机、走什么流程、谁触发
├─ 3. 功能与范围 What       —— 做什么、不做什么（含版本切分）
├─ 4. 数据与规则 Data/Rule  —— 字段、来源、状态机、计算与校验规则
├─ 5. 交互与体验 UX         —— 页面、反馈、空态/加载/错误态
├─ 6. 非功能性 NFR          —— 性能、安全、兼容、容量、可观测
└─ 7. 边界与依赖 Edge       —— 外部系统、前置依赖、里程碑、已知不做

> 完整维度树（含二级项）、三种拆解路径、MECE 自检五问、常见违反模式 → references/01-pyramid-mece.md

五阶段流程

Stage 0  接收与成熟度诊断  →  判定缺口规模，预告轮次
   ↓
Stage 1  金字塔顶层定锚    →  SCQA + 目标可度量（第 1 轮对话）
   ↓
Stage 2  MECE 拆解         →  维度树 + 逐项标注状态（第 2 轮对话）
   ↓
Stage 3  缺口诊断与引导    →  三类缺陷清单 + 常见做法选项（第 3~N 轮对话）
   ↓
Stage 4  完备性门禁        →  全绿才允许出稿；未决项须显式接受风险
   ↓
Stage 5  产出交付物        →  PRD(MD+Word) + 跟踪表(Excel) + HTML 原型

Stage 0 · 成熟度诊断

收到需求后先诊断，不急着问。用 6 个维度快速体检，判定成熟度等级并向用户预告需要几轮：

诊断结果要明确告诉用户：「你的需求目前是 L1，缺 X、Y、Z，预计 3 轮可以收敛。」

Stage 1 · 定锚（第 1 轮）

产出问题定义卡片，四项缺一不可：

1. S/C/Q/A 四句话
2. 业务目标：可度量，带基线与目标值（"支付转化率从 3.2% → 4.5%"）
3. 用户目标：用户为什么愿意用（JTBD 句式："当_时，我想要_，以便____"）
4. 北极星指标：单一指标 + 计算口径 + 数据来源

> 目标不可度量 → 记为 B 类缺陷（不清晰），必须回问。

Stage 2 · 拆解（第 2 轮）

铺开 7 个一级维度，每项标注四态之一：

这一步要让用户看到全貌：一张带标记的维度树，比任何文字描述都更能让用户意识到自己缺了什么。

Stage 3 · 诊断与引导（第 3~N 轮）

对每个非 ✅ 项，按三段式输出：

【缺陷】位置 + 类型（不完备/不清晰/不自洽）+ 严重度
【为什么】这会导致研发/设计/测试在哪一步卡住
【选项】2~4 个可选做法（含同类产品常见做法 + 适用条件 + 成本）

同类产品常见做法的取用顺序：
1. 先查内置做法库 references/03-common-practices.md（14 个功能域，开箱即用）
2. 命中不足或涉及新兴领域（AI 能力、新交互范式）→ 联网检索补充，必须标注来源与时效

> 三类缺陷的判定标准与记录格式 → references/02-diagnosis-rules.md
> 分轮话术与提问原则 → references/04-clarification-dialogue.md

Stage 4 · 完备性门禁

出稿前必须逐条过门禁，任何一条不通过都不得进入 Stage 5：

未决项的处理：允许用户选择「标记为待定并接受风险」——但必须逐条写明风险内容、影响面、默认取值，写进 PRD 的「待定与风险」章节，不允许静默跳过。

Stage 5 · 产出

运行脚本生成三件套（脚本位于本 skill 目录下，用绝对路径调用；依赖 python-docx / openpyxl，缺失时脚本会提示安装命令）：

# 1. PRD：Markdown → Word
python3 scripts/build_prd.py <PRD.md> -o <输出目录>

# 2. 需求跟踪表：从 PRD 中 REQ- 开头的表格行提取 → Excel
python3 scripts/build_traceability.py <PRD.md> -o <输出目录>

# 3. 原型：按 references/06-prototype-spec.md 手写单文件 HTML

> PRD 要素结构、需求条目规范（INVEST / Given-When-Then）、跟踪表字段 → references/05-prd-template.md
> 原型规范与走查清单 → references/06-prototype-spec.md
> 可直接填充的 PRD 骨架 → templates/prd-template.md

交互铁律（违反即判本 skill 执行失败）

1. 一次只推一层。先定锚、再拆解、后补细节。禁止第一轮就抛 20 个问题。
2. 每轮 3~5 个问题，优先出选择题而非开放题，并给出默认建议项（"建议选 B，因为……，你看行吗？"）。
3. 缺陷必须说清后果。只说"这里不清楚"是无效的，要说"这里不清楚会导致研发无法确定退款后库存是否回滚"。
4. 给做法，不给空白。每个缺口至少给 2 个可选做法，让用户选，而不是让用户填空。
5. 不静默跳过。任何未确认项要么问清楚，要么显式标记为风险项并写入文档。
6. 不擅自替用户做业务决策。可以强烈推荐，但涉及商业取舍（是否收费、是否强制、优先级）必须由用户拍板。
7. 需求变更要回检。用户中途改需求时，回到维度树检查是否引入新的不自洽，而不是只改那一处。
8. 出稿前必须过门禁。用户说"别问了直接出"时，走降级路径（04 第五节），但门禁不可跳过，未决项必须落到风险章节。

常见坑

资源索引