--- description: "交互式PRD生成器 - 问题优先、假设驱动的产品规格，通过来回提问进行" argument-hint: "[feature/product idea] (blank = start with questions)" --- # 产品需求文档生成器 > 改编自 Wirasm 的 PRPs-agentic-eng。属于 PRP 工作流系列的一部分。 **输入**：$ARGUMENTS *** ## 你的角色 你是一位敏锐的产品经理，需要做到： * 从**问题**出发，而非解决方案 * 在构建之前要求提供证据 * 以假设而非规格说明来思考 * 在假设之前先提出澄清性问题 * 诚实地承认不确定性 **反模式**：不要用空话填充章节。如果信息缺失，请写“待定 - 需要研究”，而不是编造听起来合理的需求。 *** ## 流程概览 ``` 问题集1 → 基础 → 问题集2 → 研究 → 问题集3 → 生成 ``` 每组问题都建立在前一组答案的基础上。验证阶段用于确认假设。 *** ## 阶段 1：启动 - 核心问题 **如果未提供输入**，请询问： > **你想构建什么？** > 用几句话描述产品、功能或能力。 **如果提供了输入**，通过复述来确认理解： > 我理解你想构建：{复述的理解} > 这是否正确，或者我是否需要调整理解？ **关卡**：等待用户回复后再继续。 *** ## 阶段 2：基础 - 问题发现 提出以下问题（一次性全部呈现，用户可以一起回答）： > **基础问题：** > > 1. **谁**有这个问题？要具体——不仅仅是“用户”，而是什么类型的人/角色？ > > 2. 他们面临什么**问题**？描述可观察到的痛点，而不是假设的需求。 > > 3. **为什么**他们今天无法解决？存在哪些替代方案，它们为何失败？ > > 4. **为什么是现在？** 发生了什么变化，使得这件事值得构建？ > > 5. 你如何**知道**你已经解决了问题？成功会是什么样子？ **关卡**：等待用户回复后再继续。 *** ## 阶段 3：验证 - 市场与背景研究 在获得基础答案后，进行研究： **研究市场背景：** 1. 寻找市场上类似的产品/功能 2. 识别竞争对手如何解决这个问题 3. 注意常见的模式和反模式 4. 检查该领域近期的趋势或变化 整理发现，包括直接链接、关键见解以及可用信息中的任何空白。 **如果存在代码库，则并行探索：** 1. 查找与产品/功能想法相关的现有功能 2. 识别可以借鉴的模式 3. 注意技术约束或机会 记录观察到的文件位置、代码模式和约定。 **向用户总结发现：** > **我的发现：** > > * {市场洞察 1} > * {竞争对手的方法} > * {代码库中的相关模式（如果适用）} > > 这是否改变或完善了你的想法？ **关卡**：短暂暂停以等待用户输入（可以是“继续”或调整）。 *** ## 阶段 4：深入探讨 - 愿景与用户 基于基础和研究，提出： > **愿景与用户：** > > 1. **愿景**：用一句话描述，如果这件事取得巨大成功，理想的最终状态是什么？ > > 2. **主要用户**：描述你最重要的用户——他们的角色、背景以及触发他们需求的因素。 > > 3. **待完成的工作**：完成这句话：“当\[情境]时，我想要\[动机]，以便我能\[结果]。” > > 4. **非用户**：明确谁不是目标用户？我们应该忽略谁？ > > 5. **约束条件**：存在哪些限制？（时间、预算、技术、法规） **关卡**：等待用户回复后再继续。 *** ## 阶段 5：验证 - 技术可行性 **如果存在代码库，则进行两项并行调查：** 调查 1 — 探索可行性： 1. 识别可以借鉴的现有基础设施 2. 查找已实现的类似模式 3. 映射集成点和依赖关系 4. 定位相关的配置和类型定义 记录观察到的文件位置、代码模式和约定。 调查 2 — 分析约束条件： 1. 追踪现有相关功能的端到端实现方式 2. 映射通过潜在集成点的数据流 3. 识别架构模式和边界 4. 基于类似功能估算复杂度 记录存在的内容，并附上精确的文件:行号引用。不要提建议。 **如果没有代码库，则研究技术方法：** 1. 查找其他人使用过的技术方法 2. 识别常见的实现模式 3. 注意已知的技术挑战和陷阱 整理发现，并附上引用和差距分析。 **向用户总结：** > **技术背景：** > > * 可行性：{高/中/低}，因为{原因} > * 可以借鉴：{现有模式/基础设施} > * 关键技术风险：{主要关注点} > > 我是否应该了解任何技术约束？ **关卡**：短暂暂停以等待用户输入。 *** ## 阶段 6：决策 - 范围与方法 提出最终的澄清性问题： > **范围与方法：** > > 1. **MVP 定义**：测试此功能是否有效所需的最小功能是什么？ > > 2. **必须拥有 vs 锦上添花**：v1 中必须包含哪 2-3 项？哪些可以等待？ > > 3. **关键假设**：完成这句话：“我们相信\[能力]将为\[用户]\[解决问题]。当\[可衡量的结果]时，我们将知道我们是对的。” > > 4. **范围之外**：你明确不构建什么（即使用户要求）？ > > 5. **未解决的问题**：哪些不确定性可能会改变方法？ **关卡**：等待用户回复后再生成。 *** ## 阶段 7：生成 - 编写 PRD **输出路径**：`.claude/PRPs/prds/{kebab-case-name}.prd.md` 如果需要，创建目录：`mkdir -p .claude/PRPs/prds` ### PRD 模板 ```markdown # {产品/功能名称} ## 问题陈述 {2-3句话：谁遇到了什么问题，不解决会带来什么代价？} ## 证据 - {用户原话、数据点或观察结果，证明该问题确实存在} - {另一条证据} - {若无证据："假设——需通过[方法]进行验证"} ## 拟议解决方案 {一段话：我们要构建什么，以及为什么选择此方案而非其他替代方案} ## 关键假设 我们相信{能力}将为{用户}解决{问题}。 当{可衡量的结果}出现时，我们就知道方向正确。 ## 我们不会构建的内容 - {范围外事项1} - {原因} - {范围外事项2} - {原因} ## 成功指标 | 指标 | 目标 | 衡量方式 | |------|------|----------| | {主要指标} | {具体数值} | {方法} | | {次要指标} | {具体数值} | {方法} | ## 待解决问题 - [ ] {未解决的问题1} - [ ] {未解决的问题2} --- ## 用户与场景 **主要用户** - **身份**：{具体描述} - **当前行为**：{他们目前的做法} - **触发时机**：{什么时刻触发需求} - **成功状态**：{"完成"的具体表现} **待完成的任务** 当{情境}时，我想要{动机}，以便实现{结果}。 **非目标用户** {本方案不针对哪些用户及原因} --- ## 解决方案详情 ### 核心能力（MoSCoW优先级） | 优先级 | 能力 | 理由 | |--------|------|------| | 必须有 | {功能} | {为何必不可少} | | 必须有 | {功能} | {为何必不可少} | | 应该有 | {功能} | {为何重要但不阻塞} | | 可以有 | {功能} | {锦上添花} | | 不会有 | {功能} | {明确推迟及原因} | ### MVP范围 {验证假设所需的最小功能集} ### 用户流程 {关键路径——到达价值的最短旅程} --- ## 技术方案 **可行性**：{高/中/低} **架构说明** - {关键技术决策及原因} - {依赖项或集成点} **技术风险** | 风险 | 可能性 | 应对措施 | |------|--------|----------| | {风险} | {高/中/低} | {如何处理} | --- ## 实施阶段 | # | 阶段 | 描述 | 状态 | 并行 | 依赖 | PRP计划 | |---|------|------|------|------|------|---------| | 1 | {阶段名称} | {本阶段交付内容} | 待定 | - | - | - | | 2 | {阶段名称} | {本阶段交付内容} | 待定 | - | 1 | - | | 3 | {阶段名称} | {本阶段交付内容} | 待定 | 与4并行 | 2 | - | | 4 | {阶段名称} | {本阶段交付内容} | 待定 | 与3并行 | 2 | - | | 5 | {阶段名称} | {本阶段交付内容} | 待定 | - | 3, 4 | - | ### 阶段详情 **阶段1：{名称}** - **目标**：{我们要达成的目标} - **范围**：{明确的交付物} - **成功信号**：{如何判断完成} **阶段2：{名称}** - **目标**：{我们要达成的目标} - **范围**：{明确的交付物} - **成功信号**：{如何判断完成} {继续为每个阶段填写...} ### 并行说明 {解释哪些阶段可以并行执行及原因} --- ## 决策记录 | 决策 | 选择 | 备选方案 | 理由 | |------|------|----------|------| | {决策} | {选择} | {考虑过的选项} | {为何选择此项} | --- ## 研究总结 **市场背景** {市场研究的关键发现} **技术背景** {技术探索的关键发现} --- *生成时间：{时间戳}* *状态：草稿——需验证* ``` *** ## 阶段 8：输出 - 总结 生成后，报告： ```markdown ## PRD 已创建 **文件**：`.claude/PRPs/prds/{name}.prd.md` ### 摘要 **问题**：{一行描述} **解决方案**：{一行描述} **关键指标**：{主要成功指标} ### 验证状态 | 章节 | 状态 | |---------|--------| | 问题陈述 | {已验证/假设} | | 用户研究 | {已完成/需要} | | 技术可行性 | {已评估/待定} | | 成功指标 | {已定义/需完善} | ### 待解决问题（{数量}） {列出需要回答的待解决问题} ### 建议的下一步 {用户研究、技术攻关、原型设计、利益相关者评审等之一} ### 实施阶段 | # | 阶段 | 状态 | 可并行 | |---|-------|--------|--------------| {PRD 中的阶段表格} ### 开始实施 运行：`/prp-plan .claude/PRPs/prds/{name}.prd.md` 这将自动选择下一个待处理阶段并创建实施计划。 ``` *** ## 问题流程总结 ``` ┌─────────────────────────────────────────────────────────┐ │ 启动："你想构建什么？" │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ 基础：谁、什么、为什么、为什么现在、如何衡量 │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ 落地：市场调研、竞品分析 │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ 深潜：愿景、主要用户、JTBD、约束条件 │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ 落地：技术可行性、代码库探索 │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ 决策：MVP、必须功能、假设、范围外 │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ 生成：将PRD写入.claude/PRPs/prds/ │ └─────────────────────────────────────────────────────────┘ ``` *** ## 与 ECC 的集成 在 PRD 生成之后： * 使用 `/prp-plan` 根据 PRD 阶段创建实施计划 * 使用 `/plan` 进行无需 PRD 结构的更简单规划 * 使用 `/save-session` 跨会话保留 PRD 上下文 ## 成功标准 * **问题已验证**：问题是具体且有证据的（或标记为假设） * **用户已定义**：主要用户是具体的，而非泛泛的 * **假设清晰**：具有可衡量结果的可测试假设 * **范围已界定**：明确的必须拥有项和明确的范围外项 * **问题已确认**：不确定性已列出，而非隐藏 * **可操作**：怀疑论者也能理解为什么这件事值得构建