---
name: pd
description: "通过对话式交互生成产品需求文档（PRD）。创建包含用户故事、质量门禁和验收标准的结构化 PRD。当用户希望创建 PRD、规划功能、编写需求、写规格说明，或提到「pd」「产品设计」「需求」「用户故事」时使用。"
license: MIT
---

# PD - 产品需求文档生成器

创建面向 AI 智能体执行而优化的结构化产品需求文档。

---

## 任务说明

1. 接收用户的功能描述
2. 提出 3～5 个关键澄清问题（带字母选项），每次一组
3. **务必询问质量门禁**（须通过哪些命令）
4. 每次回答后，如需要可继续追问（自适应探索）
5. 在上下文足够时生成结构化 PRD
6. 用 `[PRD]...[/PRD]` 标记包裹 PRD 输出，便于解析

**重要：** 不要开始实现，只生成 PRD。

---

## 步骤 1：澄清问题（迭代进行）

每次只问一组问题。每次回答应影响下一组问题。关注：

- **问题/目标**：解决什么问题？
- **核心功能**：关键行为有哪些？
- **范围/边界**：不应包含哪些内容？
- **成功标准**：如何判断完成？
- **集成方式**：与现有功能如何配合？
- **质量门禁**：每个用户故事须通过哪些命令？（必问）

### 问题格式示例：

```
1. 该功能的主要目标是什么？
 A. 改善用户入门体验
 B. 提高用户留存
 C. 降低支持负担
 D. 其他：[请说明]

2. 目标用户是谁？
 A. 仅新用户
 B. 仅现有用户
 C. 所有用户
 D. 仅管理员
```

这样用户可以用「1A, 2C」快速回答。

### 质量门禁问题（必问）

务必询问质量门禁——它们因项目而异：

```
每个用户故事须通过哪些质量命令？
 A. pnpm typecheck && pnpm lint
 B. npm run typecheck && npm run lint
 C. bun run typecheck && bun run lint
 D. 其他：[请说明你的命令]

对于 UI 故事，是否需要包含浏览器验证？
 A. 是，用 dev-browser 技能做可视化验证
 B. 否，自动化测试即可
```

### 自适应提问

每次回答后，决定：
- 继续追问（若答案显示复杂度）
- 问新方面（若当前已清晰）
- 生成 PRD（若上下文已足够）

通常需要 2～4 轮问题。

---

## 步骤 2：PRD 结构

按以下章节生成 PRD：

### 1. 引言/概述
简要描述功能及其解决的问题。

### 2. 目标
具体、可衡量的目标（列表）。

### 3. 质量门禁
**关键：** 列出每个用户故事必须通过的命令。

```markdown
## 质量门禁

以下命令对每个用户故事必须通过：
- `pnpm typecheck` - 类型检查
- `pnpm lint` - 代码规范

对 UI 故事，还需包含：
- 使用 dev-browser 技能在浏览器中验证
```

该章节会被转换工具提取，并附加到每个故事的验收标准中。

### 4. 用户故事
每个故事需包含：
- **标题**：简短描述性名称
- **描述**：「作为 [用户]，我希望 [功能]，以便 [收益]」
- **验收标准**：可验证的「完成」检查清单

每个故事应足够小，能在一次聚焦的 AI 智能体会话中完成。

**格式：**
```markdown
### US-001: [标题]
**描述：** 作为 [用户]，我希望 [功能]，以便 [收益]。

**验收标准：**
- [ ] 具体可验证的标准
- [ ] 另一条标准
```

**说明：** 不要在单个故事的验收标准里写质量门禁命令——它们在「质量门禁」章节统一定义，转换时自动应用到各故事。

**重要：**
- 验收标准必须可验证，不能模糊
- 「工作正常」不好
- 「删除前按钮显示确认对话框」好
- 每个故事应可独立完成

### 5. 功能需求
按编号列出具体功能：
- 「FR-1：系统必须允许用户……」
- 「FR-2：当用户点击 X 时，系统必须……」

表述明确、无歧义。

### 6. 非目标（不在范围内）
本功能**不**包含的内容。对控制范围很关键。

### 7. 技术考量（可选）
- 已知约束或依赖
- 与现有系统的集成点
- 性能要求

### 8. 成功指标
如何衡量成功？

### 9. 待解决问题
剩余问题或需进一步澄清的部分。

---

## 面向 AI 智能体的写作

PRD 将由 AI 编程智能体执行，因此：

- 表述明确、无歧义
- 用户故事要小（一次会话可完成）
- 验收标准尽量可机器验证
- 若已知，写出具体文件路径
- 引用项目现有代码模式

---

## 输出格式

**关键：** 最终 PRD 用以下标记包裹，便于解析：

```
[PRD]
# PRD: 功能名称

## 概述
...

## 质量门禁
...

## 用户故事
...
[/PRD]
```

**文件命名：** 保存为 `./tasks/prd-[功能名].md` 或建议合适路径。

---

## 示例对话流程

**用户：** 为添加暗色模式创建一个 PRD

**助手：** 好的，我来帮你做暗色模式的 PRD。先问几个问题：

1. 主要目标是什么？
 A. 减少长时间使用的眼疲劳
 B. 跟随系统主题偏好
 C. 提供视觉自定义
 D. 其他

2. 设置是否需要持久化？
 A. 是，保存到配置文件
 B. 否，仅当前会话
 C. 跟随系统偏好

**用户：** 1A, 2A

**助手：** 好的，再问两个：

3. 哪些组件需要支持暗色模式？
 A. 所有组件
 B. 仅主视图
 C. 主视图 + 设置
 D. 其他

4. 每个故事须通过哪些质量命令？
 A. pnpm typecheck && pnpm lint
 B. npm run typecheck && npm run lint
 C. bun run typecheck
 D. 其他：[请说明]

**用户：** 3A, 4A

**助手：** 可以，正在生成 PRD。

[PRD]
# PRD: 暗色模式

## 概述
添加暗色模式以减轻长时间使用的眼疲劳。功能将覆盖所有组件，并将用户偏好在配置文件中持久化。

## 目标
- 在弱光环境下提供舒适的浏览体验
- 主题偏好跨会话持久化
- 对所有组件应用一致的样式

## 质量门禁

以下命令对每个用户故事必须通过：
- `pnpm typecheck` - 类型检查
- `pnpm lint` - 代码规范

## 用户故事

### US-001: 添加主题配置
**描述：** 作为用户，我希望设置首选主题（亮色/暗色），以便跨会话持久化。

**验收标准：**
- [ ] 在配置 schema 中增加 `theme` 字段
- [ ] 支持取值："light"、"dark"、"system"
- [ ] 默认 "light" 以保持向后兼容

### US-002: 创建暗色主题配色
**描述：** 作为用户，我希望有柔和对比的暗色主题，减轻用眼负担。

**验收标准：**
- [ ] 用灰色调定义暗色配色（非纯黑）
- [ ] 保证足够对比度（WCAG AA）
- [ ] 颜色适用于所有 UI 状态

### US-003: 对所有组件应用主题
**描述：** 作为用户，我希望所有组件遵循我的主题偏好。

**验收标准：**
- [ ] 头部组件使用主题色
- [ ] 主视图使用主题色
- [ ] 设置面板使用主题色
- [ ] 弹窗使用主题色

### US-004: 在设置中添加主题切换
**描述：** 作为用户，我希望在设置中切换主题。

**验收标准：**
- [ ] 设置视图中可见主题选项
- [ ] 修改立即生效，无需重启
- [ ] 修改持久化到配置文件

## 功能需求
- FR-1：主题设置须能从配置文件读取
- FR-2：启动时须应用主题
- FR-3：主题变更须立即生效
- FR-4：所有文本在两种主题下均须保持可读

## 非目标
- 系统主题自动检测（后续增强）
- 除亮/暗外的自定义配色
- 按组件的主题覆盖

## 技术考量
- 若有现成主题能力则复用
- 考虑为 React 组件建 ThemeContext
- 主题切换时尽量减少重渲染

## 成功指标
- 所有组件在暗色模式下正确渲染
- 无无障碍对比度问题
- 主题跨会话持久化

## 待解决问题
- v2 是否应自动检测系统主题偏好？
[/PRD]

---

## 检查清单

输出 PRD 前确认：

- [ ] 已提出带字母选项的澄清问题
- [ ] 已询问质量门禁（必做）
- [ ] 需要时已做追问
- [ ] 已包含「质量门禁」章节及项目专属命令
- [ ] 用户故事足够小且可独立完成
- [ ] 用户故事中未包含质量门禁命令（见质量门禁章节）
- [ ] 功能需求已编号且无歧义
- [ ] 非目标章节界定了清晰范围
- [ ] PRD 已用 `[PRD]...[/PRD]` 包裹

---

## 异常处理

若用户回答不清或不完整：
- 礼貌请求澄清
- 提出换一种问法
- 给出有效回答示例

若用户希望跳过问题：
- 允许跳过可选问题
- 质量门禁信息始终必填
- 在 PRD 中注明所做假设