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）