PRP Generator

PRP 生成器（产品需求提示词）

概述

PRP 生成器可帮助你创建全面的产品需求提示词（PRP）——用于记录构建产品功能或系统所需全部信息的结构化文档。PRP 针对 AI 辅助开发进行了优化，提供清晰的需求，便于人和 AI 理解。

核心目的： 将模糊的想法转化为可执行且完整的需求。

何时使用此技能

在以下情况下使用 PRP 生成器：

• 启动新产品或重要功能
• 需求不明确或分散
• 需要向开发团队传达需求
• 使用 AI 助手进行实现
• 从探索阶段过渡到开发阶段
• 帮助新团队成员熟悉项目

主要功能

• 将需求整理为 12 个标准章节
• 确定项目复杂度模式（A、B、C）
• 按 Jobs-to-be-Done 格式提取用户故事
• 定义成功标准和指标
• 记录功能性和非功能性需求
• 梳理约束、风险和假设
• 明确范围内和范围外的内容

工作流

PRP 的 12 个章节

一份完整的 PRP 包含以下 12 个章节：

1. 项目概述
2. 问题陈述
3. 成功标准
4. 用户故事（Jobs-to-be-Done）
5. 功能需求
6. 非功能需求
7. 技术约束
8. 数据需求
9. UI/UX 需求
10. 风险与假设
11. 范围外事项
12. 待解问题

下面逐一介绍：

---

1. 项目概述

目的： 提供高层背景并分类项目模式

应包含内容：

• 项目名称和一句话描述
• 模式分类（A、B 或 C）
• 时间线估算
• 目标用户
• 业务背景

示例：

Project: Customer Support Chatbot
Pattern: C (AI-Native System)
Timeline: 10-12 weeks
Users: Customer support agents + end customers
Context: Reduce support ticket volume by 40% while maintaining customer satisfaction

---

2. 问题陈述

目的： 清晰定义要解决的问题

模板：

[User type] faces [problem] when [situation].
This causes [negative outcome].
We know this because [evidence].

示例：

Customer support agents face long response times when customers ask common questions about billing, account setup, and feature usage. This causes customer frustration and agent burnout handling repetitive inquiries.

We know this because:
- 60% of tickets are "How do I..." questions
- Average response time is 4 hours
- Agent surveys show 70% of time spent on repetitive questions
- NPS dropped from 45 to 38 in past 6 months

---

3. 成功标准

目的： 定义可衡量的结果

结构：

• 主要指标（北极星指标）
• 次要指标
• 最低成功门槛

示例：

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

---

4. 用户故事（Jobs-to-be-Done）

目的： 按 Jobs-to-be-Done 格式记录用户需求

模板：

When [situation], I want to [action], so I can [outcome].

示例：

Customer 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 customers escalate, I want conversation history, so I don't ask redundant questions.

---

5. 功能需求

目的： 系统必须实现的功能

类别：

• 核心功能（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 frustrated customers
- FR-010: Multi-language support

---

6. 非功能需求

目的： 定义系统应达到的表现

类别：

• 性能
• 安全性
• 可扩展性
• 可靠性
• 易用性

示例：

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: Customer 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

---

7. 技术约束

目的： 说明技术限制和要求

应包含内容：

• 需要集成的现有系统
• 技术栈要求
• 基础设施约束
• 预算限制
• 时间线约束

示例：

Integrations:
- Must integrate with existing Zendesk system
- Must use company SSO (Okta)
- Must log to existing Datadog monitoring

Technology Stack:
- Backend: Python (existing team expertise)
- LLM: OpenAI GPT-4 (approved vendor)
- Vector DB: Pinecone or Weaviate (to be decided)
- Frontend: React (existing stack)

Infrastructure:
- Deploy on existing AWS infrastructure
- Use existing CI/CD pipelines (GitHub Actions)

Budget:
- OpenAI API budget: $5,000/month maximum
- Infrastructure: $2,000/month maximum

Timeline:
- MVP must launch within 10 weeks
- Full feature set within 16 weeks

---

8. 数据需求

目的： 说明所需数据及其管理方式

结构：

• 数据来源
• 数据模型
• 数据隐私
• 数据保留

示例：

Data Sources:
- Knowledge base articles (500+ articles in Notion)
- Historical support tickets (Zendesk, 2 years)
- Product documentation (GitHub docs)
- FAQ pages (company website)

Data Models:
- Conversations: id, customer_id, agent_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 customer data at rest (AES-256)
- Encrypt in transit (TLS 1.3)
- Role-based access to conversation data

---

9. UI/UX 需求

目的： 说明用户如何与系统交互

应包含内容：

• 用户流程
• 界面要求
• 设计约束
• 无障碍需求

示例：

Customer 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

Agent 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. Customer asks question → AI retrieves answer → Displays with confidence
2. Low confidence → Auto-escalate to agent → Agent sees full context
3. Agent corrects AI → System logs for improvement

Design Constraints:
- Match existing brand colors
- Mobile-responsive design
- WCAG 2.1 AA compliant
- Support keyboard navigation

---

10. 风险与假设

目的： 识别潜在阻碍因素和依赖项

结构：

• 风险及其缓解计划
• 需要验证的假设
• 对外部因素的依赖

示例：

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 (agents don't trust AI)
   - Mitigation: Gradual rollout, agent training, show accuracy metrics

4. API cost overruns
   - Mitigation: Aggressive caching, token limits, usage monitoring

Assumptions:
1. Customers will accept AI 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. OpenAI API latency is acceptable (<2s)

Dependencies:
1. Access to Zendesk API (need approval from IT)
2. Knowledge base export from Notion
3. OpenAI API quota increase (currently limited)
4. Agent availability for training and feedback

---

11. 范围外事项

目的： 明确说明不会构建的内容

重要性： 防止范围蔓延并设定预期

示例：

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 (using OpenAI)
- Mobile app (web only initially)
- Proactive outreach (reactive support 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:

Q1: What's acceptable AI error rate for customers?
- Who: Product Manager + Customer Success lead
- Deadline: Week 2 (before architecture finalized)
- Impact: Determines confidence thresholds and escalation flow

Q2: Can we access historical conversation sentiment data?
- Who: Data team
- Deadline: Week 3 (before training data collection)
- Impact: Improves AI tone matching

Q3: What's our Zendesk API rate limit?
- Who: IT/Infrastructure
- Deadline: Week 1 (critical for architecture)
- Impact: May need caching strategy

Q4: Do we have budget for Pinecone or need open-source vector DB?
- Who: Engineering Manager
- Deadline: Week 2 (affects tech stack)
- Impact: Pinecone is easier, open-source is cheaper but more work

Q5: Are agents allowed to edit AI-generated responses?
- Who: Legal/Compliance
- Deadline: Week 4 (before feature development)
- Impact: Affects agent interface design

---

示例

示例 1：简单功能（模式 A）

项目： 为用户仪表板添加 CSV 导出功能

# PRP: CSV Export Feature

## 1. Project Overview

Pattern A (Simple Feature)
Timeline: 2-3 days
Add CSV export button to user dashboard

## 2. Problem Statement

Users need to export data for offline analysis. Currently they must manually copy-paste.

## 3. Success Criteria

- 80% of users who click export get successful download
- <5s export time for typical dataset (1000 rows)

## 4. User Stories

When viewing my data, I want to click "Export CSV", so I can analyze it in Excel.

## 5. Functional Requirements

FR-001: Export button in dashboard toolbar
FR-002: Exports all visible columns
FR-003: Respects current filters
FR-004: Filename includes timestamp

## 6-12. [Abbreviated for Pattern A]

---

示例 2：新产品（模式 B）

请参阅上述各章节中的客户支持聊天机器人示例

---

示例 3：AI 原生系统（模式 C）

项目： 多 Agent 研究助手

# PRP: Multi-Agent Research Assistant

## 1. Project Overview

Pattern C (AI-Native System)
Timeline: 14-16 weeks
Multi-agent system with specialized agents for research, synthesis, and fact-checking

## 2. Problem Statement

Researchers spend 60% of their time finding and synthesizing papers instead of analysis. Current tools return overwhelming results without quality filtering.

## 3. Success Criteria

Primary: Reduce research time from 8 hours to 2 hours per topic
Secondary:

- 90% accuracy in paper relevance
- 85% user satisfaction
- <30s for initial results
- 5+ papers synthesized per query

## 4. User Stories

- When I enter a research topic, I want a synthesized summary with sources, so I can quickly understand the landscape
- When results are vague, I want follow-up questions suggested, so I can refine my search
- When I find a relevant paper, I want related papers suggested, so I can explore deeper

## 5. Functional Requirements (AI-specific)

FR-001: Search agent queries multiple academic databases
FR-002: Filter agent scores paper relevance (0-100)
FR-003: Synthesis agent creates 500-word summary
FR-004: Fact-check agent validates key claims
FR-005: Orchestrator coordinates agents and resolves conflicts

## 6. Non-Functional Requirements (AI-specific)

NFR-001: Agent coordination latency <5s
NFR-002: RAG retrieval accuracy >90%
NFR-003: Handle 50 concurrent research sessions
NFR-004: LLM token budget: $10/research session maximum

## 7. Technical Constraints (AI-specific)

- LLM: GPT-4 for synthesis, GPT-3.5 for filtering
- Vector DB: Pinecone (1M vectors)
- Agent framework: LangChain or CrewAI
- Academic APIs: Semantic Scholar, arXiv

## 8. Data Requirements (AI-specific)

- Paper embeddings: title + abstract + keywords
- Citation network graph for related papers
- User research history for personalization
- Fact-check database with verified claims

## 9-12. [Complete as per structure]

---

最佳实践

1. 从问题出发，而非解决方案

先撰写问题陈述，再编写功能需求。在明确“是什么”之前，先弄清楚“为什么”。

2. 让成功标准可衡量

不佳：“改善用户体验” 良好：“将任务完成率从 60% 提升至 85%”

3. 使用待完成工作格式

捕捉用户意图，而不只是功能请求。

4. 明确说明不在范围内的内容

避免日后出现“我以为我们要构建 X”的争论。

5. 记录所有未决问题

不要掩盖未知事项。应将其明确列出并跟踪解决情况。

6. 随着了解加深更新 PRP

PRP 会不断演进。发现新信息时应及时更新。

7. 与利益相关者审查

与以下人员共同验证 PRP：

• 产品经理（业务需求）
• 工程负责人（技术可行性）
• 设计师（UX 需求）
• 安全团队（合规要求）

---

常见陷阱

1. 编写解决方案，而非需求

反模式：“使用 React 和 Redux 进行状态管理” 更好的做法：“系统必须支持多个视图之间的实时更新”

2. 成功标准含糊不清

反模式：“用户应该感到满意” 更好的做法：“NPS 得分 >50，任务完成率 >80%”

3. 缺少非功能性需求

**反模式：**只列出功能 **更好的做法：**纳入性能、安全性和可扩展性要求

4. 假设大家都已知晓

反模式：“显然我们需要身份验证” **更好的做法：**明确说明所有需求

5. 混合不同模式的复杂度

**反模式：**模式 A 搭配模式 C 的编排 **更好的做法：**让 PRP 的深度与模式复杂度相匹配

---

相关技能

• framework-orchestrator - 使用 PRP 确定模式和执行顺序
• product-strategist - 在创建 PRP 前验证问题
• user-researcher - 为 PRP 提供用户洞察
• bmad-method - 通过商业模式明确技术需求
• security-architect - 安全需求章节
• api-designer - 技术约束章节

---

交付物

一份完整的 PRP 文档，包含：

1. 已填写的全部 12 个章节
2. 模式分类（A、B 或 C）
3. 已由关键利益相关者审查
4. 已跟踪未决问题及其负责人和截止日期
5. 已进行版本控制（随着了解加深而更新）

---

成功指标

满足以下条件时，说明你已创建出一份优秀的 PRP：

• 开发人员无需不断澄清即可据此构建
• 利益相关者就范围和成功标准达成一致
• 风险和假设尽早显现
• 不在范围内的内容清晰明确
• 未决问题均有负责人和截止日期
• 模式复杂度与项目实际情况相符

---

**请记住：**优秀的 PRP 能让开发井然有序，避免范围混乱蔓延。前期投入时间，能为之后节省数周时间。