mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-05-14 18:44:44 +08:00
6556f20af7
Port the current-source-safe command documentation subset from stale PR #1687.\n\nEach copied command page maps to an English source file unchanged since the stale PR base; fastapi-review remains deferred because #1687 did not include a matching zh-CN translation.
454 lines
14 KiB
Markdown
454 lines
14 KiB
Markdown
---
|
||
description: "交互式PRD生成器 - 问题优先、假设驱动的产品规格，通过来回提问进行"
|
||
argument-hint: "[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 模板
|
||
|
||
```markdown
|
||
# {产品/功能名称}
|
||
|
||
## 问题陈述
|
||
|
||
{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：输出 - 总结
|
||
|
||
生成后，报告：
|
||
|
||
```markdown
|
||
## 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 上下文
|
||
|
||
## 成功标准
|
||
|
||
* **问题已验证**：问题是具体且有证据的（或标记为假设）
|
||
* **用户已定义**：主要用户是具体的，而非泛泛的
|
||
* **假设清晰**：具有可衡量结果的可测试假设
|
||
* **范围已界定**：明确的必须拥有项和明确的范围外项
|
||
* **问题已确认**：不确定性已列出，而非隐藏
|
||
* **可操作**：怀疑论者也能理解为什么这件事值得构建
|