⚡

从想法到PRDSkill idea-to-prd

该技能能够将一句模糊的产品想法通过结构化SOP流程，自动转化为包含用户故事、功能清单、MoSCoW优先级排序和验收标准的完整产品需求文档（PRD），适用于产品经理和需求分析师快速生成专业文档。关键词：PRD生成、需求分析、用户故事、MoSCoW、验收标准、产品文档、SOP流程。

需求分析 0 次安装 2 次浏览 更新于 7/8/2026

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

PRD架构师

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

快速开始

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

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

SOP 流程

阶段一：需求澄清

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

操作步骤：

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

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

阶段二：用户画像与用户故事

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

操作步骤：

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

    • 列出 2-5 个核心角色

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

    • 格式：

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

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

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

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

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

阶段三：功能清单与分解

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

操作步骤：

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

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

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

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

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

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

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

阶段四：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 优先级矩阵

阶段五：验收标准

目标：为每个 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（正常路径）

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

阶段六：文档组装与输出

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

PRD 文档模板：

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

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

## 1. 概述

### 1.1 背景与动机
[阶段一的需求背景摘要]

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

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

## 2. 用户画像

[阶段二的用户角色表]

## 3. 用户故事

[阶段二的用户故事列表，按角色分组]

## 4. 功能需求

### 4.1 功能清单
[阶段三的功能需求表]

### 4.2 非功能需求
[阶段三的非功能需求表]

### 4.3 功能依赖关系
[阶段三的依赖关系说明]

## 5. 优先级

### 5.1 MoSCoW 矩阵
[阶段四的优先级矩阵表]

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

## 6. 验收标准

[阶段五的验收标准列表，按功能分组]

## 7. 假设与约束

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

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

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

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

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

文档输出要求：

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

流程控制规则

交互模式选择

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

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

质量检查清单

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

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

迭代优化

如果用户对 PRD 有反馈：

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

参考方法论

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

  • 用户故事地图（Jeff Patton）：用户故事地图方法
  • MoSCoW 优先级排序（DSDM / Agile）：需求优先级排序框架
  • INVEST 原则：用户故事质量标准
  • 行为驱动开发 (BDD)：Given-When-Then 验收标准格式
  • Kano 模型（参考）：需求分类思想（基本型 → Must、期望型 → Should、兴奋型 → Could）