prd-generator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PRD Generator

PRD生成器

Overview

概述

Generate comprehensive, well-structured Product Requirements Documents (PRDs) that follow industry best practices. This skill helps product managers create clear, actionable requirements documents that align stakeholders and guide development teams.

生成符合行业最佳实践的全面、结构清晰的产品需求文档（PRD）。此技能帮助产品经理创建清晰、可执行的需求文档，使相关方保持一致并指导开发团队。

Core Workflow

核心工作流

When a user requests to create a PRD (e.g., "create a PRD for a user authentication feature"), follow this workflow:

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

Step 1: Gather Context

步骤1：收集上下文信息

Before generating the PRD, collect essential information through a discovery conversation:

Required Information:

Feature/Product Name: What are we building?
Problem Statement: What problem does this solve?
Target Users: Who is this for?
Business Goals: What are we trying to achieve?
Success Metrics: How will we measure success?
Timeline/Constraints: Any deadlines or limitations?

Discovery Questions to Ask:

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?

Note: If the user provides a detailed brief or requirements upfront, you can skip some questions. Always ask for clarification on missing critical information.

在生成PRD之前，通过探索性对话收集关键信息：

必填信息：

功能/产品名称：我们要构建什么？
问题陈述：这能解决什么问题？
目标用户：这是为谁打造的？
业务目标：我们想要达成什么？
成功指标：我们如何衡量成功？
时间线/约束条件：有任何截止日期或限制吗？

可询问的探索性问题：

1. 你试图解决什么问题？
2. 此功能的主要用户/受众是谁？
3. 关键业务目标是什么？
4. 我们需要注意哪些技术约束？
5. 成功的标准是什么？你将如何衡量？
6. 此功能的时间线是什么？
7. 明确排除在范围外的内容是什么？

注意： 如果用户预先提供了详细的简介或需求，你可以跳过部分问题。对于缺失的关键信息，务必请求澄清。

Step 2: Generate PRD Structure

步骤2：生成PRD结构

Use the standard PRD template from

references/prd_template.md

to create a well-structured document. The PRD should include:

Executive Summary - High-level overview (2-3 paragraphs)
Problem Statement - Clear articulation of the problem
Goals & Objectives - What we're trying to achieve
User Personas - Who we're building for
User Stories & Requirements - Detailed functional requirements
Success Metrics - KPIs and measurement criteria
Scope - What's in and out of scope
Technical Considerations - Architecture, dependencies, constraints
Design & UX Requirements - UI/UX considerations
Timeline & Milestones - Key dates and phases
Risks & Mitigation - Potential issues and solutions
Dependencies & Assumptions - What we're relying on
Open Questions - Unresolved items

使用

references/prd_template.md

中的标准PRD模板创建结构清晰的文档。PRD应包含：

执行摘要 - 高层概述（2-3段）
问题陈述 - 清晰阐述问题
目标与目的 - 我们想要达成的内容
用户画像 - 我们的目标用户群体
用户故事与需求 - 详细的功能需求
成功指标 - KPI和衡量标准
范围 - 包含与排除的内容
技术考量 - 架构、依赖项、约束条件
设计与UX需求 - UI/UX相关考量
时间线与里程碑 - 关键日期和阶段
风险与缓解措施 - 潜在问题及解决方案
依赖项与假设 - 我们依赖的前提条件
待解决问题 - 未明确的事项

Step 3: Create User Stories

步骤3：创建用户故事

For each major requirement, generate user stories using the standard format:

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]

Reference

references/user_story_examples.md

for common patterns and best practices.

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

作为[用户类型]，
我想要[执行操作]，
以便[获得收益/价值]。

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

参考

references/user_story_examples.md

获取常见模式和最佳实践。

Step 4: Define Success Metrics

步骤4：定义成功指标

Use appropriate metrics frameworks based on the product type:

AARRR (Pirate Metrics): Acquisition, Activation, Retention, Revenue, Referral
HEART Framework: Happiness, Engagement, Adoption, Retention, Task Success
North Star Metric: Single key metric that represents core value
OKRs: Objectives and Key Results

Consult

references/metrics_frameworks.md

for detailed guidance on each framework.

根据产品类型选择合适的指标框架：

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

查阅

references/metrics_frameworks.md

获取每个框架的详细指导。

Step 5: Validate & Review

步骤5：验证与审核

Optionally run the validation script to ensure PRD completeness:

bash

scripts/validate_prd.sh <prd_file.md>

This checks for:

All required sections present
User stories follow proper format
Success metrics are defined
Scope is clearly articulated
No placeholder text remains

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

bash

scripts/validate_prd.sh <prd_file.md>

此脚本检查：

所有必填章节是否存在
用户故事是否遵循正确格式
成功指标是否已定义
范围是否清晰阐述
无占位文本残留

Usage Patterns

使用模式

Pattern 1: New Feature PRD

模式1：新功能PRD

User Request: "Create a PRD for adding dark mode to our mobile app"

Execution:

Ask discovery questions about dark mode requirements
Generate PRD using template
Create user stories for:
- Theme switching
- Preference persistence
- System-level sync
- Design token updates
Define success metrics (adoption rate, user satisfaction)
Identify technical dependencies (design system, platform APIs)

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

执行流程：

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

Pattern 2: Product Enhancement PRD

模式2：产品增强PRD

User Request: "Write requirements for improving our search functionality"

Execution:

Gather context on current search limitations
Identify user pain points and desired improvements
Generate PRD with focus on:
- Current state analysis
- Proposed enhancements
- Impact assessment
Create prioritized user stories
Define before/after metrics

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

执行流程：

收集当前搜索功能局限性的上下文信息
识别用户痛点和期望的改进点
生成PRD，重点关注：
- 当前状态分析
- 拟议的增强功能
- 影响评估
创建优先级排序的用户故事
定义改进前后的指标

Pattern 3: New Product PRD

模式3：新产品PRD

User Request: "I need a PRD for a new analytics dashboard product"

Execution:

Comprehensive discovery (market analysis, user research)
Generate full PRD with:
- Market opportunity
- Competitive analysis
- Product vision
- MVP scope
- Go-to-market considerations
Detailed user stories for core features
Phased rollout plan
Success metrics aligned with business goals

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

执行流程：

全面探索（市场分析、用户研究）
生成完整PRD，包含：
- 市场机会
- 竞争分析
- 产品愿景
- MVP范围
- 上市考量
核心功能的详细用户故事
分阶段推出计划
与业务目标对齐的成功指标

Pattern 4: Quick PRD / One-Pager

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

User Request: "Create a lightweight PRD for a small bug fix feature"

Execution:

Generate simplified PRD focusing on:
- Problem statement
- Solution approach
- Acceptance criteria
- Success metrics
Skip sections not relevant for small scope
Keep document concise (1-2 pages)

用户请求：“为一个小型bug修复功能创建轻量级PRD”

执行流程：

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

PRD Best Practices

PRD最佳实践

Writing Quality Requirements

撰写高质量需求

Good Requirements Are:

Specific: Clear and unambiguous
Measurable: Can be verified/tested
Achievable: Technically feasible
Relevant: Tied to user/business value
Time-bound: Has clear timeline

Avoid:

Vague language ("fast", "easy", "intuitive")
Implementation details (let engineers decide how)
Feature creep (stick to core requirements)
Assumptions without validation

优质需求具备：

具体性：清晰且无歧义
可衡量性：可验证/测试
可实现性：技术上可行
相关性：与用户/业务价值挂钩
时效性：有明确的时间线

需避免：

模糊语言（“快速”、“简单”、“直观”）
实现细节（让工程师决定如何实现）
功能蔓延（坚守核心需求）
未经验证的假设

User Story Best Practices

用户故事最佳实践

DO:

Focus on user value, not features
Write from user perspective
Include clear acceptance criteria
Keep stories independent and small
Use consistent format

DON'T:

Write technical implementation details
Create dependencies between stories
Make stories too large (epics)
Use internal jargon
Skip acceptance criteria

应该：

聚焦用户价值，而非功能
从用户视角撰写
包含清晰的验收标准
保持故事独立且体量小
使用一致的格式

不应该：

撰写技术实现细节
在故事之间创建依赖关系
让故事体量过大（史诗级故事）
使用内部行话
跳过验收标准

Scope Management

范围管理

In-Scope Section:

List specific features/capabilities included
Be explicit and detailed
Link to user stories

Out-of-Scope Section:

Explicitly state what's NOT included
Prevents scope creep
Manages stakeholder expectations
Can include "future considerations"

包含范围章节：

列出包含的具体功能/能力
表述明确且详细
关联到用户故事

排除范围章节：

明确说明不包含的内容
防止功能蔓延
管理相关方期望
可包含“未来考量”内容

Success Metrics Guidelines

成功指标指南

Choose Metrics That:

Align with business objectives
Are measurable and trackable
Have clear targets/thresholds
Include both leading and lagging indicators
Consider user and business value

Typical Metric Categories:

Adoption: How many users use the feature?
Engagement: How often do they use it?
Satisfaction: Do users like it?
Performance: Does it work well?
Business Impact: Does it drive business goals?

选择符合以下条件的指标：

与业务目标对齐
可衡量和跟踪
有明确的目标/阈值
包含领先指标和滞后指标
兼顾用户价值和业务价值

典型指标类别：

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

Advanced Features

高级功能

PRD Templates for Different Contexts

不同场景的PRD模板

The skill supports different PRD formats:

Standard PRD - Full comprehensive document Lean PRD - Streamlined for agile teams One-Pager - Executive summary format Technical PRD - Engineering-focused requirements Design PRD - UX/UI-focused requirements

Specify the format when requesting: "Create a lean PRD for..." or "Generate a technical PRD for..."

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

标准PRD - 全面的完整文档 精益PRD - 为敏捷团队简化的版本 单页文档 - 执行摘要格式 技术PRD - 以工程为重点的需求 设计PRD - 以UX/UI为重点的需求

请求时指定格式：“为...创建精益PRD”或“为...生成技术PRD”

Integration with Design

与设计的集成

Design Requirements Section Should Include:

Visual design requirements
Interaction patterns
Accessibility requirements (WCAG compliance)
Responsive design considerations
Design system components to use
User flow diagrams
Wireframe/mockup references

设计需求章节应包含：

视觉设计要求
交互模式
可访问性要求（WCAG合规）
响应式设计考量
要使用的设计系统组件
用户流程图
线框/原型参考

Technical Considerations Section

技术考量章节

Should Address:

Architecture: High-level technical approach
Dependencies: External services, libraries, APIs
Security: Authentication, authorization, data protection
Performance: Load times, scalability requirements
Compatibility: Browser, device, platform support
Data: Storage, migration, privacy considerations
Integration: How it fits with existing systems

应解决：

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

Stakeholder Alignment

Common PRD Scenarios

常见PRD场景

Scenario 1: Feature Request from Customer

场景1：客户提出的功能请求

When creating a PRD based on customer feedback:

Document the customer request verbatim
Analyze the underlying problem
Generalize the solution for all users
Validate with product strategy
Scope appropriately (might be smaller or larger than request)

基于客户反馈创建PRD时：

如实记录客户请求
分析潜在问题
为所有用户推广解决方案
与产品战略对齐验证
合理划定范围（可能比请求的更小或更大）

Scenario 2: Strategic Initiative

场景2：战略举措

When creating a PRD for a strategic company initiative:

Link to company OKRs/goals
Include market analysis
Consider competitive landscape
Think multi-phase rollout
Include success criteria aligned with strategy

为公司战略举措创建PRD时：

关联到公司OKRs/目标
包含市场分析
考虑竞争格局
规划多阶段推出
包含与战略对齐的成功标准

Scenario 3: Technical Debt / Infrastructure

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

When creating a PRD for technical improvements:

Explain user impact (even if indirect)
Document current limitations
Articulate benefits (speed, reliability, maintainability)
Include engineering input heavily
Define measurable improvements

为技术改进创建PRD时：

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

Scenario 4: Compliance / Regulatory

场景4：合规/监管要求

When creating a PRD for compliance requirements:

Reference specific regulations (GDPR, HIPAA, etc.)
Include legal/compliance review
Deadline is usually non-negotiable
Focus on minimum viable compliance
Document audit trail requirements

为合规要求创建PRD时：

参考具体法规（GDPR、HIPAA等）
包含法律/合规审核
截止日期通常不可协商
聚焦最低可行合规要求
记录审计跟踪要求

Validation & Quality Checks

验证与质量检查

Self-Review Checklist

自我审核清单

Using the Validation Script

使用验证脚本

bash

undefined

bash

undefined

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"

undefined

scripts/validate_prd.sh my_prd.md --sections "user-stories,metrics"

undefined

Resources

资源

This skill includes bundled resources:

此技能包含捆绑资源：

scripts/

generate_prd.sh - Interactive PRD generation workflow
validate_prd.sh - Validates PRD completeness and quality

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

references/

prd_template.md - Standard PRD template structure
user_story_examples.md - User story patterns and examples
metrics_frameworks.md - Guide to PM metrics (AARRR, HEART, OKRs)

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

Tips for Product Managers

给产品经理的提示

Before Writing the PRD

撰写PRD之前

Do your research: User interviews, data analysis, competitive analysis
Validate the problem: Ensure it's worth solving
Check strategic alignment: Does this fit our roadmap?
Estimate effort: Rough t-shirt size with engineering
Consider alternatives: Is this the best solution?

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

During PRD Creation

撰写PRD期间

Be clear, not clever: Simple language wins
Show, don't tell: Use examples, mockups, diagrams
Think edge cases: What could go wrong?
Prioritize ruthlessly: What's MVP vs. nice-to-have?
Collaborate early: Don't work in isolation

清晰明了，而非炫技：简单的语言更有效
展示，而非讲述：使用示例、原型、图表
考虑边缘情况：可能会出现什么问题？
无情地排序优先级：什么是MVP vs 锦上添花的功能？
尽早协作：不要孤立工作

After PRD Completion

PRD完成后

Review with stakeholders: Get feedback early
Iterate based on input: PRDs are living documents
Present, don't just share: Walk through the PRD
Get formal sign-off: Ensure commitment
Keep it updated: Adjust as understanding evolves

与相关方审核：尽早获取反馈
根据输入迭代：PRD是活文档
进行演示，而非仅分享：逐步讲解PRD
获得正式签署：确保各方承诺
保持更新：随着认知的演变进行调整

Examples

示例

Example 1: Mobile Feature PRD

示例1：移动功能PRD

bash

undefined

bash

undefined

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

用户：“为我们的iOS应用添加生物识别认证创建PRD”

Assistant will:

助手将：

1. Ask discovery questions about security requirements, user personas, existing auth

1. 询问关于安全要求、用户画像、现有认证方式的探索性问题

2. Generate PRD covering:

2. 生成包含以下内容的PRD：

- Problem: Password friction, security concerns

- 问题：密码繁琐、安全顾虑

- Solution: Face ID / Touch ID integration

- 解决方案：Face ID / Touch ID集成

- User stories: Enable biometric, fallback to password, settings management

- 用户故事：启用生物识别、回退到密码、设置管理

- Metrics: Adoption rate, login success rate, support tickets

- 指标：采用率、登录成功率、支持工单数量

- Technical: iOS Keychain, LocalAuthentication framework

- 技术：iOS Keychain、LocalAuthentication框架

- Risks: Device compatibility, user privacy concerns

- 风险：设备兼容性、用户隐私顾虑

3. Output formatted markdown PRD

3. 输出格式化的markdown PRD

undefined

undefined

Example 2: Web Platform Enhancement

示例2：Web平台增强PRD

bash

undefined

bash

undefined

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

用户：“撰写改进我们结账流程转化率的需求”

Assistant will:

助手将：

1. Gather data on current conversion rates and drop-off points

1. 收集当前转化率和流失点的数据

2. Generate PRD including:

2. 生成包含以下内容的PRD：

- Current state analysis with metrics

- 带指标的当前状态分析

- Proposed improvements (guest checkout, saved payment, progress indicator)

- 拟议的改进（访客结账、保存支付方式、进度指示器）

- A/B test plan

- A/B测试计划

- Success metrics: Conversion rate increase, time to checkout

- 成功指标：转化率提升、结账时间缩短

- User stories for each improvement

- 每个改进的用户故事

3. Include phased rollout approach

3. 包含分阶段推出方案

undefined

undefined

Example 3: B2B Product PRD

示例3：B2B产品PRD

bash

undefined

bash

undefined

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

用户：“我需要一份面向企业客户的管理仪表板PRD”

Assistant will:

助手将：

1. Identify B2B-specific requirements (multi-tenancy, permissions, reporting)

1. 识别B2B特定需求（多租户、权限、报告）

2. Generate comprehensive PRD with:

2. 生成全面的PRD，包含：

- Enterprise user personas (admin, manager, analyst)

- 企业用户画像（管理员、经理、分析师）

- Role-based access control requirements

- 基于角色的访问控制需求

- Reporting and analytics needs

- 报告和分析需求

- Integration requirements (SSO, SCIM)

- 集成需求（SSO、SCIM）

- Success metrics: Customer adoption, admin efficiency

- 成功指标：客户采用率、管理员效率

3. Include enterprise-specific considerations (compliance, SLAs)

3. 包含企业特定考量（合规、SLA）

undefined

undefined

Troubleshooting

故障排除

Issue: PRD is too long/detailed

Solution: Create a "Lean PRD" focusing on problem, solution, acceptance criteria, and metrics. Reserve full PRD for major initiatives.

Issue: Requirements are too vague

Solution: Add specific examples, use concrete numbers, include visual references. Replace "fast" with "loads in under 2 seconds."

Issue: Stakeholders not aligned

Solution: Share PRD early as draft, incorporate feedback, present in person, get explicit sign-off before development starts.

Issue: Scope keeps expanding

Solution: Use "Out of Scope" section aggressively, create separate PRDs for future phases, tie scope to timeline constraints.

Issue: Engineers say it's not feasible

Solution: Involve engineering earlier in process, be flexible on solution approach, focus on problem not implementation.

问题：PRD太长/太详细

解决方案：创建“精益PRD”，聚焦问题、解决方案、验收标准和指标。仅为重大举措保留完整PRD。

问题：需求太模糊

解决方案：添加具体示例、使用具体数字、包含视觉参考。将“快速”替换为“加载时间少于2秒”。

问题：相关方未对齐

解决方案：尽早分享PRD草稿，整合反馈，当面演示，在开发开始前获得明确签署。

问题：范围不断扩大

解决方案：积极使用“排除范围”章节，为未来阶段创建单独的PRD，将范围与时间线约束挂钩。

问题：工程师说不可行

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

Best Practices Summary

最佳实践总结

Start with the problem, not the solution
Write for your audience (execs need summary, engineers need details)
Be specific and measurable (avoid vague language)
Include visuals (mockups, diagrams, flows)
Define success upfront (metrics, not features)
Scope aggressively (MVP mentality)
Collaborate, don't dictate (get input from all functions)
Keep it updated (PRD is a living document)
Focus on "why" and "what", not "how" (let engineers solve "how")
Make it skimmable (headers, bullets, summaries)

从问题开始，而非解决方案
为受众撰写（高管需要摘要，工程师需要细节）
具体且可衡量（避免模糊语言）
包含视觉内容（原型、图表、流程）
提前定义成功（指标，而非功能）
严格划定范围（MVP思维）
协作，而非指令（获取所有职能的输入）
保持更新（PRD是活文档）
聚焦“为什么”和“是什么”，而非“如何做”（让工程师解决“如何做”的问题）
使其易于浏览（标题、项目符号、摘要）

prd-generator

Original

Translation

PRD Generator

PRD生成器

Overview

概述

Core Workflow

核心工作流

Step 1: Gather Context

步骤1：收集上下文信息

Step 2: Generate PRD Structure

步骤2：生成PRD结构

Step 3: Create User Stories

步骤3：创建用户故事

Step 4: Define Success Metrics

步骤4：定义成功指标

Step 5: Validate & Review

步骤5：验证与审核

Usage Patterns

使用模式

Pattern 1: New Feature PRD

模式1：新功能PRD

Pattern 2: Product Enhancement PRD

模式2：产品增强PRD

Pattern 3: New Product PRD

模式3：新产品PRD

Pattern 4: Quick PRD / One-Pager

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

PRD Best Practices

PRD最佳实践

Writing Quality Requirements

撰写高质量需求

User Story Best Practices

用户故事最佳实践

Scope Management

范围管理

Success Metrics Guidelines

成功指标指南

Advanced Features

高级功能

PRD Templates for Different Contexts

不同场景的PRD模板

Integration with Design

与设计的集成

Technical Considerations Section

技术考量章节

Stakeholder Alignment

相关方对齐

Common PRD Scenarios

常见PRD场景

Scenario 1: Feature Request from Customer

场景1：客户提出的功能请求

Scenario 2: Strategic Initiative

场景2：战略举措

Scenario 3: Technical Debt / Infrastructure

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

Scenario 4: Compliance / Regulatory

场景4：合规/监管要求

Validation & Quality Checks

验证与质量检查

Self-Review Checklist

自我审核清单

Using the Validation Script

使用验证脚本

Basic validation

基础验证

Verbose output with suggestions

带建议的详细输出

Check specific sections only

仅检查特定章节

Resources

资源

scripts/

scripts/

references/

references/

Tips for Product Managers

给产品经理的提示

Before Writing the PRD