- name
- pd
- description
- 通过对话式交互生成产品需求文档（PRD）。创建包含用户故事、质量门禁和验收标准的结构化 PRD。当用户希望创建 PRD、规划功能、编写需求、写规格说明，或提到「pd」「产品设计」「需求」「用户故事」时使用。
- license
- MIT
PD - 产品需求文档生成器
创建面向 AI 智能体执行而优化的结构化产品需求文档。
任务说明
- 接收用户的功能描述
- 提出 3～5 个关键澄清问题（带字母选项），每次一组
- 务必询问质量门禁（须通过哪些命令）
- 每次回答后，如需要可继续追问（自适应探索）
- 在上下文足够时生成结构化 PRD
- 用
[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. 质量门禁
关键： 列出每个用户故事必须通过的命令。
## 质量门禁
以下命令对每个用户故事必须通过：
- `pnpm typecheck` - 类型检查
- `pnpm lint` - 代码规范
对 UI 故事，还需包含：
- 使用 dev-browser 技能在浏览器中验证该章节会被转换工具提取，并附加到每个故事的验收标准中。
4. 用户故事
每个故事需包含：
- 标题：简短描述性名称
- 描述：「作为 [用户]，我希望 [功能]，以便 [收益]」
- 验收标准：可验证的「完成」检查清单
每个故事应足够小，能在一次聚焦的 AI 智能体会话中完成。
格式：
### US-001: [标题]
**描述：** 作为 [用户]，我希望 [功能]，以便 [收益]。
**验收标准：**
- [ ] 具体可验证的标准
- [ ] 另一条标准说明： 不要在单个故事的验收标准里写质量门禁命令——它们在「质量门禁」章节统一定义，转换时自动应用到各故事。
重要：
- 验收标准必须可验证，不能模糊
- 「工作正常」不好
- 「删除前按钮显示确认对话框」好
- 每个故事应可独立完成
5. 功能需求
按编号列出具体功能：
- 「FR-1：系统必须允许用户……」
- 「FR-2：当用户点击 X 时，系统必须……」
表述明确、无歧义。
6. 非目标（不在范围内）
本功能不包含的内容。对控制范围很关键。
7. 技术考量（可选）
- 已知约束或依赖
- 与现有系统的集成点
- 性能要求
8. 成功指标
如何衡量成功？
9. 待解决问题
剩余问题或需进一步澄清的部分。
面向 AI 智能体的写作
PRD 将由 AI 编程智能体执行，因此：
- 表述明确、无歧义
- 用户故事要小（一次会话可完成）
- 验收标准尽量可机器验证
- 若已知，写出具体文件路径
- 引用项目现有代码模式
输出格式
关键： 最终 PRD 用以下标记包裹，便于解析：
[PRD]
# PRD: 功能名称
## 概述
...
## 质量门禁
...
## 用户故事
...
[/PRD]文件命名： 保存为 ./tasks/prd-[功能名].md 或建议合适路径。
示例对话流程
用户： 为添加暗色模式创建一个 PRD
助手： 好的，我来帮你做暗色模式的 PRD。先问几个问题：
- 主要目标是什么？
A. 减少长时间使用的眼疲劳 B. 跟随系统主题偏好 C. 提供视觉自定义 D. 其他
- 设置是否需要持久化？
A. 是，保存到配置文件 B. 否，仅当前会话 C. 跟随系统偏好
用户： 1A, 2A
助手： 好的，再问两个：
- 哪些组件需要支持暗色模式？
A. 所有组件 B. 仅主视图 C. 主视图 + 设置 D. 其他
- 每个故事须通过哪些质量命令？
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 中注明所做假设