prd

产品需求文档（PRD）

概述

设计全面、生产级的产品需求文档（PRD），弥合业务愿景与技术执行之间的鸿沟。此技能适用于现代软件系统，确保需求得到清晰定义。

何时使用

在以下情况使用此技能：

• 启动新产品或功能开发周期时
• 将模糊的想法转化为具体的技术规格时
• 为 AI 驱动的功能定义需求时
• 相关方需要项目范围的统一“事实来源”时
• 用户要求“写一份 PRD”、“记录需求”或“规划一个功能”时

---

操作工作流

阶段 1：探索（访谈）

在写下 PRD 的第一行之前，你必须询问用户以填补知识空白。不要假设上下文。

询问以下内容：

• 核心问题：我们为什么现在要构建这个？
• 成功指标：我们如何知道它奏效了？
• 约束条件：预算、技术栈或截止日期？

阶段 2：分析与范围界定

综合用户的输入。识别依赖关系和隐藏的复杂性。

• 梳理用户流程。
• 定义非目标以保护时间线。

阶段 3：技术起草

使用下方的严格 PRD 模式生成文档。

---

PRD 质量标准

需求质量

使用具体、可衡量的标准。避免“快速”、“简单”或“直观”。

# Vague (BAD)
- The search should be fast and return relevant results.
- The UI must look modern and be easy to use.

# Concrete (GOOD)
+ The search must return results within 200ms for a 10k record dataset.
+ The search algorithm must achieve >= 85% Precision@10 in benchmark evals.
+ The UI must follow the 'Vercel/Next.js' design system and achieve 100% Lighthouse Accessibility score.

---

严格 PRD 模式

输出必须遵循以下确切结构：

1. 执行摘要

• 问题陈述：用 1-2 句话说明痛点。
• 建议方案：用 1-2 句话说明解决方案。
• 成功标准：3-5 个可衡量的 KPI。

2. 用户体验与功能

• 用户画像：这是为谁设计的？
• 用户故事：作为 [用户]，我希望 [操作]，以便 [收益]。
• 验收标准：每个故事的“完成”定义的项目符号列表。
• 非目标：我们不构建什么？

3. AI 系统需求（如适用）

• 工具需求：需要哪些工具和 API？
• 评估策略：如何衡量输出质量和准确性。

4. 技术规格

• 架构概述：数据流和组件交互。
• 集成点：API、数据库和认证。
• 安全与隐私：数据处理和合规性。

5. 风险与路线图

• 分阶段推出：MVP -> v1.1 -> v2.0。
• 技术风险：延迟、成本或依赖故障。

---

实施指南

应该做（始终）

• 定义测试：对于 AI 系统，指定如何测试和验证输出质量。
• 迭代：呈现草稿并针对具体部分征求反馈。

不应该做（避免）

• 跳过探索：绝不在未先提出至少 2 个澄清问题的情况下编写 PRD。
• 臆造约束条件：如果用户未指定技术栈，请询问或将其标记为 TBD。

---

示例：智能搜索系统

1. 执行摘要

问题：用户难以在庞大的代码仓库中找到特定的文档片段。 解决方案：一个智能搜索系统，提供带有来源引用的直接答案。 成功：

• 将搜索时间减少 50%。
• 引用准确率 >= 95%。

2. 用户故事

• 故事：作为开发者，我希望提出自然语言问题，这样我就不必猜测关键词。
• AC：
  • 支持多轮澄清。
  • 返回带有“复制”按钮的代码块。

3. AI 系统架构

• 所需工具：codesearch、grep、webfetch。

4. 评估

• 基准：用 50 个常见开发者问题进行测试。
• 通过率：90% 必须与预期引用匹配。