prd-generator

PRD 生成器

概述

生成全面、结构清晰且遵循行业最佳实践的产品需求文档（PRD）。此技能可帮助产品经理创建清晰、可执行的需求文档，以便协调利益相关方并指导开发团队。

核心工作流

当用户请求创建 PRD（例如：“为用户身份验证功能创建一份 PRD”）时，请遵循以下工作流：

步骤 1：收集背景信息

生成 PRD 之前，通过需求探索对话收集必要信息：

必需信息：

• 功能/产品名称：我们要构建什么？
• 问题陈述：要解决什么问题？
• 目标用户：面向哪些用户？
• 业务目标：我们想要实现什么？
• 成功指标：如何衡量成功？
• 时间线/限制条件：是否有截止日期或限制？

需求探索问题：

1. What problem are you trying to solve?
2. Who is the primary user/audience for this feature?
3. What are the key business objectives?
4. Are there any technical constraints we should be aware of?
5. What does success look like? How will you measure it?
6. What's the timeline for this feature?
7. What's explicitly out of scope?

**注意：**如果用户一开始就提供了详细的说明或需求，可以跳过部分问题。对于缺失的关键信息，务必询问以进行澄清。

步骤 2：生成 PRD 结构

使用 references/prd_template.md 中的标准 PRD 模板，创建结构清晰的文档。PRD 应包含：

1. 执行摘要 - 高层概述（2-3 段）
2. 问题陈述 - 清晰阐述问题
3. 目标与目的 - 我们想要实现什么
4. 用户画像 - 我们面向哪些用户
5. 用户故事与需求 - 详细的功能需求
6. 成功指标 - KPI 和衡量标准
7. 范围 - 范围内与范围外的内容
8. 技术考量 - 架构、依赖项、限制条件
9. 设计与 UX 需求 - UI/UX 考量
10. 时间线与里程碑 - 关键日期与阶段
11. 风险与缓解措施 - 潜在问题及解决方案
12. 依赖项与假设 - 我们所依赖的内容
13. 开放问题 - 尚未解决的事项

步骤 3：创建用户故事

针对每项主要需求，使用标准格式编写用户故事：

As a [user type],
I want to [action],
So that [benefit/value].

Acceptance Criteria:
- [Specific, testable criterion 1]
- [Specific, testable criterion 2]
- [Specific, testable criterion 3]

有关常见模式和最佳实践，请参阅 references/user_story_examples.md。

步骤 4：定义成功指标

根据产品类型使用适当的指标框架：

• AARRR（海盗指标）：获客、激活、留存、收入、推荐
• HEART 框架：愉悦度、参与度、采用率、留存、任务成功率
• 北极星指标：代表核心价值的单一关键指标
• OKR：目标与关键结果

有关各框架的详细指南，请参阅 references/metrics_frameworks.md。

步骤 5：验证与审查

可选择运行验证脚本，确保 PRD 内容完整：

scripts/validate_prd.sh <prd_file.md>

该脚本会检查：

• 是否包含所有必需章节
• 用户故事是否遵循正确格式
• 是否定义了成功指标
• 是否清晰阐述了范围
• 是否仍有占位文本

使用模式

模式 1：新功能 PRD

用户请求：“为我们的移动应用添加深色模式，创建一份 PRD”

执行：

1. 询问有关深色模式需求的探索性问题
2. 使用模板生成 PRD
3. 为以下内容创建用户故事：
   • 切换主题
   • 持久化保存偏好设置
   • 与系统级设置同步
   • 更新设计令牌
4. 定义成功指标（采用率、用户满意度）
5. 确定技术依赖项（设计系统、平台 API）

模式 2：产品增强 PRD

用户请求：“编写改进我们搜索功能的需求”

执行：

1. 收集有关当前搜索功能限制的信息
2. 确定用户痛点和期望的改进
3. 重点围绕以下内容生成 PRD：
   • 当前状态分析
   • 拟议的增强功能
   • 影响评估
4. 创建并确定用户故事的优先级
5. 定义改进前后的指标

模式 3：新产品 PRD

用户请求：“我需要一份新分析仪表板产品的 PRD”

执行：

1. 全面调研（市场分析、用户研究）
2. 生成完整 PRD，包含：
   • 市场机会
   • 竞品分析
   • 产品愿景
   • MVP 范围
   • 上市策略考量
3. 为核心功能编写详细的用户故事
4. 制定分阶段发布计划
5. 制定与业务目标一致的成功指标

模式 4：快速 PRD / 单页文档

用户请求：“为一个小型缺陷修复功能创建一份精简的 PRD”

执行：

1. 生成简化版 PRD，重点关注：
   • 问题陈述
   • 解决方案
   • 验收标准
   • 成功指标
2. 跳过与小范围项目无关的章节
3. 保持文档简洁（1-2 页）

PRD 最佳实践

写作质量要求

优秀的需求应当：

• 具体：清晰明确，没有歧义
• 可衡量：可以验证或测试
• 可实现：技术上可行
• 相关：与用户或业务价值相关
• 有时限：有明确的时间安排

避免：

• 含糊的措辞（“快速”“简单”“直观”）
• 实现细节（由工程师决定如何实现）
• 功能蔓延（聚焦核心需求）
• 未经验证的假设

用户故事最佳实践

应该：

• 关注用户价值，而非功能
• 从用户视角撰写
• 包含明确的验收标准
• 保持故事相互独立且精简
• 使用一致的格式

不应该：

• 编写技术实现细节
• 在故事之间建立依赖关系
• 将故事写得过于庞大（史诗级故事）
• 使用内部行话
• 省略验收标准

范围管理

范围内章节：

• 列出包含的具体功能和能力
• 明确并详细说明
• 链接到用户故事

范围外章节：

• 明确说明不包含哪些内容
• 防止范围蔓延
• 管理利益相关者的预期
• 可包含“未来考量”

成功指标指南

选择的指标应当：

• 与业务目标一致
• 可衡量、可跟踪
• 有明确的目标或阈值
• 同时包含先行指标和滞后指标
• 考虑用户和业务价值

常见指标类别：

• 采用情况：有多少用户在使用该功能？
• 参与度：用户使用频率如何？
• 满意度：用户喜欢这项功能吗？
• 性能：功能运行良好吗？
• 业务影响：功能是否推动了业务目标？

高级功能

适用于不同场景的 PRD 模板

该技能支持不同的 PRD 格式：

标准 PRD - 完整的综合文档
精益 PRD - 为敏捷团队精简的文档
单页文档 - 执行摘要格式
技术 PRD - 面向工程的需求
设计 PRD - 面向 UX/UI 的需求

提出请求时指定格式：“创建一份精益 PRD，用于……”或“生成一份技术 PRD，用于……”

与设计集成

设计需求章节应包含：

• 视觉设计需求
• 交互模式
• 无障碍要求（符合 WCAG）
• 响应式设计考量
• 要使用的设计系统组件
• 用户流程图
• 线框图/模型参考

技术考量章节

应涵盖：

• 架构：高层次技术方案
• 依赖项：外部服务、库、API
• 安全：身份验证、授权、数据保护
• 性能：加载时间、可扩展性要求
• 兼容性：浏览器、设备、平台支持
• 数据：存储、迁移、隐私考量
• 集成：如何与现有系统配合

利益相关方对齐

PRD 应当帮助：

• 对齐跨职能团队
• 明确预期
• 支持并行工作流
• 促进决策
• 提供唯一可信信息源

分发检查清单：

• 工程团队已评估技术可行性
• 设计团队已评审 UX 需求
• 产品领导层已批准范围
• 利益相关方了解时间安排
• 已就成功指标达成一致

常见 PRD 场景

场景 1：来自客户的功能请求

基于客户反馈创建 PRD 时：

1. 原文记录客户请求
2. 分析其根本问题
3. 将解决方案推广到所有用户
4. 根据产品战略进行验证
5. 合理确定范围（可能比请求的范围更小或更大）

场景 2：战略计划

为公司的战略计划创建 PRD 时：

1. 链接到公司 OKR／目标
2. 纳入市场分析
3. 考虑竞争格局
4. 考虑分阶段推出
5. 纳入与战略相一致的成功标准

场景 3：技术债务／基础设施

为技术改进创建 PRD 时：

1. 说明对用户的影响（即使是间接影响）
2. 记录当前限制
3. 阐明收益（速度、可靠性、可维护性）
4. 大量纳入工程团队的意见
5. 定义可衡量的改进

场景 4：合规／监管

为合规要求创建 PRD 时：

1. 引用具体法规（GDPR、HIPAA 等）
2. 纳入法务／合规审查
3. 截止日期通常不可协商
4. 聚焦于最低可行合规要求
5. 记录审计跟踪要求

验证与质量检查

自我审查清单

完成 PRD 定稿前，请确认：

• 问题清晰：任何人都能理解我们要解决什么问题
• 已明确用户：我们知道这是面向哪些用户的
• 成功可衡量：我们能够判断是否取得成效
• 范围明确：清楚界定包含和不包含的内容
• 需求可测试：QA 可以验证是否完成
• 时间安排合理：已与工程团队确认预估
• 已识别风险：我们已考虑可能出现的问题
• 利益相关方已对齐：关键人员已审查并批准

使用验证脚本

# Basic validation
scripts/validate_prd.sh my_prd.md

# Verbose output with suggestions
scripts/validate_prd.sh my_prd.md --verbose

# Check specific sections only
scripts/validate_prd.sh my_prd.md --sections "user-stories,metrics"

资源

此技能包含以下捆绑资源：

scripts/

• generate_prd.sh - 交互式 PRD 生成工作流
• validate_prd.sh - 验证 PRD 的完整性和质量

references/

• prd_template.md - 标准 PRD 模板结构
• user_story_examples.md - 用户故事模式和示例
• metrics_frameworks.md - PM 指标指南（AARRR、HEART、OKR）

给产品经理的建议

编写 PRD 之前

1. 做好调研：用户访谈、数据分析、竞争分析
2. 验证问题：确保值得解决
3. 检查战略一致性：这符合我们的路线图吗？
4. 估算工作量：与工程团队粗略评估 T 恤尺码
5. 考虑其他方案：这是最佳解决方案吗？

创建 PRD 期间

1. 表达清晰，不求巧妙：简单的语言更有效
2. 展示，而非讲述：使用示例、原型图和示意图
3. 考虑边缘情况：可能会出现什么问题？
4. 果断排定优先级：哪些属于 MVP，哪些属于锦上添花？
5. 尽早协作：不要闭门造车

完成 PRD 之后

1. 与利益相关方评审：尽早征求反馈
2. 根据反馈迭代：PRD 是持续演进的文档
3. 进行讲解，而不只是分享：逐步讲解 PRD
4. 取得正式签字批准：确保各方承诺
5. 持续更新：随着认知变化进行调整

示例

示例 1：移动端功能 PRD

# User: "Create a PRD for adding biometric authentication to our iOS app"

# Assistant will:
# 1. Ask discovery questions about security requirements, user personas, existing auth
# 2. Generate PRD covering:
#    - Problem: Password friction, security concerns
#    - Solution: Face ID / Touch ID integration
#    - User stories: Enable biometric, fallback to password, settings management
#    - Metrics: Adoption rate, login success rate, support tickets
#    - Technical: iOS Keychain, LocalAuthentication framework
#    - Risks: Device compatibility, user privacy concerns
# 3. Output formatted markdown PRD

示例 2：Web 平台增强

# User: "Write requirements for improving our checkout flow conversion"

# Assistant will:
# 1. Gather data on current conversion rates and drop-off points
# 2. Generate PRD including:
#    - Current state analysis with metrics
#    - Proposed improvements (guest checkout, saved payment, progress indicator)
#    - A/B test plan
#    - Success metrics: Conversion rate increase, time to checkout
#    - User stories for each improvement
# 3. Include phased rollout approach

示例 3：B2B 产品 PRD

# User: "I need a PRD for an admin dashboard for enterprise customers"

# Assistant will:
# 1. Identify B2B-specific requirements (multi-tenancy, permissions, reporting)
# 2. Generate comprehensive PRD with:
#    - Enterprise user personas (admin, manager, analyst)
#    - Role-based access control requirements
#    - Reporting and analytics needs
#    - Integration requirements (SSO, SCIM)
#    - Success metrics: Customer adoption, admin efficiency
# 3. Include enterprise-specific considerations (compliance, SLAs)

故障排除

问题：PRD 太长、太详细

解决方案：创建一份聚焦于问题、解决方案、验收标准和指标的「精简 PRD」。将完整 PRD 留给重大项目。

问题：需求太模糊

解决方案：添加具体示例，使用明确的数字，并加入视觉参考。将「快速」改为「在 2 秒内加载」。

问题：利益相关者意见不一致

解决方案：尽早以草稿形式分享 PRD，吸纳反馈，进行面对面介绍，并在开发开始前取得明确的批准。

问题：范围不断扩大

解决方案：充分使用「不在范围内」部分，为未来阶段创建单独的 PRD，并根据时间限制确定范围。

问题：工程师认为不可行

解决方案：更早让工程团队参与流程，对解决方案保持灵活，关注问题而非实现方式。

最佳实践总结

1. 从问题出发，而非解决方案
2. 面向受众撰写（高管需要摘要，工程师需要细节）
3. 具体且可衡量（避免模糊措辞）
4. 加入视觉内容（模型图、示意图、流程图）
5. 提前定义成功标准（关注指标，而非功能）
6. 严格控制范围（秉持 MVP 思维）
7. 协作，而非发号施令（征求各职能团队的意见）
8. 保持内容更新（PRD 是一份持续更新的文档）
9. 关注「为什么」和「是什么」，而非「怎么做」（让工程师解决「怎么做」）
10. 便于快速浏览（使用标题、项目符号和摘要）