prd-documentation
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChinesePRD Documentation Skill - Professional Product Requirements Writing
PRD文档撰写技能 - 专业产品需求写作指南
This Skill provides expertise in writing comprehensive, clear, and actionable Product Requirements Documents (PRDs) and Feature Specifications.
本技能提供撰写全面、清晰且可落地的产品需求文档（PRD）和功能规格说明书的专业方法。
When to Use This Skill
何时使用本技能
Use this Skill when you need to:
- Write complete PRD documents
- Create feature specifications
- Define technical requirements
- Document acceptance criteria
- Specify non-functional requirements
- Create user stories with details
- Plan product launches
当你需要完成以下工作时，可使用本技能：
- 撰写完整的PRD文档
- 创建功能规格说明书
- 定义技术需求
- 记录验收标准
- 明确非功能性需求
- 撰写详细的用户故事
- 规划产品上线
Core Process
核心流程
Step 1: Gather Requirements
步骤1：收集需求
Essential Inputs:
- Validated business idea (from idea-agent)
- Target users and personas
- Business objectives and success metrics
- Key features and scope
- Technical constraints
- Timeline and resources
If Missing, Ask:
- "What problem does this product solve?"
- "Who are the primary users?"
- "What are the must-have features for MVP?"
- "What are the business goals and KPIs?"
- "What technical constraints exist?"
- "When is the target launch date?"
必要输入信息：
- 已验证的商业创意（来自idea-agent）
- 目标用户及用户画像
- 业务目标与成功指标
- 核心功能及范围
- 技术约束条件
- 时间线与资源情况
若信息缺失，需询问：
- “该产品解决什么问题？”
- “主要用户群体是谁？”
- “MVP必须具备哪些功能？”
- “业务目标和关键绩效指标（KPIs）是什么？”
- “存在哪些技术约束？”
- “目标上线日期是什么时候？”
Step 2: Use Reference Templates
步骤2：参考模板
Always read these templates:
bash
undefined请务必阅读以下模板：
bash
undefinedUse Read tool:
使用Read工具：
/reference/prd-templates/standard-prd-template.md
/reference/prd-templates/feature-spec-template.md
These provide:
- Complete PRD structure (15 sections)
- Feature specification format
- Acceptance criteria templates
- Technical requirements checklist
- Success metrics frameworks/reference/prd-templates/standard-prd-template.md
/reference/prd-templates/feature-spec-template.md
这些模板包含：
- 完整的PRD结构（15个章节）
- 功能规格文档格式
- 验收标准模板
- 技术需求检查清单
- 成功指标框架Step 3: PRD Structure
步骤3：PRD结构
Follow this comprehensive 15-section structure:
遵循以下包含15个章节的完整结构：
1. Document Information
1. 文档信息
markdown
- Product Name: [Name]
- Version: [1.0]
- Author: [Name]
- Last Updated: [Date]
- Status: [Draft | In Review | Approved | In Development]markdown
- 产品名称: [名称]
- 版本: [1.0]
- 作者: [姓名]
- 最后更新日期: [日期]
- 状态: [草稿 | 审核中 | 已批准 | 开发中]2. Executive Summary
2. 执行摘要
Product Overview:
- One-paragraph description
- Core value proposition
Problem Statement:
- What problem we're solving
- Why it matters now
Success Criteria:
- Primary metric and target
- Secondary metrics
产品概述：
- 一段式描述
- 核心价值主张
问题陈述：
- 我们要解决的问题
- 为何现在需要解决该问题
成功标准：
- 主要指标及目标值
- 次要指标
3. Goals and Objectives
3. 目标与目的
Business Goals:
- Revenue impact
- Market position
- Strategic alignment
User Goals:
- User benefits
- Problem solved
- Outcome achieved
Product Objectives (OKRs):
markdown
Objective 1: [Qualitative, inspiring goal]
├─ Key Result 1.1: [Measurable, time-bound]
├─ Key Result 1.2: [Measurable, time-bound]
└─ Key Result 1.3: [Measurable, time-bound]
Objective 2: [Qualitative goal]
├─ Key Result 2.1: [Measurable]
└─ Key Result 2.2: [Measurable]业务目标：
- 收入影响
- 市场定位
- 战略对齐
用户目标：
- 用户收益
- 解决的问题
- 达成的成果
产品目标（OKRs）：
markdown
目标1: [定性、具有激励性的目标]
├─ 关键结果1.1: [可衡量、有时限]
├─ 关键结果1.2: [可衡量、有时限]
└─ 关键结果1.3: [可衡量、有时限]
目标2: [定性目标]
├─ 关键结果2.1: [可衡量]
└─ 关键结果2.2: [可衡量]4. Target Audience
4. 目标受众
Primary Persona:
markdown
undefined核心用户画像：
markdown
undefinedPersona: [Name]
用户画像: [名称]
Demographics:
- Age: [Range]
- Location: [Where]
- Job/Role: [Title]
- Tech Proficiency: [High/Medium/Low]
Goals:
- [Goal 1]
- [Goal 2]
Pain Points:
- [Pain 1]
- [Pain 2]
Current Solutions:
- [What they use today]
Quote:
"[In their own words]"
undefined人口统计信息:
- 年龄: [范围]
- 所在地: [地区]
- 职位/角色: [头衔]
- 技术熟练度: [高/中/低]
目标:
- [目标1]
- [目标2]
痛点:
- [痛点1]
- [痛点2]
当前解决方案:
- [他们目前使用的产品]
用户语录:
"[用户的真实表述]"
undefined5. User Stories and Use Cases
5. 用户故事与用例
Format:
markdown
undefined格式：
markdown
undefinedUser Story: [Title]
用户故事: [标题]
As a [specific user type],
I want to [specific action],
So that [specific benefit].
Acceptance Criteria:
Given [precondition]
When [action]
Then [expected outcome]
And [additional outcome]
Priority: P0 | P1 | P2
Story Points: [1-13]
**Use Case Format:**
```markdown作为[特定用户类型],
我希望[执行特定操作],
以便[获得特定收益]。
验收标准:
给定[前置条件]
当[执行操作]
则[预期结果]
并且[额外结果]
优先级: P0 | P1 | P2
故事点数: [1-13]
**用例格式：**
```markdownUse Case: [Title]
用例: [标题]
Actor: [Who performs this]
Trigger: [What initiates this]
Preconditions: [What must be true]
Main Flow:
- [Step 1]
- [Step 2]
- [Step 3]
Alternative Flows:
- If [condition], then [alternative steps]
Postconditions: [System state after completion]
undefined参与者: [执行该操作的角色]
触发条件: [启动该用例的事件]
前置条件: [必须满足的状态]
主流程:
- [步骤1]
- [步骤2]
- [步骤3]
备选流程:
- 如果[条件], 则[备选步骤]
后置条件: [完成后的系统状态]
undefined6. Features and Requirements
6. 功能与需求
For Each Feature:
markdown
undefined每个功能的撰写格式：
markdown
undefinedFeature: [Name]
功能: [名称]
Description:
[What it is and why it's important]
User Value:
[How it benefits users]
User Story:
As a [user],
I want to [action],
So that [benefit].
Functional Requirements:
- [Requirement 1]
- [Requirement 2]
- [Requirement 3]
Acceptance Criteria:
Given [context]
When [action]
Then [outcome]
Priority: P0 (Must) | P1 (Should) | P2 (Could)
Effort: XS | S | M | L | XL
Dependencies: [Feature IDs or systems]
Technical Notes: [Implementation considerations]
Edge Cases:
- [Edge case 1 and handling]
- [Edge case 2 and handling]
Error Handling:
- [Error scenario 1]: [Error message and action]
- [Error scenario 2]: [Error message and action]
**Non-Functional Requirements:**
```markdown描述:
[功能定义及重要性]
用户价值:
[该功能为用户带来的收益]
用户故事:
作为[用户],
我希望[执行操作],
以便[获得收益]。
功能性需求:
- [需求1]
- [需求2]
- [需求3]
验收标准:
给定[场景]
当[执行操作]
则[结果]
优先级: P0（必须） | P1（应该） | P2（可以）
工作量: XS | S | M | L | XL
依赖项: [功能ID或系统]
技术说明: [实现注意事项]
边缘场景:
- [边缘场景1及处理方式]
- [边缘场景2及处理方式]
错误处理:
**非功能性需求:**
```markdownPerformance
性能
- Page Load Time: < [X] seconds
- API Response Time: < [Y] ms
- Concurrent Users: [Z] minimum
- Data Processing: [Rate/volume]
- 页面加载时间: < [X] 秒
- API响应时间: < [Y] 毫秒
- 并发用户数: 至少[Z]人
- 数据处理能力: [速率/容量]
Security
安全性
- Authentication: [Method]
- Authorization: [RBAC, ABAC]
- Data Encryption: [At rest, in transit]
- Compliance: [GDPR, HIPAA, SOC 2]
- Input Validation: [Rules]
- Rate Limiting: [Limits]
- 认证方式: [方法]
- 授权机制: [RBAC, ABAC]
- 数据加密: [静态加密、传输加密]
- 合规性: [GDPR, HIPAA, SOC 2]
- 输入验证: [规则]
- 请求限制: [限制条件]
Scalability
可扩展性
- Horizontal Scaling: [Yes/No]
- Auto-scaling: [Yes/No]
- Peak Load Capacity: [X users/requests]
- Database Sharding: [If applicable]
- 水平扩展: [是/否]
- 自动扩缩容: [是/否]
- 峰值负载能力: [X个用户/请求]
- 数据库分片: [若适用]
Reliability
可靠性
- Uptime SLA: [99.9%]
- Disaster Recovery: RPO/RTO
- Backup Strategy: [Frequency, retention]
- Monitoring: [Tools, alerts]
- 可用性SLA: [99.9%]
- 灾难恢复: RPO/RTO
- 备份策略: [频率、保留期限]
- 监控: [工具、告警规则]
Accessibility
可访问性
- WCAG Level: [AA | AAA]
- Screen Reader: [Supported]
- Keyboard Navigation: [Full support]
- Color Contrast: [Ratio]
- Focus Indicators: [Visible]
- WCAG级别: [AA | AAA]
- 屏幕阅读器: [支持]
- 键盘导航: [完全支持]
- 颜色对比度: [比例]
- 焦点指示器: [可见]
Browser/Platform Support
浏览器/平台支持
Desktop:
- Chrome: [Latest 2 versions]
- Firefox: [Latest 2 versions]
- Safari: [Latest 2 versions]
- Edge: [Latest 2 versions]
Mobile:
- iOS Safari: [Latest 2 versions]
- Chrome Mobile: [Latest 2 versions]
undefined桌面端:
- Chrome: [最新2个版本]
- Firefox: [最新2个版本]
- Safari: [最新2个版本]
- Edge: [最新2个版本]
移动端:
- iOS Safari: [最新2个版本]
- Chrome Mobile: [最新2个版本]
undefined7. Design and UX
7. 设计与UX
markdown
undefinedmarkdown
undefinedDesign Principles
设计原则
- [Principle 1: e.g., Simplicity first]
- [Principle 2: e.g., Progressive disclosure]
- [Principle 3: e.g., Accessible by default]
- [原则1：例如，简洁优先]
- [原则2：例如，渐进式披露]
- [原则3：例如，默认可访问]
Key Screens
核心页面
Screen 1: [Name]
- Purpose: [What users do here]
- Key Elements: [Components, CTAs]
- User Flow: [Navigation]
页面1: [名称]
- 用途: [用户在此页面的操作]
- 核心元素: [组件、CTA按钮]
- 用户流程: [导航路径]
User Flows
用户流程
Flow: [Name]
- [Entry point]
- [Step 1]
- [Decision point]
- [Step 2]
- [Exit/Success state]
流程: [名称]
- [入口点]
- [步骤1]
- [决策点]
- [步骤2]
- [退出/成功状态]
Design Assets
设计资产
- Wireframes: [Link to Figma/Sketch]
- Mockups: [Link]
- Design System: [Link]
- Style Guide: [Link]
undefined- 线框图: [Figma/Sketch链接]
- 高保真原型: [链接]
- 设计系统: [链接]
- 风格指南: [链接]
undefined8. Technical Specifications
8. 技术规格
markdown
undefinedmarkdown
undefinedSystem Architecture
系统架构
[High-level architecture diagram or description]
Frontend <-> API Gateway <-> Backend Services <-> Database
↓
Third-party APIs[高层架构图或描述]
前端 <-> API网关 <-> 后端服务 <-> 数据库
↓
第三方APITechnology Stack
技术栈
- Frontend: [React, Vue, Angular]
- Backend: [Node.js, Python, Java]
- Database: [PostgreSQL, MongoDB]
- Infrastructure: [AWS, GCP, Azure]
- Cache: [Redis, Memcached]
- 前端: [React, Vue, Angular]
- 后端: [Node.js, Python, Java]
- 数据库: [PostgreSQL, MongoDB]
- 基础设施: [AWS, GCP, Azure]
- 缓存: [Redis, Memcached]
API Requirements
API需求
Endpoint:
POST /api/resourceRequest:
json
{
"field1": "value",
"field2": 123
}Response:
json
{
"success": true,
"data": {
"id": "uuid",
"created_at": "timestamp"
}
}Error Codes:
- 400: Bad Request
- 401: Unauthorized
- 404: Not Found
- 500: Internal Server Error
端点:
POST /api/resource请求:
json
{
"field1": "value",
"field2": 123
}响应:
json
{
"success": true,
"data": {
"id": "uuid",
"created_at": "timestamp"
}
}错误码:
- 400: 错误请求
- 401: 未授权
- 404: 资源不存在
- 500: 服务器内部错误
Data Model
数据模型
Entity: User
{
id: UUID (PK)
email: String (unique, indexed)
name: String
created_at: Timestamp
updated_at: Timestamp
}Relationships:
- User has_many Orders
- Order belongs_to User
实体: 用户
{
id: UUID (主键)
email: String (唯一、已索引)
name: String
created_at: 时间戳
updated_at: 时间戳
}关系:
- 用户拥有多个订单
- 订单属于单个用户
Integrations
集成服务
| Service | Purpose | API | Auth |
|---|---|---|---|
| Stripe | Payments | REST | API Key |
| SendGrid | REST | API Key | |
| AWS S3 | Storage | SDK | IAM |
undefined| 服务 | 用途 | API | 认证方式 |
|---|---|---|---|
| Stripe | 支付 | REST | API密钥 |
| SendGrid | 邮件 | REST | API密钥 |
| AWS S3 | 存储 | SDK | IAM |
undefined9. Analytics and Metrics
9. 分析与指标
markdown
undefinedmarkdown
undefinedKey Performance Indicators
关键绩效指标
Product KPIs:
- Acquisition: [New users/month]
- Activation: [% completing onboarding]
- Engagement: [DAU, session length]
- Retention: [Day 7, Day 30]
- Revenue: [MRR, ARPU]
- Referral: [NPS, viral coefficient]
Success Metrics:
| Metric | Current | Target | Timeline |
|---|---|---|---|
| User Adoption | 0 | 10K users | 3 months |
| Activation Rate | - | 40% | Launch+30d |
| DAU/MAU | - | 25% | Launch+90d |
| NPS | - | 40+ | Launch+90d |
产品KPIs:
- 获取: [每月新增用户数]
- 激活: [完成入门流程的用户占比]
- 参与度: [日活用户数、会话时长]
- 留存: [7日留存、30日留存]
- 收入: [月度经常性收入、每用户平均收入]
- 推荐: [净推荐值、病毒系数]
成功指标:
| 指标 | 当前值 | 目标值 | 时间线 |
|---|---|---|---|
| 用户采用率 | 0 | 10000用户 | 3个月 |
| 激活率 | - | 40% | 上线后30天 |
| 日活/月活 | - | 25% | 上线后90天 |
| 净推荐值 | - | 40+ | 上线后90天 |
Event Tracking Plan
事件追踪计划
| Event Name | Description | Properties | Priority |
|---|---|---|---|
| user_signup | User completes registration | source, plan | P0 |
| feature_used | User activates key feature | feature_name, duration | P0 |
| conversion | User upgrades to paid | plan, amount | P0 |
| error_occurred | System error | error_type, page | P1 |
| 事件名称 | 描述 | 属性 | 优先级 |
|---|---|---|---|
| user_signup | 用户完成注册 | 来源、套餐 | P0 |
| feature_used | 用户使用核心功能 | 功能名称、使用时长 | P0 |
| conversion | 用户升级为付费套餐 | 套餐、金额 | P0 |
| error_occurred | 系统发生错误 | 错误类型、页面 | P1 |
A/B Testing
A/B测试
Test 1: [Onboarding Flow]
- Hypothesis: [Simplified onboarding will increase activation by 20%]
- Variants: Control vs Variant A
- Success Metric: [Onboarding completion rate]
- Sample Size: [10,000 users]
- Duration: [2 weeks]
undefined测试1: [入门流程]
- 假设: [简化入门流程将提升20%的激活率]
- 变体: 对照组 vs 变体A
- 成功指标: [入门流程完成率]
- 样本量: [10000用户]
- 时长: [2周]
undefined10. Risks and Mitigations
10. 风险与缓解措施
markdown
| Risk | Probability | Impact | Mitigation Strategy |
|------|-------------|--------|---------------------|
| Technical complexity | Medium | High | Prototype early, allocate buffer time |
| Low user adoption | Low | High | Beta test, user research, iterative launch |
| Third-party dependency | Medium | Medium | Alternative vendor, fallback plan |
| Competitive response | High | Medium | Focus on differentiation, speed to market |
| Scope creep | High | Medium | Strict prioritization, clear MVP definition |markdown
| 风险 | 概率 | 影响 | 缓解策略 |
|------|-------------|--------|---------------------|
| 技术复杂度 | 中等 | 高 | 提前制作原型，预留缓冲时间 |
| 用户采用率低 | 低 | 高 | 进行Beta测试、用户研究、迭代式上线 |
| 第三方依赖问题 | 中等 | 中等 | 备选供应商、 fallback方案 |
| 竞品响应 | 高 | 中等 | 聚焦差异化，加快上市速度 |
| 范围蔓延 | 高 | 中等 | 严格优先级排序，明确MVP定义 |11. Timeline and Milestones
11. 时间线与里程碑
markdown
undefinedmarkdown
undefinedProject Phases
项目阶段
Phase 1: Planning (Weeks 1-2)
- PRD Approval
- Design Review
- Technical Spec Complete
Phase 2: Development (Weeks 3-8)
- Sprint 1 (Weeks 3-4): Core features
- Sprint 2 (Weeks 5-6): Integration
- Sprint 3 (Weeks 7-8): Polish and bug fixes
Phase 3: Testing (Weeks 9-10)
- QA Testing
- User Acceptance Testing
- Performance Testing
- Security Audit
Phase 4: Launch (Week 11)
- Soft Launch (10% rollout)
- Monitor metrics
- Full Launch (100% rollout)
阶段1: 规划（第1-2周）
- PRD批准
- 设计评审
- 技术规格完成
阶段2: 开发（第3-8周）
- 冲刺1（第3-4周）: 核心功能
- 冲刺2（第5-6周）: 集成开发
- 冲刺3（第7-8周）: 优化与Bug修复
阶段3: 测试（第9-10周）
- QA测试
- 用户验收测试
- 性能测试
- 安全审计
阶段4: 上线（第11周）
- 灰度发布（10%用户覆盖）
- 指标监控
- 全量发布（100%用户覆盖）
Dependencies
依赖项
| Dependency | Owner | Status | Due Date | Blocker? |
|---|---|---|---|---|
| [API from Team B] | [Name] | In Progress | [Date] | Yes |
| [Design System Update] | [Name] | Not Started | [Date] | No |
undefined| 依赖项 | 负责人 | 状态 | 截止日期 | 是否阻塞 |
|---|---|---|---|---|
| [团队B提供的API] | [姓名] | 进行中 | [日期] | 是 |
| [设计系统更新] | [姓名] | 未开始 | [日期] | 否 |
undefined12. Open Questions and Assumptions
12. 待解决问题与假设
markdown
undefinedmarkdown
undefinedOpen Questions
待解决问题
-
[Question about feature X]
- Decision needed by: [Date]
- Owner: [Name]
- Options: A, B, C
- Recommendation: [Option A because...]
-
[Question about technical approach]
- Decision needed by: [Date]
- Owner: [Name]
-
[关于功能X的问题]
- 需在[日期]前决策
- 负责人: [姓名]
- 选项: A, B, C
- 推荐方案: [选项A，因为...]
-
[关于技术方案的问题]
- 需在[日期]前决策
- 负责人: [姓名]
Assumptions
假设
- Users have stable internet connection
- 80% of traffic from mobile devices
- Third-party API has 99.9% uptime
- Users familiar with similar products
- 用户拥有稳定的网络连接
- 80%的流量来自移动端
- 第三方API的可用性为99.9%
- 用户熟悉同类产品
Out of Scope (Explicitly NOT Included)
范围外内容（明确不包含）
- [Feature X] - Planned for v2.0
- [Platform Y support] - Not in roadmap
- [Integration Z] - Deprioritized
undefined- [功能X] - 计划在v2.0版本中实现
- [平台Y支持] - 不在路线图中
- [集成Z] - 优先级降低
undefined13-15. Supporting Sections
13-15. 支持性章节
markdown
undefinedmarkdown
undefinedResources and Team
资源与团队
Core Team:
- Product Manager: [Name]
- Engineering Lead: [Name]
- Design Lead: [Name]
- QA Lead: [Name]
Extended Team:
- Engineers: [X people]
- Designers: [Y people]
- QA: [Z people]
核心团队:
- 产品经理: [姓名]
- 技术负责人: [姓名]
- 设计负责人: [姓名]
- QA负责人: [姓名]
扩展团队:
- 工程师: [X人]
- 设计师: [Y人]
- QA: [Z人]
Launch Plan
上线计划
Pre-Launch:
- Beta program (100 users, 2 weeks)
- Marketing materials
- Support documentation
- Team training
Launch:
- Announcement (blog, email, social)
- Press release
- Customer outreach
Post-Launch:
- Monitor metrics daily
- User feedback collection
- Iteration plan
上线前:
- Beta测试（100名用户，持续2周）
- 营销物料准备
- 支持文档准备
- 团队培训
上线时:
- 公告（博客、邮件、社交媒体）
- 新闻稿
- 客户触达
上线后:
- 每日指标监控
- 用户反馈收集
- 迭代计划制定
Change Log
变更日志
| Date | Version | Changes | Author |
|---|---|---|---|
| 2024-01-15 | 1.0 | Initial draft | PM Name |
| 2024-01-20 | 1.1 | Added technical specs | PM Name |
| 2024-01-25 | 2.0 | Final for review | PM Name |
undefined| 日期 | 版本 | 变更内容 | 作者 |
|---|---|---|---|
| 2024-01-15 | 1.0 | 初始草稿 | PM姓名 |
| 2024-01-20 | 1.1 | 添加技术规格 | PM姓名 |
| 2024-01-25 | 2.0 | 最终审核版本 | PM姓名 |
undefinedBest Practices
最佳实践
Writing Style
写作风格
✅ Do:
- Use clear, unambiguous language
- Be specific and measurable
- Include examples
- Use tables and bullets
- Write from user perspective
- Define acronyms on first use
❌ Don't:
- Use vague terms ("user-friendly", "fast")
- Mix implementation with requirements
- Skip edge cases and errors
- Write lengthy paragraphs
- Assume technical knowledge
✅ 建议：
- 使用清晰、无歧义的语言
- 内容具体且可衡量
- 包含示例
- 使用表格和项目符号
- 从用户视角撰写
- 首次出现的缩写需定义
❌ 避免：
- 使用模糊术语（如“用户友好”、“快速”）
- 将实现细节与需求混淆
- 忽略边缘场景和错误处理
- 冗长的段落
- 假设读者具备技术知识
Acceptance Criteria
验收标准
✅ Do:
- Use Given-When-Then format
- Cover happy path, errors, edge cases
- Make testable and measurable
- Include visual feedback requirements
- Specify error messages
❌ Don't:
- Write vague criteria ("works well")
- Focus only on happy path
- Skip error handling
- Forget accessibility
- Leave untestable criteria
✅ 建议：
- 使用Given-When-Then格式
- 覆盖正常流程、错误场景和边缘情况
- 可测试、可衡量
- 包含视觉反馈要求
- 明确错误提示信息
❌ 避免：
- 模糊的标准（如“运行良好”）
- 仅关注正常流程
- 忽略错误处理
- 忘记可访问性要求
- 留下无法测试的标准
Prioritization
优先级排序
Use MoSCoW:
- P0 (Must Have): Blocking for launch
- P1 (Should Have): Important, not blocking
- P2 (Could Have): Nice to have
- P3 (Won't Have): Out of scope
使用MoSCoW方法：
- P0（必须具备）: 上线的阻塞项
- P1（应该具备）: 重要但不阻塞上线
- P2（可以具备）: 锦上添花的功能
- P3（不会具备）: 范围外内容
Review Checklist
审核清单
Before finalizing PRD:
- All sections complete
- User stories have acceptance criteria
- Success metrics defined and measurable
- Technical requirements clear
- Dependencies identified
- Risks assessed with mitigations
- Timeline realistic
- Open questions documented
- Reviewed by engineering
- Reviewed by design
- Reviewed by QA
- Approved by stakeholders
在最终确定PRD前：
- 所有章节完整
- 用户故事包含验收标准
- 成功指标已定义且可衡量
- 技术需求清晰
- 依赖项已识别
- 风险已评估并制定缓解措施
- 时间线合理
- 待解决问题已记录
- 已通过技术团队评审
- 已通过设计团队评审
- 已通过QA团队评审
- 已通过利益相关方批准
Output Format
输出格式
File Naming:
[product-name]-prd-v[version].md
Example: ai-study-planner-prd-v1.0.mdLocation:
/docs/prd/[filename]Format:
- Markdown with proper headings (##, ###)
- Tables for comparisons and data
- Code blocks for technical specs
- Checkboxes for action items
- Links to external resources
文件命名规则：
[产品名称]-prd-v[版本号].md
示例: ai-study-planner-prd-v1.0.md存储位置：
/docs/prd/[文件名]格式要求：
- 使用Markdown格式，正确使用标题层级（##, ###）
- 使用表格进行对比和数据展示
- 使用代码块展示技术规格
- 使用复选框标记行动项
- 包含外部资源链接
Example Output
输出示例
See for complete example.
/reference/prd-templates/standard-prd-template.md完整示例请查看 。
/reference/prd-templates/standard-prd-template.mdIntegration Points
集成点
This Skill works with:
- prd-agent: Primary user of this skill
- idea-generation: Takes validated idea as input
- userstory-documentation: Provides requirements for story breakdown
- pm-knowledge-base: Uses OKR, metrics, prioritization frameworks
Always use reference templates as foundation, customizing for specific product needs.
本技能可与以下组件配合使用：
- prd-agent: 本技能的主要使用者
- idea-generation: 接收已验证的创意作为输入
- userstory-documentation: 为故事拆分提供需求
- pm-knowledge-base: 使用OKR、指标、优先级排序框架
请始终以参考模板为基础，根据特定产品需求进行定制化调整。