---

name: idea-to-prd description: "一句话需求生成完整产品需求文档（PRD），包含用户故事、功能清单、MoSCoW优先级排序和验收标准。当用户提及编写PRD、产品需求文档、需求分析，或使用如“帮我把这个想法写成PRD”、“这个需求帮我细化一下”、“帮我拆解功能点”、“写用户故事”、“排优先级”、“定验收标准”等具体请求时触发。" license: MIT

PRD Architect

一句话需求 → 完整 PRD：通过结构化 SOP 流程，将模糊的产品想法转化为包含用户故事、功能清单、MoSCoW 优先级和验收标准的专业产品需求文档。

Quick Start

用户只需提供一句话描述需求，Agent 按照以下流程自动完成 PRD：

用户：我想做一个团队内部的知识库系统
Agent：[按 SOP 流程输出完整 PRD]

SOP 流程

Phase 1: 需求澄清（Requirement Elicitation）

目标：从用户的一句话需求中提取足够信息来构建 PRD。

操作步骤：

1. 解析原始需求：识别用户需求中的核心动词、目标对象和隐含约束
2. 提出澄清问题（最多 5 个关键问题）：
   • 目标用户是谁？（内部团队 / 外部客户 / 两者都有）
   • 要解决的核心痛点是什么？（现在怎么做的，哪里不好）
   • 有没有参考产品或竞品？
   • 有没有硬性约束？（时间、预算、技术栈、合规要求）
   • 成功的衡量标准是什么？（关键指标）
3. 如果用户要求跳过澄清，则基于合理假设继续，并在 PRD 的「假设与约束」章节中标明

输出：一份需求背景摘要（不超过 200 字）

---

Phase 2: 用户画像与用户故事（User Personas & Stories）

目标：识别所有关键角色，为每个角色编写用户故事。

操作步骤：

1. 识别用户角色（Persona）：

   • 列出 2-5 个核心角色

   • 每个角色用一句话描述其身份、目标和痛点

   • 格式：

     **角色名称**：[一句话描述]
     - 身份：[职位/角色]
     - 核心目标：[想达成什么]
     - 主要痛点：[现在遇到什么问题]
     

2. 编写用户故事（User Stories）：

   • 每个角色至少 3 条用户故事
   • 标准格式：作为[角色]，我想要[功能]，以便[价值/目的]
   • 用户故事必须满足 INVEST 原则：
     • Independent（独立）：故事之间尽量无依赖
     • Negotiable（可协商）：不锁定实现方式
     • Valuable（有价值）：对用户有明确价值
     • Estimable（可估算）：团队能评估工作量
     • Small（足够小）：一个迭代内可完成
     • Testable（可测试）：有明确的验证方式

3. 故事地图排列：按用户旅程的时间线排列故事，识别核心路径

输出：用户角色表 + 用户故事列表

---

Phase 3: 功能清单与分解（Feature Decomposition）

目标：将用户故事转化为具体的功能列表，区分功能性和非功能性需求。

操作步骤：

1. 功能性需求（Functional Requirements）：

   • 从每条用户故事中提取具体功能点
   • 每个功能点包含：
     • 功能编号（F-001, F-002...）
     • 功能名称
     • 所属用户故事编号
     • 功能描述（一句话说清做什么）
     • 输入 / 输出 / 交互说明

2. 非功能性需求（Non-Functional Requirements）：

   • 逐项检查以下维度，标注适用的：

     维度	检查项
     性能	响应时间、并发量、吞吐量
     安全	认证、授权、数据加密、合规
     可用性	SLA、容灾、备份恢复
     可扩展性	用户增长、数据增长、功能扩展
     易用性	学习成本、无障碍访问、多语言
     兼容性	浏览器、设备、操作系统、API 版本

3. 功能依赖关系：画出功能之间的前后依赖（哪些功能必须先做）

输出：功能需求表 + 非功能需求表 + 依赖关系说明

---

Phase 4: MoSCoW 优先级排序

目标：对所有功能按 MoSCoW 框架进行优先级分类。

MoSCoW 框架定义：

等级	含义	判断标准	占比建议
Must Have	必须有	没有它产品无法上线、用户核心流程走不通	约 60%
Should Have	应该有	重要但不致命，可以短期用替代方案	约 20%
Could Have	可以有	锦上添花，有了更好，没有也行	约 15%
Won't Have (this time)	暂不做	明确排除，避免范围蔓延，留到后续版本	约 5%

操作步骤：

1. 逐个功能评估：对每个功能回答三个问题：

   • 如果没有这个功能，产品能上线吗？（不能 → Must）
   • 如果没有这个功能，用户会明显不满吗？（会 → Should）
   • 这个功能是否有明确的替代方案？（有 → Could / Won't）

2. 优先级校验：

   • Must Have 不应超过总功能的 60%（超过说明拆分不够细）
   • Won't Have 必须至少有 1-2 项（说明做了取舍，不是全都要）
   • 检查 Must Have 之间的依赖链是否完整

3. 输出优先级矩阵表：

   | 功能编号 | 功能名称 | 优先级 | 理由 |
   |----------|----------|--------|------|
   | F-001    | xxx      | Must   | xxx  |
   

输出：MoSCoW 优先级矩阵

---

Phase 5: 验收标准（Acceptance Criteria）

目标：为每个 Must Have 和 Should Have 功能编写可测试的验收标准。

操作步骤：

1. 使用 Given-When-Then 格式：

   功能：F-001 用户登录
   
   AC-F001-01: 正常登录
   Given 用户已注册且账号状态正常
   When 用户输入正确的邮箱和密码并点击登录
   Then 系统跳转到首页，显示用户昵称
   
   AC-F001-02: 密码错误
   Given 用户已注册
   When 用户输入错误密码并点击登录
   Then 系统显示"邮箱或密码错误"，不透露具体是哪个错
   

2. 验收标准检查清单（每条 AC 必须满足）：

   • 是否只描述行为，不指定实现方式？
   • 是否可被独立验证（不依赖其他 AC）？
   • 是否覆盖了正常路径和至少一个异常路径？
   • 边界条件是否明确（数字范围、字符长度、空值处理）？
   • 是否有明确的预期结果（不是"正常工作"这种模糊描述）？

3. 覆盖率要求：

   • Must Have 功能：每个至少 3 条 AC（正常 + 异常 + 边界）
   • Should Have 功能：每个至少 2 条 AC（正常 + 异常）
   • Could Have 功能：每个至少 1 条 AC（正常路径）

输出：按功能分组的验收标准列表

---

Phase 6: 文档组装与输出

目标：将前五个阶段的产出组装成完整的 PRD 文档。

PRD 文档模板：

# [产品名称] - 产品需求文档（PRD）

> 版本：v1.0 | 作者：[填写] | 日期：[当前日期]
> 状态：草稿

## 1. 概述

### 1.1 背景与动机
[Phase 1 的需求背景摘要]

### 1.2 目标
- 业务目标：[要达成什么业务结果]
- 用户目标：[要解决用户什么问题]
- 成功指标：[KPI / 北极星指标]

### 1.3 范围
- 本期包含：[Must + Should 功能概述]
- 本期不包含：[Won't Have 列表及原因]

## 2. 用户画像

[Phase 2 的用户角色表]

## 3. 用户故事

[Phase 2 的用户故事列表，按角色分组]

## 4. 功能需求

### 4.1 功能清单
[Phase 3 的功能需求表]

### 4.2 非功能需求
[Phase 3 的非功能需求表]

### 4.3 功能依赖关系
[Phase 3 的依赖关系说明]

## 5. 优先级

### 5.1 MoSCoW 矩阵
[Phase 4 的优先级矩阵表]

### 5.2 版本规划建议
- MVP（v1.0）：所有 Must Have
- v1.1：所有 Should Have
- v2.0：评估 Could Have

## 6. 验收标准

[Phase 5 的验收标准列表，按功能分组]

## 7. 假设与约束

### 7.1 假设
- [列出所有假设，特别是 Phase 1 中因信息不足而做的假设]

### 7.2 约束
- 技术约束：[如有]
- 业务约束：[如有]
- 时间约束：[如有]

### 7.3 风险
| 风险 | 影响 | 概率 | 缓解措施 |
|------|------|------|----------|
| xxx  | 高   | 中   | xxx      |

## 8. 开放问题
- [ ] [待确认的问题 1]
- [ ] [待确认的问题 2]

## 附录
- 术语表（如有领域专业术语）
- 参考文档链接

文档输出要求：

• 所有表格使用 Markdown 格式
• 功能编号全局唯一且连续
• 用户故事编号与功能编号之间有清晰的映射关系
• 验收标准编号格式：AC-[功能编号]-[序号]（如 AC-F001-01）
• 日期使用当前实际日期

---

流程控制规则

交互模式选择

根据用户输入的详细程度选择模式：

用户输入	模式	行为
只有一句话（< 50 字）	引导模式	执行 Phase 1 提问，等用户回答后继续
有一定细节（50-200 字）	半自动模式	提出 2-3 个关键问题，同时开始 Phase 2
详细需求描述（> 200 字）	全自动模式	直接从 Phase 2 开始，跳过澄清
用户说"直接写/不用问"	快速模式	基于合理假设直接输出完整 PRD

质量检查清单

在输出最终 PRD 前，逐项检查：

• 每个用户角色都有至少 3 条用户故事
• 每条用户故事都映射到至少 1 个功能
• 每个功能都有 MoSCoW 优先级
• Must Have 占比不超过 60%
• Won't Have 至少有 1 项
• Must Have 功能都有至少 3 条验收标准
• 验收标准使用 Given-When-Then 格式
• 假设与约束章节非空
• 开放问题章节非空（总有未确认的事项）
• 所有编号连续且无遗漏

迭代优化

如果用户对 PRD 有反馈：

1. 定位反馈涉及的 Phase
2. 从该 Phase 重新执行
3. 向下级联更新所有受影响的内容
4. 保持编号体系一致性

参考方法论

本 SOP 综合了以下产品管理方法论：

• User Story Mapping（Jeff Patton）：用户故事地图方法
• MoSCoW Prioritization（DSDM / Agile）：需求优先级排序框架
• INVEST Principle：用户故事质量标准
• Behavior-Driven Development (BDD)：Given-When-Then 验收标准格式
• Kano Model（参考）：需求分类思想（基本型 → Must、期望型 → Should、兴奋型 → Could）