prp-writer
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChinesePRP Generator (Product Requirements Prompt)
PRP生成器(Product Requirements Prompt)
Overview
概述
The PRP Generator helps you create comprehensive Product Requirements Prompts - structured documents that capture everything needed to build a product feature or system. PRPs are optimized for AI-assisted development, providing clear requirements that both humans and AI can understand.
Core Purpose: Transform vague ideas into actionable, complete requirements.
PRP生成器可帮助您创建全面的产品需求提示词——结构化文档,涵盖构建产品功能或系统所需的全部信息。PRP针对AI辅助开发进行优化,提供人类和AI都能理解的清晰需求。
核心目标: 将模糊的想法转化为可执行的完整需求。
When to Use This Skill
何时使用该工具
Use PRP Generator when:
- Starting a new product or major feature
- Requirements are unclear or scattered
- Need to communicate requirements to development team
- Using AI assistants for implementation
- Transitioning from discovery to development
- Onboarding new team members to a project
在以下场景使用PRP生成器:
- 启动新产品或重大功能
- 需求不明确或分散
- 需要向开发团队传达需求
- 使用AI助手进行开发实现
- 从探索阶段过渡到开发阶段
- 让新团队成员快速熟悉项目
Key Capabilities
核心功能
- Structure requirements into 12 standardized sections
- Identify project complexity pattern (A, B, C)
- Extract user stories in Jobs-to-be-Done format
- Define success criteria and metrics
- Document functional and non-functional requirements
- Capture constraints, risks, and assumptions
- Clarify what's in and out of scope
- 将需求结构化分为12个标准化板块
- 识别项目复杂度模式(A、B、C)
- 以Jobs-to-be-Done格式提取用户故事
- 定义成功标准和指标
- 记录功能性和非功能性需求
- 捕获约束条件、风险和假设
- 明确界定需求范围的包含与排除项
Workflow
工作流程
The 12-Section PRP Structure
12板块PRP结构
A complete PRP contains these 12 sections:
- Project Overview
- Problem Statement
- Success Criteria
- User Stories (Jobs-to-be-Done)
- Functional Requirements
- Non-Functional Requirements
- Technical Constraints
- Data Requirements
- UI/UX Requirements
- Risks & Assumptions
- Out of Scope
- Open Questions
Let's dive into each:
一份完整的PRP包含以下12个板块:
- 项目概述
- 问题陈述
- 成功标准
- 用户故事(Jobs-to-be-Done)
- 功能性需求
- 非功能性需求
- 技术约束
- 数据需求
- UI/UX需求
- 风险与假设
- 范围外内容
- 待解决问题
接下来深入介绍每个板块:
1. Project Overview
1. 项目概述
Purpose: High-level context and pattern classification
What to Include:
- Project name and one-sentence description
- Pattern classification (A, B, or C)
- Timeline estimate
- Target users
- Business context
Example:
Project: Domain Workflow Assistant
Pattern: C (AI-Native System)
Timeline: 10-12 weeks
Users: Primary operators + end users
Context: Reduce repetitive manual work by 40% while maintaining task quality目标: 提供高层级背景信息和模式分类
需包含内容:
- 项目名称和一句话描述
- 模式分类(A、B或C)
- 时间预估
- 目标用户
- 业务背景
示例:
Project: Domain Workflow Assistant
Pattern: C (AI-Native System)
Timeline: 10-12 weeks
Users: Primary operators + end users
Context: Reduce repetitive manual work by 40% while maintaining task quality2. Problem Statement
2. 问题陈述
Purpose: Clearly define the problem being solved
Template:
[User type] faces [problem] when [situation].
This causes [negative outcome].
We know this because [evidence].Example:
Primary operators face long response times when end users request recurring workflow help. This causes user dissatisfaction and operator burnout handling repetitive inquiries.
We know this because:
- 60% of requests are recurring "How do I..." questions
- Average response time is 4 hours
- Operator surveys show 70% of time spent on repetitive questions
- NPS dropped from 45 to 38 in past 6 months目标: 清晰定义要解决的问题
模板:
[用户类型]在[场景]下遇到[问题]。
这会导致[负面结果]。
我们得知这一点是因为[证据]。示例:
Primary operators face long response times when end users request recurring workflow help. This causes user dissatisfaction and operator burnout handling repetitive inquiries.
We know this because:
- 60% of requests are recurring "How do I..." questions
- Average response time is 4 hours
- Operator surveys show 70% of time spent on repetitive questions
- NPS dropped from 45 to 38 in past 6 months3. Success Criteria
3. 成功标准
Purpose: Define measurable outcomes
Structure:
- Primary metric (North Star)
- Secondary metrics
- Minimum success thresholds
Example:
Primary Metric:
- Reduce support ticket volume by 40% within 3 months of launch
Secondary Metrics:
- 80% of common questions answered by AI without escalation
- <2 second response time for AI answers
- >4.0/5.0 user satisfaction rating with AI responses
- 50% reduction in agent time spent on common questions
Minimum Success:
- 30% ticket reduction + 4.0/5.0 satisfaction目标: 定义可衡量的成果
结构:
- 核心指标(北极星指标)
- 次要指标
- 最低成功阈值
示例:
Primary Metric:
- Reduce support ticket volume by 40% within 3 months of launch
Secondary Metrics:
- 80% of common questions answered by AI without escalation
- <2 second response time for AI answers
- >4.0/5.0 user satisfaction rating with AI responses
- 50% reduction in agent time spent on common questions
Minimum Success:
- 30% ticket reduction + 4.0/5.0 satisfaction4. User Stories (Jobs-to-be-Done)
4. 用户故事(Jobs-to-be-Done)
Purpose: Capture user needs in job-to-be-done format
Template:
When [situation], I want to [action], so I can [outcome].Example:
End-User Stories:
1. When I have a billing question, I want instant answers, so I can resolve issues without waiting.
2. When I'm setting up my account, I want step-by-step guidance, so I don't get stuck.
3. When I need to reset my password, I want a simple self-service flow, so I don't need to contact support.
Agent Stories:
1. When a complex issue arrives, I want context from the AI conversation, so I can help efficiently.
2. When training new agents, I want the AI to handle basics, so I can focus on teaching advanced topics.
3. When end users escalate, I want interaction history, so I don't ask redundant questions.目标: 以Jobs-to-be-Done格式捕获用户需求
模板:
当[场景]时,我想要[操作],以便我可以[达成结果]。示例:
End-User Stories:
1. When I have a billing question, I want instant answers, so I can resolve issues without waiting.
2. When I'm setting up my account, I want step-by-step guidance, so I don't get stuck.
3. When I need to reset my password, I want a simple self-service flow, so I don't need to contact support.
Agent Stories:
1. When a complex issue arrives, I want context from the AI conversation, so I can help efficiently.
2. When training new agents, I want the AI to handle basics, so I can focus on teaching advanced topics.
3. When end users escalate, I want interaction history, so I don't ask redundant questions.5. Functional Requirements
5. 功能性需求
Purpose: What the system must do
Categories:
- Core features (P0 - must have)
- Important features (P1 - should have)
- Nice-to-have (P2 - could have)
Example:
P0 (Core - MVP):
- FR-001: System answers common questions from knowledge base
- FR-002: System escalates to human when confidence is low (<70%)
- FR-003: Agents can see full conversation history
- FR-004: System tracks conversation satisfaction ratings
P1 (Important - Post-MVP):
- FR-005: System learns from agent corrections
- FR-006: System handles multi-turn conversations with context
- FR-007: Agents can override AI suggestions
P2 (Nice-to-have - Future):
- FR-008: System proactively suggests help articles
- FR-009: System detects dissatisfied end users
- FR-010: Multi-language support目标: 明确系统必须实现的功能
分类:
- 核心功能(P0 - 必备)
- 重要功能(P1 - 应备)
- 锦上添花功能(P2 - 可选)
示例:
P0 (Core - MVP):
- FR-001: System answers common questions from knowledge base
- FR-002: System escalates to human when confidence is low (<70%)
- FR-003: Agents can see full conversation history
- FR-004: System tracks conversation satisfaction ratings
P1 (Important - Post-MVP):
- FR-005: System learns from agent corrections
- FR-006: System handles multi-turn conversations with context
- FR-007: Agents can override AI suggestions
P2 (Nice-to-have - Future):
- FR-008: System proactively suggests help articles
- FR-009: System detects dissatisfied end users
- FR-010: Multi-language support6. Non-Functional Requirements
6. 非功能性需求
Purpose: How the system should perform
Categories:
- Performance
- Security
- Scalability
- Reliability
- Usability
Example:
Performance:
- NFR-001: Response time <2 seconds for 95th percentile
- NFR-002: Handle 100 concurrent conversations
- NFR-003: Knowledge base search <500ms
Security:
- NFR-004: End-user data encrypted at rest and in transit
- NFR-005: SOC2 Type II compliance
- NFR-006: Role-based access control (RBAC)
- NFR-007: Audit logs for all AI responses
Scalability:
- NFR-008: Support 10,000 conversations/day at launch
- NFR-009: Scale to 100,000 conversations/day within 6 months
Reliability:
- NFR-010: 99.9% uptime SLA
- NFR-011: Graceful degradation if AI service unavailable
Usability:
- NFR-012: Agents can use with <10 minutes training
- NFR-013: WCAG 2.1 AA accessibility compliance目标: 明确系统的性能要求
分类:
- 性能
- 安全性
- 可扩展性
- 可靠性
- 易用性
示例:
Performance:
- NFR-001: Response time <2 seconds for 95th percentile
- NFR-002: Handle 100 concurrent conversations
- NFR-003: Knowledge base search <500ms
Security:
- NFR-004: End-user data encrypted at rest and in transit
- NFR-005: SOC2 Type II compliance
- NFR-006: Role-based access control (RBAC)
- NFR-007: Audit logs for all AI responses
Scalability:
- NFR-008: Support 10,000 conversations/day at launch
- NFR-009: Scale to 100,000 conversations/day within 6 months
Reliability:
- NFR-010: 99.9% uptime SLA
- NFR-011: Graceful degradation if AI service unavailable
Usability:
- NFR-012: Agents can use with <10 minutes training
- NFR-013: WCAG 2.1 AA accessibility compliance7. Technical Constraints
7. 技术约束
Purpose: Technology limitations and requirements
What to Include:
- Existing systems to integrate with
- Technology stack requirements
- Infrastructure constraints
- Budget limitations
- Timeline constraints
Example:
Integrations:
- Must integrate with the existing system of record
- Must use the organization's approved identity provider
- Must emit logs and metrics to the existing observability platform
Technology Stack:
- Backend: Approved backend runtime for the project
- AI model: Approved model provider or self-hosted model
- Retrieval/index layer: Approved search, database, or vector index
- Frontend: Existing UI framework or platform standard
Infrastructure:
- Deploy on the existing hosting or runtime environment
- Use existing CI/CD and release pipelines
Budget:
- AI/service usage budget: TBD monthly maximum
- Infrastructure budget: TBD monthly maximum
Timeline:
- MVP must launch within 10 weeks
- Full feature set within 16 weeks目标: 明确技术限制与要求
需包含内容:
- 需要集成的现有系统
- 技术栈要求
- 基础设施约束
- 预算限制
- 时间线约束
示例:
Integrations:
- Must integrate with the existing system of record
- Must use the organization's approved identity provider
- Must emit logs and metrics to the existing observability platform
Technology Stack:
- Backend: Approved backend runtime for the project
- AI model: Approved model provider or self-hosted model
- Retrieval/index layer: Approved search, database, or vector index
- Frontend: Existing UI framework or platform standard
Infrastructure:
- Deploy on the existing hosting or runtime environment
- Use existing CI/CD and release pipelines
Budget:
- AI/service usage budget: TBD monthly maximum
- Infrastructure budget: TBD monthly maximum
Timeline:
- MVP must launch within 10 weeks
- Full feature set within 16 weeks8. Data Requirements
8. 数据需求
Purpose: What data is needed and how it's managed
Structure:
- Data sources
- Data models
- Data privacy
- Data retention
Example:
Data Sources:
- Knowledge base articles (500+ source documents)
- Historical workflow records (2 years)
- Product or process documentation
- Public or internal FAQ pages
Data Models:
- Interactions: id, end_user_id, operator_id, messages[], status, satisfaction_rating
- Messages: id, sender, text, timestamp, ai_confidence
- Knowledge: id, title, content, embeddings, category, last_updated
Data Privacy:
- PII must be redacted before AI processing
- Conversation data retained for 90 days
- Analytics data aggregated and anonymized
- GDPR right-to-delete compliance
Data Security:
- Encrypt end-user data at rest (AES-256)
- Encrypt in transit (TLS 1.3)
- Role-based access to conversation data目标: 明确所需数据及其管理方式
结构:
- 数据源
- 数据模型
- 数据隐私
- 数据留存
示例:
Data Sources:
- Knowledge base articles (500+ source documents)
- Historical workflow records (2 years)
- Product or process documentation
- Public or internal FAQ pages
Data Models:
- Interactions: id, end_user_id, operator_id, messages[], status, satisfaction_rating
- Messages: id, sender, text, timestamp, ai_confidence
- Knowledge: id, title, content, embeddings, category, last_updated
Data Privacy:
- PII must be redacted before AI processing
- Conversation data retained for 90 days
- Analytics data aggregated and anonymized
- GDPR right-to-delete compliance
Data Security:
- Encrypt end-user data at rest (AES-256)
- Encrypt in transit (TLS 1.3)
- Role-based access to conversation data9. UI/UX Requirements
9. UI/UX需求
Purpose: How users interact with the system
What to Include:
- User flows
- Interface requirements
- Design constraints
- Accessibility needs
Example:
End-User Interface:
- Chat widget in bottom-right corner
- Typing indicators and response time estimates
- Clear "Talk to a human" button always visible
- Conversation history accessible for 30 days
Operator Interface:
- Side panel showing AI suggestions
- One-click "Accept AI answer" button
- Edit AI answer before sending
- Flag incorrect responses for retraining
- Dashboard showing AI performance metrics
User Flows:
1. End user asks question → System retrieves answer → Displays with confidence
2. Low confidence → Auto-escalate to operator → Operator sees full context
3. Operator corrects response → System logs correction for improvement
Design Constraints:
- Match existing brand colors
- Mobile-responsive design
- WCAG 2.1 AA compliant
- Support keyboard navigation目标: 明确用户与系统的交互方式
需包含内容:
- 用户流程
- 界面要求
- 设计约束
- 无障碍需求
示例:
End-User Interface:
- Chat widget in bottom-right corner
- Typing indicators and response time estimates
- Clear "Talk to a human" button always visible
- Conversation history accessible for 30 days
Operator Interface:
- Side panel showing AI suggestions
- One-click "Accept AI answer" button
- Edit AI answer before sending
- Flag incorrect responses for retraining
- Dashboard showing AI performance metrics
User Flows:
1. End user asks question → System retrieves answer → Displays with confidence
2. Low confidence → Auto-escalate to operator → Operator sees full context
3. Operator corrects response → System logs correction for improvement
Design Constraints:
- Match existing brand colors
- Mobile-responsive design
- WCAG 2.1 AA compliant
- Support keyboard navigation10. Risks & Assumptions
10. 风险与假设
Purpose: Identify potential blockers and dependencies
Structure:
- Risks with mitigation plans
- Assumptions to validate
- Dependencies on external factors
Example:
Risks:
1. AI hallucination risk
- Mitigation: Confidence thresholds, human review for low confidence
2. Knowledge base quality risk
- Mitigation: Content audit before launch, SME review of top 100 articles
3. User adoption risk (operators do not rely on assisted output)
- Mitigation: Gradual rollout, agent training, show accuracy metrics
4. API cost overruns
- Mitigation: Aggressive caching, token limits, usage monitoring
Assumptions:
1. End users will accept assisted responses (validate with beta test)
2. Knowledge base is accurate and up-to-date (audit required)
3. 80% of questions can be answered with existing knowledge
4. Approved AI/service latency is acceptable (<2s)
Dependencies:
1. Access to system-of-record API (approval required)
2. Knowledge base export from source repository
3. AI/service quota increase if current limits are insufficient
4. Operator availability for training and feedback目标: 识别潜在障碍与依赖项
结构:
- 风险及缓解方案
- 需要验证的假设
- 对外部因素的依赖
示例:
Risks:
1. AI hallucination risk
- Mitigation: Confidence thresholds, human review for low confidence
2. Knowledge base quality risk
- Mitigation: Content audit before launch, SME review of top 100 articles
3. User adoption risk (operators do not rely on assisted output)
- Mitigation: Gradual rollout, agent training, show accuracy metrics
4. API cost overruns
- Mitigation: Aggressive caching, token limits, usage monitoring
Assumptions:
1. End users will accept assisted responses (validate with beta test)
2. Knowledge base is accurate and up-to-date (audit required)
3. 80% of questions can be answered with existing knowledge
4. Approved AI/service latency is acceptable (<2s)
Dependencies:
1. Access to system-of-record API (approval required)
2. Knowledge base export from source repository
3. AI/service quota increase if current limits are insufficient
4. Operator availability for training and feedback11. Out of Scope
11. 范围外内容
Purpose: Explicitly state what WON'T be built
Why Important: Prevents scope creep and sets expectations
Example:
Out of Scope for MVP:
- Voice/phone support integration (post-MVP)
- Multi-language support (Phase 2)
- Integration with CRM system (future)
- Custom AI model training unless explicitly required
- Mobile app (web only initially)
- Proactive workflow initiation (on-demand assistance only)
- Sentiment analysis dashboard (future analytics)
- Agent performance scoring (v2 feature)
Explicitly NOT Building:
- Custom LLM training (too expensive)
- Real-time translation (complexity vs. value)
- Video call integration (different project)目标: 明确说明不会开发的内容
重要性: 防止范围蔓延,设定预期
示例:
Out of Scope for MVP:
- Voice/phone support integration (post-MVP)
- Multi-language support (Phase 2)
- Integration with CRM system (future)
- Custom AI model training unless explicitly required
- Mobile app (web only initially)
- Proactive workflow initiation (on-demand assistance only)
- Sentiment analysis dashboard (future analytics)
- Agent performance scoring (v2 feature)
Explicitly NOT Building:
- Custom LLM training (too expensive)
- Real-time translation (complexity vs. value)
- Video call integration (different project)12. Open Questions
12. 待解决问题
Purpose: Document unknowns that need answers
Structure:
- Question
- Who can answer
- When answer needed by
- Impact if not answered
Example:
Q1: What error rate is acceptable for assisted responses? Who: product owner and domain owner. Deadline: before target architecture approval. Impact: Determines confidence thresholds and escalation flow.目标: 记录需要解答的未知问题
结构:
- 问题
- 可解答人员
- 解答截止时间
- 未解答的影响
示例:
Q1: What error rate is acceptable for assisted responses? Who: product owner and domain owner. Deadline: before target architecture approval. Impact: Determines confidence thresholds and escalation flow.Examples
示例
Use compact PRPs for bounded Pattern A changes and full-depth PRPs for AI-heavy Pattern C systems. For Pattern C, define model, retrieval, orchestration, evaluation, latency, token budget, privacy, fallback, and human escalation requirements explicitly.
针对边界清晰的模式A变更使用精简版PRP,针对AI重度的模式C系统使用完整版PRP。对于模式C,需明确定义模型、检索、编排、评估、延迟、令牌预算、隐私、回退和人工升级需求。
Best Practices
最佳实践
- Start with the problem before naming solutions.
- Make success criteria measurable.
- Use Jobs-to-be-Done stories to capture user intent.
- State out-of-scope items explicitly.
- Track open questions with owner, deadline, and impact.
- Update the PRP as constraints and evidence change.
- Validate with product, engineering, design, and security stakeholders when relevant.
- 先定义问题,再命名解决方案。
- 让成功标准可衡量。
- 使用Jobs-to-be-Done故事捕获用户意图。
- 明确说明范围外内容。
- 跟踪待解决问题,记录负责人、截止时间和影响。
- 随着约束条件和证据变化更新PRP。
- 必要时与产品、工程、设计和安全相关利益相关者进行验证。
Common Pitfalls
常见误区
- Writing implementation choices instead of behavioral requirements.
- Using vague success criteria such as "better UX" or "fast".
- Omitting non-functional requirements.
- Assuming hidden knowledge instead of documenting it.
- Applying Pattern C complexity to Pattern A work.
- 撰写实现方案而非行为需求。
- 使用模糊的成功标准,如“更好的UX”或“快速”。
- 遗漏非功能性需求。
- 假设存在隐性知识而非将其记录下来。
- 将模式C的复杂度应用于模式A的工作。
Deliverables
交付成果
A complete PRP document containing all 12 sections, a pattern classification, measurable outcomes, explicit scope boundaries, tracked open questions, and stakeholder-ready requirements.
一份包含全部12个板块的完整PRP文档,涵盖模式分类、可衡量成果、明确的范围边界、已跟踪的待解决问题,以及可供利益相关者使用的需求内容。
Success Metrics
成功指标
The PRP is ready when developers can build from it without repeated clarification, stakeholders agree on scope, risks are visible, open questions have owners, and the selected pattern matches the project complexity.
当开发人员无需反复澄清即可基于PRP开展工作、利益相关者对范围达成一致、风险可见、待解决问题有负责人,且所选模式匹配项目复杂度时,PRP即准备就绪。