名称：产品简报描述：通过引导式问题提取产品想法并生成产品需求文档（PRD）

目的

通过引导式问题从你的头脑中提取产品想法，然后生成详细的产品需求文档（PRD）。专为产品人员设计，他们有愿景但需要帮助清晰地表达它。

解决的问题

你脑海中有一个产品或功能的构想，但难以全面解释。此命令充当你的产品思考伙伴——提出正确的问题以提取你所设想的内容，然后将其构建成可供团队执行的PRD。

使用方式

/product-brief [初始想法]

示例：

/product-brief 为我们的应用添加通知系统
/product-brief 构建客户反馈门户
/product-brief 为新用户创建入门流程
/product-brief（提示输入想法）

流程

阶段1：捕获初始想法

如果未提供想法： 询问：“你在思考什么产品或功能？”

等待描述（从1句话到几段）
将其捕获为起点

如果提供想法： 从用户提供的任何内容开始：

可以是1句话或5段
将其捕获为起点
不评判，仅吸收

显示：

## 初始想法

[用户描述]

---

**下一步：** 我将询问几个问题以更好地理解。

阶段2：澄清问题（对话式）

重要： 以对话方式提问，而非调查。每次2-3个问题，等待回答后再提问更多。

提问策略：

第1轮（关键上下文）：

这解决了什么问题？
这是为谁设计的？
成功的标准是什么？

第2轮（约束与范围）： 基于第1轮答案，询问：

时间线期望
技术约束
需集成的现有系统
明确排除的内容

第3轮（用户体验）：

用户如何发现这个？
核心用户旅程是什么？
哪些操作应简单 vs 困难？

第4轮（成功与验证）：

我们如何知道这成功了？
我们有哪些需要验证的假设？
存在哪些依赖？

自适应提问： 如果用户早期提及利益相关者、预算或其他上下文，相应调整问题。不重复已知信息。

每轮后，简要确认答案并自然过渡：

“明白了。这帮助我理解了[X]。关于[Y]的更多问题…”

阶段3：理解总结

在继续前进之前，确认正确捕获了愿景：

## 我所听到的

**问题：**
[综合问题陈述]

**目标用户：**
[为谁设计]

**核心价值：**
[主要好处/结果]

**关键约束：**
[时间线、技术、范围边界]

**需要验证的假设：**
[我们假设但应测试的事项]

---

**这捕获了你的愿景吗？输入“是”继续或更正以上内容。**

如果用户更正，更新并重新确认。

阶段4：规格文档

用户触发：spec doc 或 create spec

生成结构化产品规格：

# 产品规格：[功能/产品名称]

**日期：** YYYY-MM-DD
**负责人：** [用户姓名]
**状态：** 草案

---

## 执行摘要

[2-3句话推介：这是什么以及为何重要]

---

## 问题陈述

### 当前状况
[今天存在什么]

### 痛点
- [具体痛点1]
- [具体痛点2]
- [具体痛点3]

### 不行动的后果
[如果不构建这个会发生什么]

---

## 目标受众

### 主要用户
[谁最常使用这个]

### 次要用户
[谁还受益]

### 用户特征
- [关键特征1]
- [关键特征2]
- [关键特征3]

---

## 解决方案概述

[我们构建内容的高层描述]

---

## 关键功能与特性

### 必须拥有（MVP）
1. **[功能1]**
   - 描述
   - 为何关键
   
2. **[功能2]**
   - 描述
   - 为何关键

### 应该拥有（阶段2）
1. **[功能3]**
   - 描述
   - 为何有价值

### 可有可无（未来）
1. **[功能4]**
   - 描述
   - 为何理想

---

## 成功指标

### 主要指标
[最重要的一个数字]

### 次要指标
- [指标2]
- [指标3]

### 领先指标
[成功/失败的早期信号]

---

## 假设与风险

### 关键假设
1. [假设1]
   - 如何验证：[测试方法]
   
2. [假设2]
   - 如何验证：[测试方法]

### 风险
1. **[风险1]** — [缓解策略]
2. **[风险2]** — [缓解策略]

---

## 依赖

### 技术
- [系统/API/服务依赖]

### 团队
- [谁需要参与]

### 外部
- [第三方依赖]

---

## 排除范围

明确不包括：
- [事项1]
- [事项2]
- [事项3]

---

## 开放问题

- [ ] [问题1]
- [ ] [问题2]
- [ ] [问题3]

---

**下一步：**

- 输入 `prioritize` 按努力/影响对功能排序
- 输入 `design flows` 创建详细用户流程
- 输入 `create prd` 生成最终PRD
- 输入 `back` 修订以上内容

阶段5：优先级排序（可选）

用户触发：prioritize

创建努力/影响矩阵：

## 功能优先级排序

| 功能 | 影响 | 努力 | 优先级 | 理由 |
|---------|--------|--------|----------|-----------|
| [功能1] | 高 | 低 | P0 | [原因] |
| [功能2] | 高 | 中 | P0 | [原因] |
| [功能3] | 中 | 低 | P1 | [原因] |
| [功能4] | 低 | 高 | P2 | [原因] |

### 推荐MVP范围

基于高影响 + 合理努力：
1. [功能1]
2. [功能2]
3. [功能3]

**估计努力：** [X周/冲刺]

---

**下一步：**
- 输入 `design flows` 创建用户流程
- 输入 `create prd` 生成最终PRD
- 输入 `back` 修订规格

阶段6：设计流程（可选）

用户触发：design flows

创建详细用户流程和屏幕规格：

## 用户流程与屏幕规格

### 流程1：[主要用户旅程]

**入口点：** [用户如何到达]

**步骤：**

#### 步骤1：[屏幕名称]

**布局：**
- [头部元素]
- [主要内容区域]
- [操作/按钮]

**用户操作：**
- 点击 [X] → [结果]
- 输入 [Y] → [验证规则]
- 取消 → [状态变化]

**导航：**
- 成功 → [下一屏幕]
- 错误 → [错误状态]
- 返回 → [上一屏幕]

**验证规则：**
- [字段1]：[规则]
- [字段2]：[规则]

**状态：**
- 默认：[描述]
- 加载中：[用户看到什么]
- 错误：[错误消息]
- 成功：[确认]

---

#### 步骤2：[下一屏幕]

[与步骤1相同结构]

---

### 流程2：[次要旅程]

[与流程1相同结构]

---

**下一步：**
- 输入 `create prd` 生成最终PRD
- 输入 `back` 修订流程

阶段7：最终PRD

用户触发：create prd 或 generate prd

生成综合PRD，结合所有先前阶段：

# 产品需求文档
## [产品/功能名称]

**作者：** [用户姓名]
**日期：** YYYY-MM-DD
**状态：** 草案
**最后更新：** YYYY-MM-DD

---

## 文档控制

| 版本 | 日期 | 作者 | 变更 |
|---------|------|--------|---------|
| 0.1 | YYYY-MM-DD | [姓名] | 初始草案 |

---

## 执行摘要

[2-3段涵盖：什么、为什么、谁、成功]

---

## 背景与上下文

### 当前状态
[今天存在什么]

### 问题陈述
[我们解决的问题]

### 机会
[为何现在、为何我们]

---

## 目标与成功指标

### 主要目标
[主要目标]

### 成功指标

**主要：**
- [指标1]：[目标]

**次要：**
- [指标2]：[目标]
- [指标3]：[目标]

**领先指标：**
- [早期信号1]
- [早期信号2]

---

## 目标用户

### 主要受众
[详细描述]

### 使用案例
1. **[使用案例1]**
   - 作为 [用户类型]
   - 我想要 [操作]
   - 以便 [好处]

2. **[使用案例2]**
   - 作为 [用户类型]
   - 我想要 [操作]
   - 以便 [好处]

---

## 解决方案概述

[我们构建内容的全面描述]

---

## 功能需求

### 必须拥有（P0）

#### 需求1：[名称]
- **描述：** [做什么]
- **验收标准：**
  - [ ] [标准1]
  - [ ] [标准2]
  - [ ] [标准3]
- **用户故事：** 作为 [X]，我想要 [Y]，以便 [Z]

#### 需求2：[名称]
[相同结构]

### 应该拥有（P1）

[与必须拥有相同结构]

### 可有可无（P2）

[与必须拥有相同结构]

---

## 用户体验

### 用户流程
[引用阶段6的流程，如果跳过则创建]

### 关键屏幕
[高层屏幕描述]

### 交互模式
[用户如何与功能交互]

---

## 技术需求

### 性能
- [需求1]
- [需求2]

### 安全
- [需求1]
- [需求2]

### 集成点
- [系统1]：[需要连接什么]
- [系统2]：[需要连接什么]

### 数据需求
- [收集什么数据]
- [存储在哪里]
- [如何使用]

---

## 设计需求

### 视觉设计
- [风格指南合规]
- [响应式需求]
- [可访问性标准]

### 内容需求
- [文案需求]
- [翻译需求]
- [资产需求]

---

## 依赖与约束

### 依赖
- **技术：** [列表]
- **团队：** [谁需要参与]
- **外部：** [第三方]

### 约束
- **时间线：** [日期/里程碑]
- **预算：** [如果适用]
- **技术：** [平台限制]

---

## 假设与风险

### 假设
1. [假设1]
   - **验证方法：** [如何测试]
   - **如果错误的后果：** [结果]

2. [假设2]
   - **验证方法：** [如何测试]
   - **如果错误的后果：** [结果]

### 风险

| 风险 | 可能性 | 影响 | 缓解策略 |
|------|------------|--------|------------|
| [风险1] | 高/中/低 | 高/中/低 | [策略] |
| [风险2] | 高/中/低 | 高/中/低 | [策略] |

---

## 排除范围

此版本明确不包括：
- [事项1] — [为何/何时可能包括]
- [事项2] — [为何/何时可能包括]
- [事项3] — [为何/何时可能包括]

---

## 开放问题

- [ ] [问题1] — 负责人：[姓名]，截止：[日期]
- [ ] [问题2] — 负责人：[姓名]，截止：[日期]
- [ ] [问题3] — 负责人：[姓名]，截止：[日期]

---

## 时间线与里程碑

| 里程碑 | 目标日期 | 状态 |
|-----------|-------------|--------|
| PRD完成 | [日期] | 进行中 |
| 设计完成 | [日期] | 未开始 |
| 开发完成 | [日期] | 未开始 |
| 测试完成 | [日期] | 未开始 |
| 启动 | [日期] | 未开始 |

---

## 利益相关者

| 姓名 | 角色 | 参与度 |
|------|------|-------------|
| [姓名] | [角色] | [他们做什么] |
| [姓名] | [角色] | [他们做什么] |

---

## 附录

### 研究
[链接到用户研究、竞争分析等]

### 设计模拟
[链接到设计可用时]

### 技术规格
[链接到技术文档]

---

**文档状态：** 准备审查

**下一步行动：**
- [ ] 与利益相关者审查
- [ ] 基于反馈优化
- [ ] 获得批准继续
- [ ] 移交给设计/工程

---

*此PRD使用 /product-brief 命令生成。根据需要更新。*

阶段8：保存与集成

生成PRD后：

保存文档：
- 创建文件夹：04-Projects/[产品名称]/
- 保存为：04-Projects/[产品名称]/PRD.md
创建人员页面（如果提及利益相关者）：
- 对于每个提及的利益相关者，检查人员页面是否存在
- 在 People/Internal/ 或 People/External/ 中创建/更新页面
- 在他们的页面中添加引用此项目的备注
链接到 03-Tasks/Tasks.md：
- 如果用户提及任何立即行动，建议创建任务
- 将任务链接到项目
确认完成：

## ✅ PRD 已创建

**保存到：** `04-Projects/[产品名称]/PRD.md`

**下一步：**
1. 审查并优化PRD
2. 与利益相关者分享以获取反馈
3. 使用 `/project-health` 跟踪进展
4. 准备执行时在 03-Tasks/Tasks.md 中创建任务

**想要：**
- 修订任何部分 → 只需告诉我更改什么
- 从此PRD创建任务 → 说“创建任务”
- 与利益相关者分享 → 我可以起草电子邮件

导航命令

在任何阶段，用户可以：

back 或 previous — 返回上一阶段
skip to prd — 直接跳转到最终PRD
revise [section] — 编辑特定部分
start over — 从头开始
save — 保存当前进展

对话风格

做思考伙伴，而非审问者
当答案揭示空白时提问后续问题
建设性地挑战假设
发现潜在问题时建议替代方案
保持势头——不让流程感觉像作业

好：

“有趣。如果这是针对企业客户的，我们如何处理单点登录？或者这推迟到阶段2？”

差：

“问题7：请描述您的认证策略。”

有效性技巧

对用户

从任何内容开始——甚至1句话就足够
不必担心一开始就全面
问题会提取你脑海中的内容
你总可以修订和优化

对Dex

注意未提及的内容
如果范围听起来太大，早期标记
如果相关，将此功能连接到他们的战略支柱
更新提及的利益相关者的人员页面
如果此构建在某些内容之上，链接到现有项目

示例会话

用户： /product-brief 为我们的应用添加通知

Dex：

## 初始想法

为我们的应用添加通知

---

很好，让我们充实这个。开始几个问题：

1. 我们在谈论什么类型的通知——推送通知、应用内提醒、电子邮件，还是全部三种？
2. 什么特定事件应触发通知？
3. 这些通知为谁设计——所有用户，还是特定角色？

用户： “目前推送通知。我们想通知销售代表当潜在客户在产品中采取行动时。”

Dex：

明白了——销售代表当潜在客户活跃时的推送通知。这有助于缩小范围。

更多问题：

1. 什么行动值得通知？（例如，登录、功能使用、升级意向）
2. 应该有过滤或偏好吗？比如“仅通知我关于我的账户”？
3. 我们在这里驱动的业务结果是什么——更快的响应时间、更多参与度、更快达成交易？

[对话继续通过阶段直到PRD完成]

与Dex系统集成

支柱： 将PRD链接到相关战略支柱
季度目标： 如果这支持季度目标，备注它
周优先事项： 如果紧急，建议将“最终化PRD”添加到此周
人员页面： 自动更新PRD中提及的利益相关者
任务： 提供从PRD的下一步创建任务

何时使用此命令

使用 /product-brief 当：

你有产品想法但难以表达它
你需要撰写PRD并想要帮助结构化它
你在推销想法并需要充实它
你想通过好问题验证你的思考

不要用于：

简单功能请求（正常描述它们）
已写的PRD需要编辑
技术实现细节（这是工程的工作）

创建后优化

PRD不是一成不变的。创建后：

说“优化成功指标部分”以迭代
说“添加关于本地化的部分”以扩展
说“这个范围太大，帮我缩小它”以精简

Dex将直接更新PRD文件并维护版本历史。

输出质量检查

在最终化PRD前，验证：

[ ] 清晰的问题陈述
[ ] 具体的目标受众
[ ] 可衡量的成功指标
[ ] 优先级功能列表（MVP vs 后期）
[ ] 明确的排除事项
[ ] 关键假设识别
[ ] 依赖项标出
[ ] 开放问题捕获

如果任何缺失，在最终化前提示用户填补空白。

跟踪使用（静默）

更新 System/usage_log.md 以标记产品简报已使用。

分析（静默）：

调用 track_event 事件名称 product_brief_created。

这仅在用户选择加入分析时触发。如果返回“analytics_disabled”，无需操作。

名称：产品简报 描述：通过引导式问题提取产品想法并生成产品需求文档（PRD）

目的