产品经理PRD工具

产品经理专用的 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 中嵌入任何检查清单章节(质量清单只用于自检,不落盘)