serejaris PRD Architect
一句话需求 → 完整 PRD：通过结构化 SOP 流程，将模糊的产品想法转化为包含用户故事、功能清单、MoSCoW 优先级和验收标准的专业产品需求文档。
Quick Start
用户只需提供一句话描述需求，Agent 按照以下流程自动完成 PRD：
用户：我想做一个团队内部的知识库系统
Agent：[按 SOP 流程输出完整 PRD]
SOP 流程
Phase 1: 需求澄清（Requirement Elicitation）
目标：从用户的一句话需求中提取足够信息来构建 PRD。
操作步骤：
- 解析原始需求：识别用户需求中的核心动词、目标对象和隐含约束
- 提出澄清问题（最多 5 个关键问题）：
- 目标用户是谁？（内部团队 / 外部客户 / 两者都有）
- 要解决的核心痛点是什么？（现在怎么做的，哪里不好）
- 有没有参考产品或竞品？
- 有没有硬性约束？（时间、预算、技术栈、合规要求）
- 成功的衡量标准是什么？（关键指标）
- 如果用户要求跳过澄清，则基于合理假设继续，并在 PRD 的「假设与约束」章节中标明
输出：一份需求背景摘要（不超过 200 字）
Phase 2: 用户画像与用户故事（User Personas & Stories）
目标：识别所有关键角色，为每个角色编写用户故事。
操作步骤：
识别用户角色（Persona）：
列出 2-5 个核心角色
每个角色用一句话描述其身份、目标和痛点
格式：
**角色名称**：[一句话描述] - 身份：[职位/角色] - 核心目标：[想达成什么] - 主要痛点：[现在遇到什么问题]
编写用户故事（User Stories）：
- 每个角色至少 3 条用户故事
- 标准格式：作为[角色]，我想要[功能]，以便[价值/目的]
- 用户故事必须满足 INVEST 原则：
- Independent（独立）：故事之间尽量无依赖
- Negotiable（可协商）：不锁定实现方式
- Valuable（有价值）：对用户有明确价值
- Estimable（可估算）：团队能评估工作量
- Small（足够小）：一个迭代内可完成
- Testable（可测试）：有明确的验证方式
故事地图排列：按用户旅程的时间线排列故事，识别核心路径
输出：用户角色表 + 用户故事列表
Phase 3: 功能清单与分解（Feature Decomposition）
目标：将用户故事转化为具体的功能列表，区分功能性和非功能性需求。
操作步骤：
功能性需求（Functional Requirements）：
- 从每条用户故事中提取具体功能点
- 每个功能点包含：
- 功能编号（F-001, F-002...）
- 功能名称
- 所属用户故事编号
- 功能描述（一句话说清做什么）
- 输入 / 输出 / 交互说明
非功能性需求（Non-Functional Requirements）：
逐项检查以下维度，标注适用的：
维度 检查项 性能 响应时间、并发量、吞吐量 安全 认证、授权、数据加密、合规 可用性 SLA、容灾、备份恢复 可扩展性 用户增长、数据增长、功能扩展 易用性 学习成本、无障碍访问、多语言 兼容性 浏览器、设备、操作系统、API 版本
功能依赖关系：画出功能之间的前后依赖（哪些功能必须先做）
输出：功能需求表 + 非功能需求表 + 依赖关系说明
Phase 4: MoSCoW 优先级排序
目标：对所有功能按 MoSCoW 框架进行优先级分类。
MoSCoW 框架定义：
| 等级 | 含义 | 判断标准 | 占比建议 |
|---|---|---|---|
| Must Have | 必须有 | 没有它产品无法上线、用户核心流程走不通 | 约 60% |
| Should Have | 应该有 | 重要但不致命，可以短期用替代方案 | 约 20% |
| Could Have | 可以有 | 锦上添花，有了更好，没有也行 | 约 15% |
| Won't Have (this time) | 暂不做 | 明确排除，避免范围蔓延，留到后续版本 | 约 5% |
操作步骤：
逐个功能评估：对每个功能回答三个问题：
- 如果没有这个功能，产品能上线吗？（不能 → Must）
- 如果没有这个功能，用户会明显不满吗？（会 → Should）
- 这个功能是否有明确的替代方案？（有 → Could / Won't）
优先级校验：
- Must Have 不应超过总功能的 60%（超过说明拆分不够细）
- Won't Have 必须至少有 1-2 项（说明做了取舍，不是全都要）
- 检查 Must Have 之间的依赖链是否完整
输出优先级矩阵表：
| 功能编号 | 功能名称 | 优先级 | 理由 | |----------|----------|--------|------| | F-001 | xxx | Must | xxx |
输出：MoSCoW 优先级矩阵
Phase 5: 验收标准（Acceptance Criteria）
目标：为每个 Must Have 和 Should Have 功能编写可测试的验收标准。
操作步骤：
使用 Given-When-Then 格式：
功能：F-001 用户登录 AC-F001-01: 正常登录 Given 用户已注册且账号状态正常 When 用户输入正确的邮箱和密码并点击登录 Then 系统跳转到首页，显示用户昵称 AC-F001-02: 密码错误 Given 用户已注册 When 用户输入错误密码并点击登录 Then 系统显示"邮箱或密码错误"，不透露具体是哪个错验收标准检查清单（每条 AC 必须满足）：
- 是否只描述行为，不指定实现方式？
- 是否可被独立验证（不依赖其他 AC）？
- 是否覆盖了正常路径和至少一个异常路径？
- 边界条件是否明确（数字范围、字符长度、空值处理）？
- 是否有明确的预期结果（不是"正常工作"这种模糊描述）？
覆盖率要求：
- 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 有反馈：
- 定位反馈涉及的 Phase
- 从该 Phase 重新执行
- 向下级联更新所有受影响的内容
- 保持编号体系一致性
参考方法论
本 SOP 综合了以下产品管理方法论：
- User Story Mapping（Jeff Patton）：用户故事地图方法
- MoSCoW Prioritization（DSDM / Agile）：需求优先级排序框架
- INVEST Principle：用户故事质量标准
- Behavior-Driven Development (BDD)：Given-When-Then 验收标准格式
- Kano Model（参考）：需求分类思想（基本型 → Must、期望型 → Should、兴奋型 → Could）