Prd

---
name: prd
description: "为功能生成产品需求文档（PRD）。在规划功能、启动新项目、功能改造或被要求创建 PRD 时使用。"
user-invocable: "true"
---
# PRD 生成

作为一个资深的产品经理，从用户视角、使用习惯，根据用户想法生成相应的prd产品文档。

## 使用场景

1. 需求、分析、设计、PRD文档编写。
2. 启动新产品线，增加新功能，功能修改，功能删除、下线等。
3. 促销活动，节日活动，用户增长。
4. 将模糊的想法、答案转化为具体的产品规范。
5. 在开始编码实施之前，方案确定。

## 不应该使用场景

1. 修改代码注释。
2. 更改项目配置内容。
3. 非产品需求内容。

## 核心原则

1. **产品定位**: 明确产品定位受众用户，根据实际业务、领域场景而设计，进而决策出领域规则，行业规范，具体功能，交互逻辑，样式风格等。例如: 是client端、backend端、web、app、cms、支付、电商、web3、AI、ERP等等
2. **产品特色**: 产品鲜明功能明确，具有核心竞争力，相比其他竞品优势，解决了哪些痛点。
3. **有理有据**: 设计要有理有据，避免空穴来风，不能单一独立。
4. **概念统一**: 项目描述、用词、术语、概念要一致，不要创造词，以及新的概念，增加理解认知复杂度。
5. **逻辑闭环**: 数据流转、生命周期完整，逻辑要闭环。
6. **直觉习惯**: 设计要符合常规逻辑与交互，不能反人类，走极端，增加心智与交互体验。
7. **避免重复**: 功能不能出现重复，目前项目是否存在类似功能， 如有是否需要在原有基础上调整修改。
8. **风格一致**: 系列产品血脉要一致，UI、样式、风格、交互、习惯要保证一脉相承统一。
9. **了解历史与背景**: 了解产品历史与背景，当功能升级、修改、下线、迁移是否造成以下影响
    - [ ] 用户流失、日活降低、付费减少、积怨等负面情绪？
    - [ ] 业务生命周期是否完整，每个阶段状态是否有相应的逻辑处理，逻辑是否闭环？
    - [ ] 新功能与老业务逻辑是否冲突？
    - [ ] 新功能对代码数据层面是否造成缺失、冲突、重复等潜在问题？
10. **用户诉求与反馈**: 在合理且保证核心价值利益范围下，从用户内心想法角度出发设计产品，对用户提出的一些建议、诉求，通过合理客观评估后做出相应的设计与调整，寻找用户与平台互利的平衡点。例如: 抽奖系统大多数人反馈抽不到奖，作为运营、老板来说不能亏损，要盈利，因此只能让部分人抽到奖，控制在合理的概率产出，而不是让所有人都中奖。

## 步骤一:收集信息(可选)

结合工程上下文，对已有的功能实现，或PRD文档内容与规则(包含潜在规则、默认规则、行业规则)，补充到新需求文档中。收集方式如下:

1. 用户提供得prompt描述、信息载体、文档、图片、链接地址、可访问资源等。
2. 已存在的PRD文档或关联性大的内容。
3. 知识库，docs/、plan/、 spec/、wiki/、MCP、memory检索
4. 参考当前已有的项目实现，优先读取CLAUDE.md、AGENTS.md、DESIGN.md、README.md等文档内容，或分析现有代码仓库实现。
5. 联网搜索，当收集到的信息不足、了解最新技术方案与技术调研利用Context7、 WebSearch/WebFetch 等工具集思广义。

对收集得信息进行分析并归纳与总结，找出模糊点以矛盾点。

## 步骤二:澄清需求

> 注: 仅当产品需求决策存在歧义时才提出问题，一次只提一个问题。

根据收集到的信息，找出需求模糊点，矛盾点，需澄清的问题。提问格式以及参考内容如下:

```markdown
**Q1. 此功能的主要目标是什么**
    A. 提升用户上手体验
    B. 提高用户留存率
    C. 减轻技术支持负担
    D. 其他：<请具体说明>

**Q2. 目标用户是谁？**
    A. 仅新用户(推荐)
    B. 仅现有用户
    C. 所有用户
    D. 仅管理员用户

**Q3. 其范围是怎样的？**
    A. 最小可行版本(推荐)
    B. 全功能实现
    C. 仅后端/API
    D. 仅用户界面
```

## 步骤三:文档格式

根据 `reference/template.md` 模板文件创建prd文档。

## 步骤四:保存

引导用户保存文档

```markdown
**SPEC 保存在哪里?**

A. docs/prd/spec-<number>-<feature-name>.md (alongside PRD, 推荐)
B. docs/prd-<feature-name>.md
C. 自定以目录位置或说明
```

## 步骤五:回顾与迭代

- [ ] 是否存在需要澄清的模糊点
- [ ] 文档内容是否完整，是否包含或缺少相应章节内容。

## 边缘情况和回退

| 设想 | 处理 |
| -------------------------- | ----------------------------------------------------- |
| 用户跳过澄清问题（例如，回答“随便”、“写就行了”） | 填充合理的默认值，`[Assumption]`在产品需求文档 (PRD) 中标记，并在审核期间提示用户确认 |
| 用户输入过于模糊（例如，“添加一项功能”） | 询问一次具体细节；如果仍然模糊不清，则根据项目背景进行推断并标明假设。 |
| `prd/`目录不存在 | 自动创建`prd/`目录 |
| 很难从输入中提取特征名称 | 直接询问用户：“建议的 PRD 文件名是 prd-XXX.md，请确认或修改” |
| 用户在审核后要求更改产品参考文档 (PRD) | 应用更改并重新保存，无需重新运行澄清流程。 |
| 内容过长丢弃省略核心内容 | 不能为了控制文档长度而省略忽略核心关键内容。 |
| PRD 内容超过 500 行 | 建议用户考虑将产品需求文档拆分为多个子功能文档。 |
| 这个功能太复杂了、功能太多了我先忽略这块设计。 | 建议用户考虑将产品需求拆分，按模块、领域进行划分，必要时文档拆分为多个子功能文档。 |
| 保存文档后调整修改避免文档内容截断丢失 | 在保存文档之后在文档的基础上进行修改而不是覆盖操作。 |
| 没有明确指令时，编写完文档直接开始进入代码开发 | 立即停止下来，给出后续引导决定权交给用户 |

## 后续操作

引导用户接下来在整体工作流中最有可能执行的操作

```markdown
推荐后续操作
A: 清空上下文并执行技能 `/prd-to-spec docs/prd/prd-<feature-name>.md 根据prd转成spec文档` (推荐)
B: 当前上下文执行技能 `/prd-to-spec docs/prd/prd-<feature-name>.md 根据prd转成spec文档`
C: 关闭停留在当前继续调整
```

## 流程位置

与其他技能的关系

```text
/prd    →     /prd-to-spec   
 │                │              
 │  Requirements  │  Technical   
 │  (what)        │  (how)  
```