61 lines
3.8 KiB
Plaintext
61 lines
3.8 KiB
Plaintext
---
|
||
description: "全局规则"
|
||
globs: ["**/*"]
|
||
alwaysApply: true
|
||
---
|
||
# 规则：生成产品需求文档 (PRD)
|
||
|
||
## 目标 (Goal)
|
||
|
||
指导 AI 助手基于用户的初始提示创建详细的产品需求文档 (PRD)（Markdown 格式）。PRD 应清晰、可操作，并适合初级开发人员理解和实施该功能。
|
||
|
||
## 流程 (Process)
|
||
|
||
1. **接收初始提示：** 用户提供新功能或功能的简要描述或请求。
|
||
2. **提出澄清性问题：** 在编写 PRD *之前*，AI *必须*提出澄清性问题以收集足够的细节。目标是理解功能的“是什么”和“为什么”，而不是“如何做”（开发人员将负责解决）。务必以字母/数字列表的形式提供选项，以便我可以用选择轻松回复。
|
||
3. **生成 PRD：** 基于初始提示和用户对澄清性问题的回答，使用下面概述的结构生成 PRD。
|
||
4. **保存 PRD：** 将生成的文档保存为 `/tasks` 目录中的 `prd-[功能名称].md`。
|
||
|
||
## 澄清性问题 (示例) (Clarifying Questions (Examples))
|
||
|
||
AI 应根据提示调整其问题，但以下是一些常见的探索领域：
|
||
|
||
* **问题/目标：** “这个功能为用户解决了什么问题？” 或 “我们希望通过这个功能实现的主要目标是什么？”
|
||
* **目标用户：** “这个功能的主要用户是谁？”
|
||
* **核心功能：** “您能描述用户应该能够使用此功能执行的关键操作吗？”
|
||
* **用户故事：** “您能提供一些用户故事吗？（例如：作为 [用户类型]，我希望 [执行操作]，以便 [获得收益]。）”
|
||
* **验收标准：** “我们如何知道此功能已成功实施？关键的成功标准是什么？”
|
||
* **范围/边界：** “有没有此功能*不应该*做的特定事情（非目标）？”
|
||
* **数据需求：** “此功能需要显示或操作什么类型的数据？”
|
||
* **设计/UI：** “是否有现有的设计稿或 UI 指南需要遵循？” 或 “您能描述期望的外观和感觉吗？”
|
||
* **边界情况：** “是否有任何潜在的边界情况或错误条件我们需要考虑？”
|
||
|
||
## PRD 结构 (PRD Structure)
|
||
|
||
生成的 PRD 应包含以下部分：
|
||
|
||
1. **引言/概述：** 简要描述该功能及其解决的问题。陈述目标。
|
||
2. **目标：** 列出此功能的具体、可衡量的目标。
|
||
3. **用户故事：** 详细描述描述功能使用和收益的用户叙事。
|
||
4. **功能需求：** 列出该功能必须具备的具体功能。使用清晰、简洁的语言（例如：“系统必须允许用户上传个人资料图片。”）。对这些需求进行编号。
|
||
5. **非目标（范围之外）：** 明确说明此功能*不会*包含的内容，以管理范围。
|
||
6. **设计考虑（可选）：** 如果适用，链接到设计稿，描述 UI/UX 要求，或提及相关组件/样式。
|
||
7. **技术考虑（可选）：** 提及任何已知的技术限制、依赖项或建议（例如：“应与现有的 Auth 模块集成”）。
|
||
8. **成功指标：** 如何衡量此功能的成功？（例如：“用户参与度提高 10%”、“减少与 X 相关的支持工单”）。
|
||
9. **待解决问题：** 列出任何剩余问题或需要进一步澄清的领域。
|
||
|
||
## 目标受众 (Target Audience)
|
||
|
||
假设 PRD 的主要读者是**初级开发人员**。因此，需求应明确、无歧义，并尽可能避免行话。提供足够的细节供他们理解功能的目的和核心逻辑。
|
||
|
||
## 输出 (Output)
|
||
|
||
* **格式：** Markdown (`.md`)
|
||
* **位置：** `/tasks/`
|
||
* **文件名：** `prd-[功能名称].md`
|
||
|
||
## 最终指令 (Final instructions)
|
||
|
||
1. 不要开始实施 PRD。
|
||
2. 务必向用户提出澄清性问题。
|
||
3. 获取用户对澄清性问题的答案，并据此改进 PRD。 |