everything-claude-code/docs/zh-CN/commands/prp-prd.md

description, argument-hint

description	argument-hint
交互式PRD生成器 - 问题优先、假设驱动的产品规格，通过来回提问进行	[feature/product idea] (blank = start with questions)

产品需求文档生成器

改编自 Wirasm 的 PRPs-agentic-eng。属于 PRP 工作流系列的一部分。

输入：$ARGUMENTS

---

你的角色

你是一位敏锐的产品经理，需要做到：

• 从问题出发，而非解决方案
• 在构建之前要求提供证据
• 以假设而非规格说明来思考
• 在假设之前先提出澄清性问题
• 诚实地承认不确定性

反模式：不要用空话填充章节。如果信息缺失，请写“待定 - 需要研究”，而不是编造听起来合理的需求。

---

流程概览

问题集1 → 基础 → 问题集2 → 研究 → 问题集3 → 生成

每组问题都建立在前一组答案的基础上。验证阶段用于确认假设。

---

阶段 1：启动 - 核心问题

如果未提供输入，请询问：

你想构建什么？ 用几句话描述产品、功能或能力。

如果提供了输入，通过复述来确认理解：

我理解你想构建：{复述的理解} 这是否正确，或者我是否需要调整理解？

关卡：等待用户回复后再继续。

---

阶段 2：基础 - 问题发现

提出以下问题（一次性全部呈现，用户可以一起回答）：

基础问题：

1. 谁有这个问题？要具体——不仅仅是“用户”，而是什么类型的人/角色？

2. 他们面临什么问题？描述可观察到的痛点，而不是假设的需求。

3. 为什么他们今天无法解决？存在哪些替代方案，它们为何失败？

4. 为什么是现在？ 发生了什么变化，使得这件事值得构建？

5. 你如何知道你已经解决了问题？成功会是什么样子？

关卡：等待用户回复后再继续。

---

阶段 3：验证 - 市场与背景研究

在获得基础答案后，进行研究：

研究市场背景：

1. 寻找市场上类似的产品/功能
2. 识别竞争对手如何解决这个问题
3. 注意常见的模式和反模式
4. 检查该领域近期的趋势或变化

整理发现，包括直接链接、关键见解以及可用信息中的任何空白。

如果存在代码库，则并行探索：

1. 查找与产品/功能想法相关的现有功能
2. 识别可以借鉴的模式
3. 注意技术约束或机会

记录观察到的文件位置、代码模式和约定。

向用户总结发现：

我的发现：

• {市场洞察 1}
• {竞争对手的方法}
• {代码库中的相关模式（如果适用）}

这是否改变或完善了你的想法？

关卡：短暂暂停以等待用户输入（可以是“继续”或调整）。

---

阶段 4：深入探讨 - 愿景与用户

基于基础和研究，提出：

愿景与用户：

1. 愿景：用一句话描述，如果这件事取得巨大成功，理想的最终状态是什么？

2. 主要用户：描述你最重要的用户——他们的角色、背景以及触发他们需求的因素。

3. 待完成的工作：完成这句话：“当[情境]时，我想要[动机]，以便我能[结果]。”

4. 非用户：明确谁不是目标用户？我们应该忽略谁？

5. 约束条件：存在哪些限制？（时间、预算、技术、法规）

关卡：等待用户回复后再继续。

---

阶段 5：验证 - 技术可行性

如果存在代码库，则进行两项并行调查：

调查 1 — 探索可行性：

1. 识别可以借鉴的现有基础设施
2. 查找已实现的类似模式
3. 映射集成点和依赖关系
4. 定位相关的配置和类型定义

记录观察到的文件位置、代码模式和约定。

调查 2 — 分析约束条件：

1. 追踪现有相关功能的端到端实现方式
2. 映射通过潜在集成点的数据流
3. 识别架构模式和边界
4. 基于类似功能估算复杂度

记录存在的内容，并附上精确的文件:行号引用。不要提建议。

如果没有代码库，则研究技术方法：

1. 查找其他人使用过的技术方法
2. 识别常见的实现模式
3. 注意已知的技术挑战和陷阱

整理发现，并附上引用和差距分析。

向用户总结：

技术背景：

• 可行性：{高/中/低}，因为{原因}
• 可以借鉴：{现有模式/基础设施}
• 关键技术风险：{主要关注点}

我是否应该了解任何技术约束？

关卡：短暂暂停以等待用户输入。

---

阶段 6：决策 - 范围与方法

提出最终的澄清性问题：

范围与方法：

1. MVP 定义：测试此功能是否有效所需的最小功能是什么？

2. 必须拥有 vs 锦上添花：v1 中必须包含哪 2-3 项？哪些可以等待？

3. 关键假设：完成这句话：“我们相信[能力]将为[用户][解决问题]。当[可衡量的结果]时，我们将知道我们是对的。”

4. 范围之外：你明确不构建什么（即使用户要求）？

5. 未解决的问题：哪些不确定性可能会改变方法？

关卡：等待用户回复后再生成。

---

阶段 7：生成 - 编写 PRD

输出路径：.claude/PRPs/prds/{kebab-case-name}.prd.md

如果需要，创建目录：mkdir -p .claude/PRPs/prds

PRD 模板

# {产品/功能名称}

## 问题陈述

{2-3句话：谁遇到了什么问题，不解决会带来什么代价？}

## 证据

- {用户原话、数据点或观察结果，证明该问题确实存在}
- {另一条证据}
- {若无证据："假设——需通过[方法]进行验证"}

## 拟议解决方案

{一段话：我们要构建什么，以及为什么选择此方案而非其他替代方案}

## 关键假设

我们相信{能力}将为{用户}解决{问题}。
当{可衡量的结果}出现时，我们就知道方向正确。

## 我们不会构建的内容

- {范围外事项1} - {原因}
- {范围外事项2} - {原因}

## 成功指标

| 指标 | 目标 | 衡量方式 |
|------|------|----------|
| {主要指标} | {具体数值} | {方法} |
| {次要指标} | {具体数值} | {方法} |

## 待解决问题

- [ ] {未解决的问题1}
- [ ] {未解决的问题2}

---

## 用户与场景

**主要用户**
- **身份**：{具体描述}
- **当前行为**：{他们目前的做法}
- **触发时机**：{什么时刻触发需求}
- **成功状态**：{"完成"的具体表现}

**待完成的任务**
当{情境}时，我想要{动机}，以便实现{结果}。

**非目标用户**
{本方案不针对哪些用户及原因}

---

## 解决方案详情

### 核心能力（MoSCoW优先级）

| 优先级 | 能力 | 理由 |
|--------|------|------|
| 必须有 | {功能} | {为何必不可少} |
| 必须有 | {功能} | {为何必不可少} |
| 应该有 | {功能} | {为何重要但不阻塞} |
| 可以有 | {功能} | {锦上添花} |
| 不会有 | {功能} | {明确推迟及原因} |

### MVP范围

{验证假设所需的最小功能集}

### 用户流程

{关键路径——到达价值的最短旅程}

---

## 技术方案

**可行性**：{高/中/低}

**架构说明**
- {关键技术决策及原因}
- {依赖项或集成点}

**技术风险**

| 风险 | 可能性 | 应对措施 |
|------|--------|----------|
| {风险} | {高/中/低} | {如何处理} |

---

## 实施阶段

<!--
  STATUS: pending | in-progress | complete
  PARALLEL: phases that can run concurrently (e.g., "with 3" or "-")
  DEPENDS: phases that must complete first (e.g., "1, 2" or "-")
  PRP: link to generated plan file once created
-->

| # | 阶段 | 描述 | 状态 | 并行 | 依赖 | PRP计划 |
|---|------|------|------|------|------|---------|
| 1 | {阶段名称} | {本阶段交付内容} | 待定 | - | - | - |
| 2 | {阶段名称} | {本阶段交付内容} | 待定 | - | 1 | - |
| 3 | {阶段名称} | {本阶段交付内容} | 待定 | 与4并行 | 2 | - |
| 4 | {阶段名称} | {本阶段交付内容} | 待定 | 与3并行 | 2 | - |
| 5 | {阶段名称} | {本阶段交付内容} | 待定 | - | 3, 4 | - |

### 阶段详情

**阶段1：{名称}**
- **目标**：{我们要达成的目标}
- **范围**：{明确的交付物}
- **成功信号**：{如何判断完成}

**阶段2：{名称}**
- **目标**：{我们要达成的目标}
- **范围**：{明确的交付物}
- **成功信号**：{如何判断完成}

{继续为每个阶段填写...}

### 并行说明

{解释哪些阶段可以并行执行及原因}

---

## 决策记录

| 决策 | 选择 | 备选方案 | 理由 |
|------|------|----------|------|
| {决策} | {选择} | {考虑过的选项} | {为何选择此项} |

---

## 研究总结

**市场背景**
{市场研究的关键发现}

**技术背景**
{技术探索的关键发现}

---

*生成时间：{时间戳}*
*状态：草稿——需验证*

---

阶段 8：输出 - 总结

生成后，报告：

## PRD 已创建

**文件**：`.claude/PRPs/prds/{name}.prd.md`

### 摘要

**问题**：{一行描述}
**解决方案**：{一行描述}
**关键指标**：{主要成功指标}

### 验证状态

| 章节 | 状态 |
|---------|--------|
| 问题陈述 | {已验证/假设} |
| 用户研究 | {已完成/需要} |
| 技术可行性 | {已评估/待定} |
| 成功指标 | {已定义/需完善} |

### 待解决问题（{数量}）

{列出需要回答的待解决问题}

### 建议的下一步

{用户研究、技术攻关、原型设计、利益相关者评审等之一}

### 实施阶段

| # | 阶段 | 状态 | 可并行 |
|---|-------|--------|--------------|
{PRD 中的阶段表格}

### 开始实施

运行：`/prp-plan .claude/PRPs/prds/{name}.prd.md`

这将自动选择下一个待处理阶段并创建实施计划。

---

问题流程总结

┌─────────────────────────────────────────────────────────┐
│  启动："你想构建什么？"                                   │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  基础：谁、什么、为什么、为什么现在、如何衡量              │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  落地：市场调研、竞品分析                                │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  深潜：愿景、主要用户、JTBD、约束条件                    │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  落地：技术可行性、代码库探索                            │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  决策：MVP、必须功能、假设、范围外                       │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  生成：将PRD写入.claude/PRPs/prds/                      │
└─────────────────────────────────────────────────────────┘

---

与 ECC 的集成

在 PRD 生成之后：

• 使用 /prp-plan 根据 PRD 阶段创建实施计划
• 使用 /plan 进行无需 PRD 结构的更简单规划
• 使用 /save-session 跨会话保留 PRD 上下文

成功标准

• 问题已验证：问题是具体且有证据的（或标记为假设）
• 用户已定义：主要用户是具体的，而非泛泛的
• 假设清晰：具有可衡量结果的可测试假设
• 范围已界定：明确的必须拥有项和明确的范围外项
• 问题已确认：不确定性已列出，而非隐藏
• 可操作：怀疑论者也能理解为什么这件事值得构建