Prd Generator

PRD 生成器

概述

生成全面、结构良好的产品需求文档（PRD），遵循行业最佳实践。此技能帮助产品经理创建清晰、可操作的需求文档，使利益相关者保持一致并指导开发团队。

核心工作流程

当用户请求创建 PRD 时（例如，"为用户认证功能创建 PRD"），请遵循以下工作流程：

步骤 1：收集上下文

在生成 PRD 之前，通过发现对话收集必要信息：

必需信息：

• 功能/产品名称：我们正在构建什么？
• 问题陈述：这解决了什么问题？
• 目标用户：这是为谁准备的？
• 业务目标：我们试图实现什么？
• 成功指标：我们将如何衡量成功？
• 时间线/约束：有任何截止日期或限制吗？

需要询问的发现问题：

1. 您试图解决什么问题？
2. 此功能的主要用户/受众是谁？
3. 关键业务目标是什么？
4. 有没有我们应该了解的技术约束？
5. 成功是什么样子的？您将如何衡量它？
6. 此功能的时间线是什么？
7. 明确不在范围内的内容是什么？

注意： 如果用户预先提供了详细的简报或需求，您可以跳过一些问题。对于缺失的关键信息，始终要求澄清。

步骤 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：创建用户故事

对于每个主要需求，使用标准格式生成用户故事：

作为 [用户类型]，
我希望 [行动]，
以便 [收益/价值]。

验收标准：
- [具体、可测试的标准 1]
- [具体、可测试的标准 2]
- [具体、可测试的标准 3]

参考 references/user_story_examples.md 获取常见模式和最佳实践。

步骤 4：定义成功指标

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

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

查阅 references/metrics_frameworks.md 获取每个框架的详细指南。

步骤 5：验证与审查

可选运行验证脚本来确保 PRD 完整性：

scripts/validate_prd.sh 

这会检查：

• 所有必需部分都存在
• 用户故事遵循正确格式
• 成功指标已定义
• 范围明确阐述
• 没有剩余的占位符文本

使用模式

模式 1：新功能 PRD

用户请求： "为我们的移动应用添加深色模式创建 PRD"

执行：

1. 询问关于深色模式需求的发现问题
2. 使用模板生成 PRD
3. 为以下内容创建用户故事：

• 主题切换
• 偏好持久化
• 系统级同步
• 设计令牌更新

1. 定义成功指标（采用率、用户满意度）
2. 识别技术依赖项（设计系统、平台 API）

模式 2：产品增强 PRD

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

执行：

1. 收集关于当前搜索限制的上下文
2. 识别用户痛点和期望的改进
3. 生成 PRD，重点关注：

• 当前状态分析
• 提议的增强
• 影响评估

1. 创建优先排序的用户故事
2. 定义前后指标

模式 3：新产品 PRD

用户请求： "我需要为新的分析仪表板产品创建 PRD"

执行：

1. 全面发现（市场分析、用户研究）
2. 生成完整 PRD，包括：

• 市场机会
• 竞争分析
• 产品愿景
• MVP 范围
• 上市考虑

1. 核心功能的详细用户故事
2. 分阶段推出计划
3. 与业务目标一致的成功指标

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

用户请求： "为小型错误修复功能创建轻量级 PRD"

执行：

1. 生成简化的 PRD，重点关注：

• 问题陈述
• 解决方案方法
• 验收标准
• 成功指标

1. 跳过与小范围无关的部分
2. 保持文档简洁（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 可以验证完成
• [ ] 时间线现实：估计与工程验证
• [ ] 风险已识别：我们已考虑可能出错的情况
• [ ] 利益相关者对齐：关键人员已审查并批准

使用验证脚本

# 基本验证
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 模板结构
• userstoryexamples.md - 用户故事模式和示例
• metrics_frameworks.md - PM 指标指南（AARRR、HEART、OKR）

产品经理提示

编写 PRD 之前

1. 做研究：用户访谈、数据分析、竞争分析
2. 验证问题：确保值得解决
3. 检查战略对齐：这是否符合我们的路线图？
4. 估计工作量：与工程进行粗略估算
5. 考虑替代方案：这是最佳解决方案吗？

PRD 创建期间

1. 清晰，而非聪明：简单语言获胜

2 展示，而非讲述：使用示例、模型、图表

1. 考虑边缘情况：可能出错的情况？
2. 无情优先排序：什么是 MVP 与锦上添花？
3. 早期协作：不要孤立工作

PRD 完成后

1. 与利益相关者审查：尽早获取反馈
2. 根据输入迭代：PRD 是活文档
3. 展示，而非仅共享：遍历 PRD
4. 获取正式签字：确保承诺
5. 保持更新：随着理解的发展进行调整

示例

示例 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. 包括企业特定考虑（合规性、SLA）

故障排除

问题：PRD 过长/详细

解决方案：创建"精益 PRD"，专注于问题、解决方案、验收标准和指标。为重大计划保留完整 PRD。

问题：需求过于模糊

解决方案：添加具体示例，使用具体数字，包括视觉参考。将"快速"替换为"在 2 秒内加载"。

问题：利益相关者不一致

解决方案：尽早以草稿形式分享 PRD，纳入反馈，亲自展示，在开发开始前获得明确签字。

问题：范围不断扩大

解决方案：积极使用"范围外"部分，为未来阶段创建单独的 PRD，将范围与时间线约束联系起来。

问题：工程师说不可行

解决方案：更早地让工程参与，对解决方案方法保持灵活，专注于问题而非实现。

最佳实践摘要

1. 从问题开始，而非解决方案
2. 为受众写作（高管需要摘要，工程师需要细节）
3. 具体可衡量（避免模糊语言）
4. 包括视觉元素（模型、图表、流程）
5. 提前定义成功（指标，而非功能）
6. 积极界定范围（MVP 心态）
7. 协作，而非命令（获取所有职能的输入）
8. 保持更新（PRD 是活文档）
9. 专注于"为什么"和"什么"，而非"如何"（让工程师解决"如何"）
10. 使其易于浏览（标题、项目符号、摘要）

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: linlannet
• Source: linlannet/agent-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.