Pm Prd

---
name: prd
description: 产品经理专用的 PRD(产品需求文档)生成、优化与扩展工具。用于从自然语言描述创建结构化 PRD、对现有 PRD 进行澄清式审阅以补全模糊点、或向已有 PRD 追加新功能。当用户提到"写 PRD""生成产品需求文档""需求文档""优化/澄清 PRD""review PRD""给 PRD 加功能""PRD 新增需求"时使用此技能。
---

# PRD Skill - 产品需求文档生成、优化与扩展

本技能为产品经理提供三个核心工作流:

1. **生成模式 (generate)**: 从自然语言功能描述创建一份结构化 PRD
2. **澄清模式 (clarify)**: 审阅已有 PRD,识别模糊点并通过针对性问题帮助用户补全
3. **扩展模式 (extend)**: 向已有 PRD 追加新功能,保持术语/编号/优先级一致

## 模式判定

根据 `$ARGUMENTS` 和对话上下文判断走哪个模式:

- **扩展模式**: 参数同时包含一个**已存在的 PRD 文件路径**和一段**新功能的自然语言描述**(或用户明确说"给这个 PRD 加 xxx 功能""PRD 新增 xxx")
- **澄清模式**: 参数**只**含有指向已存在文件的路径,无新功能描述;或用户明确说"优化/澄清/review 这个 PRD"
- **生成模式**: 其他情况(纯自然语言功能描述,无文件路径)
- 文件存在但内容为空/全是占位符 → 当作生成模式处理
- 扩展和澄清的边界模糊时,看用户意图: "新增/追加/再加一个/还要支持" → 扩展;"这里没写清楚/含糊/review" → 澄清

不确定时,直接问用户一句确认,不要默默猜错模式。

---

## 模式一: 生成 PRD (Generate)

### 输入
用户通过 `$ARGUMENTS` 提供的功能/产品描述。关注 **What** 和 **Why**,不要陷入 **How**(技术栈、API、代码结构)。

### 输出位置
默认写入当前工作目录下的 `./prds/<short-name>.md`:

- 如果当前目录已经叫 `prd`、`prds`、`docs/prd` 或类似,直接写到 `./<short-name>.md`
- `short-name` 从描述中提炼 2-4 个词,用连字符连接,例如 `user-auth`、`photo-albums`、`fix-payment-timeout`
- 如果目标文件已存在,追加时间戳后缀避免覆盖(`<short-name>-YYYYMMDD.md`)
- 写文件前用 Bash `mkdir -p` 确保目录存在

**不要**涉及任何 git 操作(不创建分支、不 commit、不读 git 状态)。

### 执行流程

1. **解析输入**: 从功能描述中提取参与者 (actors)、操作 (actions)、数据 (data)、约束 (constraints)
2. **合理推测**: 对没明说的细节,基于行业标准和常见模式填默认值,并在"假设"章节记录
3. **限制澄清标记**: 最多保留 **3 个** `[NEEDS CLARIFICATION: 具体问题]` 标记,按优先级:范围 > 安全/隐私 > 用户体验 > 技术细节。有合理默认值的一律不标
4. **用户故事**: 按重要性排序 (P1/P2/P3),每个故事必须可独立测试、独立交付价值 (MVP 切片)
5. **功能需求**: 每条 `FR-NNN` 必须可测试、无歧义
6. **成功标准**: 每条 `SC-NNN` 必须可衡量、技术无关、以用户/业务视角描述
7. **使用下方模板**写入 PRD 文件
8. **质量自检**: 写完后对照"质量清单"逐项打勾,不过关就修改重写,最多迭代 3 次

### PRD 模板

```markdown
# 产品需求文档: [功能名称]

**创建时间**: [YYYY-MM-DD]
**状态**: 草稿
**输入描述**: "$ARGUMENTS"

## 用户场景与测试 *(必填)*

### 用户故事 1 - [简要标题] (优先级: P1)

[用通俗语言描述用户旅程]

**优先级原因**: [为什么是 P1 - 业务价值、用户痛点]

**独立测试**: [如何独立验证这个故事的价值,例如"通过 X 操作可完整体验并交付 Y 价值"]

**验收场景**:
1. **给定** [初始状态],**当** [用户操作],**那么** [预期结果]
2. **给定** [初始状态],**当** [用户操作],**那么** [预期结果]

---

### 用户故事 2 - [简要标题] (优先级: P2)

(结构同上)

---

### 用户故事 3 - [简要标题] (优先级: P3)

(结构同上)

---

### 边界情况

- 当 [边界条件] 时会发生什么?
- 系统如何处理 [错误场景]?
- [并发 / 超时 / 空数据 / 权限越界 等]

## 需求 *(必填)*

### 功能需求

- **FR-001**: 系统必须 [具体能力]
- **FR-002**: 用户必须能够 [关键交互]
- **FR-003**: 系统必须 [数据需求]
- **FR-004**: 系统必须 [行为]

### 关键实体 *(如涉及数据则包含)*

- **[实体 1]**: [代表什么,关键属性,不含实现细节]
- **[实体 2]**: [与其他实体的关系]

## 成功标准 *(必填)*

### 可衡量的结果

- **SC-001**: [用户可以在 N 分钟内完成 X]
- **SC-002**: [N% 的用户在首次尝试时成功]
- **SC-003**: [业务指标提升 N%]

## 假设

- [关于目标用户的假设]
- [关于范围边界的假设]
- [对现有系统的依赖]

## 超出范围 *(可选)*

- [本次明确不做的事]
```

### 质量清单 (Quality Checklist)

写完 PRD 后在内存中对照检查,不要写到文件里:

**内容质量**
- [ ] 不含实现细节(语言、框架、API)
- [ ] 聚焦用户价值和业务需求
- [ ] 为非技术干系人可读
- [ ] 所有必填章节已填写

**需求完整性**
- [ ] `[NEEDS CLARIFICATION]` 标记 ≤ 3 个
- [ ] 每条需求可测试、无歧义
- [ ] 成功标准可衡量、技术无关
- [ ] 所有验收场景已定义
- [ ] 边界情况已识别
- [ ] 范围边界清晰
- [ ] 依赖和假设已记录

**功能就绪度**
- [ ] 每条功能需求都有清晰的验收标准
- [ ] 用户场景覆盖主流程
- [ ] 符合成功标准中定义的可衡量结果

### 报告

写完后向用户报告:

- PRD 文件路径
- 生成的用户故事数量和优先级分布
- 遗留的 `[NEEDS CLARIFICATION]` 清单(如有)
- 建议下一步:"可运行 `/prd <path>` 进入澄清模式补全细节"

---

## 模式二: 澄清 PRD (Clarify)

### 目标

检测现有 PRD 中的模糊点或缺失的决策,**一次问一个问题**地与用户确认,把答案直接写回 PRD。总问题数上限 **5 个**。

### 执行流程

1. **加载 PRD**: 读取用户指定的文件。如果文件不存在或为空,提示用户先运行生成模式
2. **结构化扫描**: 按以下分类检查每个类别的状态(清晰 / 部分 / 缺失),**不要**把原始扫描结果输出给用户:

   - **功能范围与行为**: 核心目标、成功标准、超出范围声明、用户角色区分
   - **领域与数据模型**: 实体/属性/关系、唯一性、生命周期、数据量级
   - **交互与 UX 流程**: 关键旅程、错误/空/加载态、可访问性/本地化
   - **非功能属性**: 性能、可扩展性、可靠性、可观测性、安全隐私、合规
   - **集成与外部依赖**: 外部服务、数据导入导出、协议版本
   - **边缘情况**: 负面场景、限流、冲突解决
   - **约束与权衡**: 技术约束、已拒绝的替代方案
   - **术语一致性**: 术语表、避免的同义词
   - **完成信号**: 验收标准可测试性
   - **模糊占位符**: TODO、"robust"/"intuitive" 等无量化的形容词

3. **生成优先级问题队列** (≤5):
   - 每个问题必须可用多选(2-5 个互斥选项)或 ≤5 字的短答回答
   - 只问答案能实质影响架构/数据模型/测试/UX/运营/合规的问题
   - 类别平衡:先覆盖影响最大的未解决类别
   - 排除已答问题、风格偏好、规划层的执行细节
   - 如果候选 > 5,按(影响 × 不确定性)启发式选前 5

4. **顺序交互提问**: 一次**只问一个**问题,绝不提前泄露后续问题

   **多选题格式**:

   ```markdown
   **Q[N]: [主题]**

   **推荐**: 选项 [X] — [1-2 句推理:最佳实践 / 类似实现常见模式 / 风险降低 / 与 PRD 既有目标一致]

   | 选项 | 描述 |
   |------|------|
   | A | [描述] |
   | B | [描述] |
   | C | [描述] |
   | 自定义 | 提供不同的 ≤5 字短答 |

   你可以回复选项字母(如 "A")、说"是"或"推荐"接受推荐,或给出自己的 ≤5 字短答。
   ```

   **短答题格式**:

   ```markdown
   **Q[N]: [主题]**

   **建议**: [你建议的答案] — [简要理由]

   格式: ≤5 字短答。回复"是"/"建议"接受,或给出你自己的答案。
   ```

5. **用户回答后**:
   - 如果用户说 "yes"/"是"/"推荐"/"建议",使用之前声明的推荐作为答案
   - 否则验证答案映射到某选项或 ≤5 字约束,模糊则要求消歧(不计新问题)
   - 记录答案到工作内存,**立刻**把澄清应用到 PRD 对应章节并保存文件:
     - 功能模糊 → 更新或追加功能需求项
     - 用户交互/角色 → 更新用户故事或角色子章节
     - 数据形状/实体 → 更新关键实体
     - 非功能约束 → 更新成功标准中的可衡量结果(把模糊形容词换成指标)
     - 边缘情况 → 在边界情况下追加
     - 术语冲突 → 全文统一术语
   - 若澄清使早先声明失效,**替换**掉旧声明而不是留矛盾文本
   - 同时在 PRD 顶部维护 `## Clarifications` → `### Session YYYY-MM-DD` 子标题,追加一行 `- Q: <问题> → A: <最终答案>`。**同日多轮**: 如果当天已存在同名 session 标题,新会话使用 `### Session YYYY-MM-DD (2)`、`(3)` 递增编号,不要合并到已有 session 块

6. **停止条件**(满足任一即停):
   - 所有关键模糊已早期解决
   - 用户发出完成信号("done"/"stop"/"好了")
   - 已问满 5 个问题

7. **最终报告**:
   - 已问/已答问题数量
   - 更新的 PRD 文件路径
   - 涉及的章节清单
   - 覆盖范围摘要表(每个分类: 已解决 / 已推迟 / 清晰 / 未完成)
   - 建议下一步

### 行为规则

- 如果没有发现有意义的模糊,直接回应:"未检测到值得正式澄清的关键模糊点",建议继续下一阶段
- 如果 PRD 文件缺失或为空,指示用户先走生成模式,**不要**在澄清模式里新建 PRD
- 永远不超过总共 5 个问题(同一问题的消歧重试不计为新问题)
- 不要问投机性的技术栈问题,除非缺失会阻碍功能清晰性
- 尊重用户的提前终止信号
- 达到配额但仍有高影响未决项,在报告中明确标记"已推迟"并附理由

---

## 模式三: 扩展 PRD (Extend)

### 目标

向一份已有 PRD **追加一个或多个全新功能**,保持既有用户故事/实体/术语/编号/优先级分布的一致性,不破坏原有结构。

这不是"修正含糊点"(那是澄清模式的职责),而是**扩张范围**。

### 输入

参数同时包含:
- 一个已存在的 PRD 文件路径
- 一段描述新功能的自然语言

### 执行流程

1. **加载并吃透原 PRD**: 读取整份文件,在内存中提取以下上下文:
   - 产品/功能的整体目标
   - 既有用户故事清单及各自优先级 (P1/P2/P3...)
   - 功能需求最大编号 (如 `FR-012`)
   - 成功标准最大编号 (如 `SC-005`)
   - 关键实体清单及属性
   - 术语用法(例如是叫"用户"还是"使用者"、是叫"相册"还是"图集")
   - 假设与超出范围声明

2. **重复检查**: 判断新功能是否与既有内容重叠:
   - 如果新功能本质上已经被某个 P1/P2 用户故事覆盖 → **停下来**向用户说明并请求确认(不要偷偷加重复项)
   - 如果新功能是对既有功能的细化/修正 → **建议改走澄清或修正路径**,不要作为新功能追加
   - 如果确实是新功能 → 继续

3. **范围一致性检查**: 对照原 PRD 的"超出范围"章节(如有)。如果新功能明确在超出范围内,提醒用户这是范围扩张,需要确认后再加

4. **解析新功能**: 从描述中提取参与者/操作/数据/约束,按与生成模式相同的标准推断合理默认值

5. **优先级分配**:
   - 默认新故事的优先级为 `P(current_max + 1)`,即追加到现有最低优先级之后
   - 如果新功能明显比某个既有故事更关键(影响核心流程/安全/合规),向用户询问是否调整优先级 — **只问一次,不要反复确认**
   - 如果用户在描述里明确说了优先级("这个是 P1 的"),直接用

6. **追加用户故事**: 在用户故事章节末尾(边界情况章节之前)新增故事块,遵循原 PRD 的模板格式:
   ```markdown
   ### 用户故事 N - [标题] (优先级: PN)
   ...
   ```

7. **追加功能需求**: 从 `FR-(max+1)` 开始递增编号,新需求追加到功能需求列表末尾。**不要**重排或重编已有 FR

8. **按需更新其他章节**:
   - **关键实体**: 如果新功能引入新实体 → 追加;如果扩展了既有实体的属性 → 修改原实体条目(不要新建重复条目)
   - **成功标准**: 如果新功能有独立的可衡量目标 → 从 `SC-(max+1)` 开始追加
   - **边界情况**: 新功能相关的边缘场景追加到边界情况列表
   - **假设**: 如果新功能依赖新的假设 → 追加
   - **超出范围**: 如果新功能明确排除某些用法 → 追加

9. **术语统一**: 新内容必须复用原 PRD 已有术语。如果新描述用了不同叫法(比如原文是"相册",新描述是"图集"),自动归一到原文术语

10. **追加 `[NEEDS CLARIFICATION]` 标记**(可选): 仅对新功能的显著模糊点使用,最多 2 个(比整体生成模式更严格,因为整份 PRD 已有上下文可推断)

11. **维护变更日志**: 在 PRD 顶部(`## Clarifications` 之后或之前,统一位置)维护 `## Change Log` 章节,追加一行:
    ```markdown
    ## Change Log

    ### YYYY-MM-DD - Extend
    - 新增用户故事 N: [标题] (PN)
    - 新增功能需求: FR-XXX ~ FR-YYY
    - 新增/更新实体: [实体名]
    - 新增成功标准: SC-XXX ~ SC-YYY
    ```
    同日多次扩展时,追加新的子条目到当天的 `### YYYY-MM-DD - Extend` 块下,不要新建重复的日期标题

12. **保存文件**: 原子写回整份 PRD

13. **质量自检**(不落盘):
    - [ ] 新 FR 编号与既有编号连续,无冲突
    - [ ] 新用户故事的"独立测试"描述填写完整
    - [ ] 术语与原文一致(无同义词混用)
    - [ ] 没有重复/覆盖已有需求
    - [ ] 每个新 FR 可测试
    - [ ] 新 SC 可衡量、技术无关

### 报告

向用户报告:
- PRD 文件路径
- 本次新增内容清单(故事/FR/SC/实体/假设数量)
- 分配的优先级及理由
- 遗留的 `[NEEDS CLARIFICATION]`(如有)
- 如果扩展使原 PRD 的某些声明需要更新(比如"超出范围"应当删除某项),明确列出**建议用户后续处理的事项**,不要自己静默修改这些边界
- 建议下一步: "可运行澄清模式补全新功能的细节"

### 行为规则

- **不重排已有内容**: 所有既有用户故事、FR、SC、实体的顺序和编号保持不变
- **不覆盖已有内容**: 除非扩展确实使原声明失效(例如新功能让原"超出范围"条目作废),此时需明确在报告中提示用户
- **不跨模式混用**: 扩展模式只负责追加;如果用户在扩展过程中提到既有内容的模糊点,记录下来并建议在扩展完成后运行澄清模式处理
- **单次扩展可包含多个相关功能**: 如果用户描述的是一组相关子功能(例如"加分享功能,包括生成链接、设置过期时间、查看分享记录"),作为一个扩展会话处理,可以产出多个用户故事,但它们应围绕同一个业务主题

---

## 通用规则

- **语言**: 除非用户明确要求英文,PRD 内容一律用中文撰写
- **无 git 集成**: 不创建分支、不 commit、不调用 git 命令
- **不执行任何脚本**: 所有文件操作直接用 Write/Edit/Read/Bash mkdir 完成
- **关注 What/Why**: 避免描述 How(技术栈、实现细节、框架选型)
- **为业务相关方写**: 用通俗语言,而不是开发者术语
- **不要**在 PRD 中嵌入任何检查清单章节(质量清单只用于自检,不落盘)