name: prd-generator description: 为产品经理生成全面的产品需求文档（PRDs）。当用户请求“创建PRD”、“编写产品需求”、“记录功能”或需要帮助构建产品规范时使用此技能。
PRD 生成器
概述
生成全面、结构良好的产品需求文档（PRDs），遵循行业最佳实践。此技能帮助产品经理创建清晰、可操作的需求文档，以对齐利益相关者并指导开发团队。
核心工作流程
当用户请求创建PRD（例如，“为用户认证功能创建PRD”）时，遵循此工作流程：
步骤1：收集上下文
在生成PRD之前，通过发现对话收集基本信息：
所需信息：
- 功能/产品名称：我们正在构建什么？
- 问题陈述：这解决了什么问题？
- 目标用户：这是为谁？
- 业务目标：我们试图实现什么？
- 成功指标：我们将如何衡量成功？
- 时间线/约束：有任何截止日期或限制吗？
发现提问：
1. 你试图解决什么问题？
2. 此功能的主要用户/受众是谁？
3. 关键业务目标是什么？
4. 我们应该注意任何技术约束吗？
5. 成功看起来像什么？你将如何衡量它？
6. 此功能的时间线是什么？
7. 明确哪些是超出范围的？
注意： 如果用户提前提供了详细的简报或需求，可以跳过一些问题。始终要求澄清缺失的关键信息。
步骤2：生成PRD结构
使用 references/prd_template.md 中的标准PRD模板创建结构良好的文档。PRD应包括：
- 执行摘要 - 高级概述（2-3段）
- 问题陈述 - 问题的清晰阐述
- 目标与目的 - 我们试图实现什么
- 用户角色 - 我们为谁构建
- 用户故事与需求 - 详细功能需求
- 成功指标 - KPI和测量标准
- 范围 - 什么在范围内，什么在范围外
- 技术考虑 - 架构、依赖、约束
- 设计与UX需求 - UI/UX考虑
- 时间线与里程碑 - 关键日期和阶段
- 风险与缓解 - 潜在问题和解决方案
- 依赖与假设 - 我们依赖什么
- 开放问题 - 未解决的项目
步骤3：创建用户故事
对于每个主要需求，使用标准格式生成用户故事：
作为一个[用户类型]，
我想[行动]，
以便[好处/价值]。
验收标准：
- [具体、可测试的标准1]
- [具体、可测试的标准2]
- [具体、可测试的标准3]
参考 references/user_story_examples.md 获取常见模式和最佳实践。
步骤4：定义成功指标
根据产品类型使用适当的指标框架：
- AARRR（海盗指标）：获取、激活、留存、收入、推荐
- HEART框架：幸福、参与、采用、留存、任务成功
- 北极星指标：代表核心价值的单一关键指标
- OKRs：目标与关键结果
咨询 references/metrics_frameworks.md 获取每个框架的详细指导。
步骤5：验证与审查
可选运行验证脚本以确保PRD完整性：
scripts/validate_prd.sh <prd_file.md>
这检查：
- 所有必需部分存在
- 用户故事遵循正确格式
- 成功指标已定义
- 范围清晰表达
- 无占位符文本剩余
使用模式
模式1：新功能PRD
用户请求： “为我们的移动应用添加深色模式创建PRD”
执行：
- 询问关于深色模式需求的发现提问
- 使用模板生成PRD
- 为用户故事创建：
- 主题切换
- 偏好持久化
- 系统级同步
- 设计令牌更新
- 定义成功指标（采用率、用户满意度）
- 识别技术依赖（设计系统、平台API）
模式2：产品增强PRD
用户请求： “为改进我们的搜索功能编写需求”
执行：
- 收集当前搜索限制的上下文
- 识别用户痛点期望改进
- 生成PRD，重点在：
- 当前状态分析
- 提议的增强
- 影响评估
- 创建优先级用户故事
- 定义前后指标
模式3：新产品PRD
用户请求： “我需要一个新分析仪表板产品的PRD”
执行：
- 全面发现（市场分析、用户研究）
- 生成完整PRD，包括：
- 市场机会
- 竞争分析
- 产品愿景
- MVP范围
- 进入市场考虑
- 核心功能的详细用户故事
- 分阶段推出计划
- 与业务目标对齐的成功指标
模式4：快速PRD / 一页纸
用户请求： “为一个小错误修复功能创建一个轻量级PRD”
执行：
- 生成简化PRD，重点在：
- 问题陈述
- 解决方案方法
- 验收标准
- 成功指标
- 跳过不相关的部分
- 保持文档简洁（1-2页）
PRD最佳实践
编写质量需求
好需求是：
- 具体：清晰无歧义
- 可测量：可验证/测试
- 可实现：技术上可行
- 相关：与用户/业务价值相关
- 时间绑定：有清晰时间线
避免：
- 模糊语言（“快”、“容易”、“直观”）
- 实现细节（让工程师决定如何）
- 功能蔓延（坚持核心需求）
- 未经验证的假设
用户故事最佳实践
做：
- 专注于用户价值，而不是功能
- 从用户角度编写
- 包括清晰验收标准
- 保持故事独立且小
- 使用一致格式
不做：
- 编写技术实现细节
- 创建故事间依赖
- 使故事太大（史诗）
- 使用内部术语
- 跳过验收标准
范围管理
范围内部分：
- 列出具体包含的功能/能力
- 明确和详细
- 链接到用户故事
范围外部分：
- 明确说明不包括什么
- 防止范围蔓延
- 管理利益相关者期望
- 可以包括“未来考虑”
成功指标指南
选择指标：
- 与业务目标对齐
- 可测量和可跟踪
- 有清晰目标/阈值
- 包括领先和滞后指标
- 考虑用户和业务价值
典型指标类别：
- 采用：有多少用户使用此功能？
- 参与：他们使用频率如何？
- 满意度：用户喜欢它吗？
- 性能：它工作得好吗？
- 业务影响：它驱动业务目标吗？
高级功能
不同上下文的PRD模板
技能支持不同PRD格式：
标准PRD - 完整全面文档 精益PRD - 为敏捷团队简化 一页纸 - 执行摘要格式 技术PRD - 工程聚焦需求 设计PRD - UX/UI聚焦需求
请求时指定格式：“为…创建精益PRD”或“为…生成技术PRD”
与设计集成
设计需求部分应包括：
- 视觉设计需求
- 交互模式
- 可访问性需求（WCAG合规）
- 响应式设计考虑
- 设计系统组件使用
- 用户流程图
- 线框图/模型参考
技术考虑部分
应解决：
- 架构：高级技术方法
- 依赖：外部服务、库、API
- 安全：认证、授权、数据保护
- 性能：加载时间、可扩展性需求
- 兼容性：浏览器、设备、平台支持
- 数据：存储、迁移、隐私考虑
- 集成：如何与现有系统配合
利益相关者对齐
PRD应帮助：
- 对齐跨职能团队
- 设置清晰期望
- 启用并行工作流
- 促进决策制定
- 提供单一真相来源
分发检查清单：
- [ ] 工程审查技术可行性
- [ ] 设计审查UX需求
- [ ] 产品领导批准范围
- [ ] 利益相关者理解时间线
- [ ] 成功指标达成一致
常见PRD场景
场景1：来自客户的功能请求
当基于客户反馈创建PRD时：
- 记录客户请求原文
- 分析潜在问题
- 为所有用户泛化解决方案
- 用产品策略验证
- 适当范围（可能比请求小或大）
场景2：战略倡议
当为公司战略倡议创建PRD时：
- 链接到公司OKRs/目标
- 包括市场分析
- 考虑竞争格局
- 考虑多阶段推出
- 包括与策略对齐的成功标准
场景3：技术债务 / 基础设施
当为技术改进创建PRD时：
- 解释用户影响（即使间接）
- 记录当前限制
- 阐述好处（速度、可靠性、可维护性）
- 包括工程输入
- 定义可测量的改进
场景4：合规 / 监管
当为合规需求创建PRD时：
- 参考具体法规（GDPR、HIPAA等）
- 包括法律/合规审查
- 截止日期通常不可协商
- 专注于最小可行合规
- 文档审计跟踪需求
验证与质量检查
自审查检查清单
在最终确定PRD之前，验证：
- [ ] 问题清晰：任何人都能理解我们在解决什么
- [ ] 用户识别：我们知道这是为谁
- [ ] 成功可测量：我们可以确定它是否有效
- [ ] 范围有界：清楚什么在范围内外
- [ ] 需求可测试：QA可以验证完成
- [ ] 时间线现实：与工程验证的估计
- [ ] 风险识别：我们已经思考可能出错的地方
- [ ] 利益相关者对齐：关键人员已审查并批准
使用验证脚本
# 基本验证
scripts/validate_prd.sh my_prd.md
# 详细输出与建议
scripts/validate_prd.sh my_prd.md --verbose
# 仅检查特定部分
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、OKRs）
给产品经理的提示
在编写PRD之前
- 做你的研究：用户访谈、数据分析、竞争分析
- 验证问题：确保值得解决
- 检查战略对齐：这符合我们的路线图吗？
- 估计努力：与工程的粗略T恤大小
- 考虑替代方案：这是最佳解决方案吗？
在PRD创建期间
- 清晰，不聪明：简单语言胜出
- 展示，不告诉：使用示例、模型、图表
- 思考边缘情况：可能出错什么？
- 无情优先级：什么是MVP vs. 可有可无？
- 早期合作：不要孤立工作
在PRD完成后
- 与利益相关者审查：尽早获取反馈
- 基于输入迭代：PRD是活文档
- 展示，不只是分享：走过PRD
- 获取正式签字：确保承诺
- 保持更新：随着理解发展调整
示例
示例1：移动功能PRD
# 用户： “为我们的iOS应用添加生物识别认证创建PRD”
# 助理将：
# 1. 询问关于安全需求、用户角色、现有认证的发现提问
# 2. 生成PRD，覆盖：
# - 问题：密码摩擦、安全关切
# - 解决方案：Face ID / Touch ID集成
# - 用户故事：启用生物识别、回退到密码、设置管理
# - 指标：采用率、登录成功率、支持票务
# - 技术：iOS Keychain、LocalAuthentication框架
# - 风险：设备兼容性、用户隐私关切
# 3. 输出格式化Markdown PRD
示例2：Web平台增强
# 用户： “为改进我们的结账流程转换编写需求”
# 助理将：
# 1. 收集当前转换率和掉点数据
# 2. 生成PRD，包括：
# - 带指标的当前状态分析
# - 提议的改进（访客结账、保存支付、进度指示器）
# - A/B测试计划
# - 成功指标：转换率增加、结账时间
# - 每个改进的用户故事
# 3. 包括分阶段推出方法
示例3：B2B产品PRD
# 用户： “我需要一个为企业客户的管理仪表板PRD”
# 助理将：
# 1. 识别B2B特定需求（多租户、权限、报告）
# 2. 生成全面PRD，包括：
# - 企业用户角色（管理员、经理、分析师）
# - 基于角色的访问控制需求
# - 报告和分析需求
# - 集成需求（SSO、SCIM）
# - 成功指标：客户采用、管理员效率
# 3. 包括企业特定考虑（合规、SLAs）
故障排除
问题：PRD太长/太详细
解决方案：创建“精益PRD”，专注于问题、解决方案、验收标准和指标。为重大倡议保留完整PRD。
问题：需求太模糊
解决方案：添加具体示例，使用具体数字，包括视觉参考。用“在2秒内加载”替换“快”。
问题：利益相关者未对齐
解决方案：尽早分享PRD草稿，纳入反馈，亲自呈现，在开发开始前获取明确签字。
问题：范围不断扩展
解决方案：积极使用“范围外”部分，为未来阶段创建单独PRD，将范围与时间线约束绑定。
问题：工程师说不可行
解决方案：早期涉及工程过程，对解决方案方法灵活，专注于问题而不是实现。
最佳实践总结
- 从问题开始，而不是解决方案
- 为你的受众编写（高管需要摘要，工程师需要细节）
- 具体和可测量（避免模糊语言）
- 包括视觉（模型、图表、流程）
- 提前定义成功（指标，而不是功能）
- 积极范围（MVP心态）
- 合作，不 dictate（获取所有职能的输入）
- 保持更新（PRD是活文档）
- 专注于“为什么”和“什么”，而不是“如何”（让工程师解决“如何”）
- 使其可浏览（标题、项目符号、摘要）