# Idea To Prd

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

- Skill: `haomingz/idea-to-prd` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add haomingz/idea-to-prd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/haomingz/idea-to-prd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: haomingz (https://skillmd.com/u/haomingz)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/haomingz/idea-to-prd

---


# 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 原则：
     - **I**ndependent（独立）：故事之间尽量无依赖
     - **N**egotiable（可协商）：不锁定实现方式
     - **V**aluable（有价值）：对用户有明确价值
     - **E**stimable（可估算）：团队能评估工作量
     - **S**mall（足够小）：一个迭代内可完成
     - **T**estable（可测试）：有明确的验证方式

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 文档模板**：

```markdown
# [产品名称] - 产品需求文档（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）