---
name: create-prd
description: 根据用户提供的业务上下文，生成结构化的 B端 PRD 文档（含初始内容）。当用户要求创建、撰写、生成 PRD、需求文档、产品方案、系统设计文档时自动触发，即使用户只说"帮我写个 PRD/方案/需求文档"。
---

# create-prd

根据用户提供的业务上下文和需求背景，生成结构化的、带有初始内容的 B端 PRD 文档。

支持显式调用（如 `/create-prd`）和自动触发（当用户明确要求创建、撰写 PRD、需求文档、产品方案或企业系统设计时）。

## 输入

- 用户提供的业务上下文和需求背景（自由文本、会议纪要、简要描述等均可）
- 或通过 `$ARGUMENTS` 传入的文件路径

如有参数传入，优先作为输入源：

$ARGUMENTS

## 生成流程

严格按以下顺序执行，不可跳过或调换步骤。

### 阶段 0：理解上下文与产品定型

1. 完整阅读并理解用户提供的所有业务上下文。
2. 从用户描述中推断：
   - **商业属性**：商业化产品 or 企业自研系统
   - **功能类型**：业务型管理软件 / 工具型软件 / 交易型平台 / 基础服务型
3. 用一句话向用户呈现推断结果，请求确认：

> 根据你的描述，这是一个【{商业属性} × {功能类型}】产品{，简要理由}。我会据此调整 PRD 各章节的侧重点。如有不对请纠正。

4. 等待用户确认后再继续。
5. 确认后，加载定型参考文件以确定各章节的适配规则：

[产品定型与章节适配](references/appendices/create-prd-appendix-typing.md)

### 阶段 1：前置章节（1-9章）

按顺序生成第1至第9章。每完成一章，**立即输出**该章内容，不要等所有章节完成后再一起输出。

每章加载对应的生成指引：

1. [第1章 项目背景](references/chapters/create-prd-ch01-background.md)
2. [第2章 需求基本情况](references/chapters/create-prd-ch02-basic.md)
3. [第3章 商业分析](references/chapters/create-prd-ch03-commercial.md)
4. [第4章 项目收益目标](references/chapters/create-prd-ch04-goals.md)
5. [第5章 项目方案概述](references/chapters/create-prd-ch05-overview.md)
6. [第6章 项目范围](references/chapters/create-prd-ch06-scope.md)
7. [第7章 项目风险](references/chapters/create-prd-ch07-risks.md)
8. [第8-9章 术语与参考文献](references/chapters/create-prd-ch08-09-terms.md)

### 阶段 2：核心功能需求（第10章）

这是 PRD 中最大、最核心的章节。加载生成指引：

9. [第10章 功能需求](references/chapters/create-prd-ch10-functions.md)

按子章节分段生成：
- 10.1 产品框架概述（系统框架图、数据模型图、业务流程图、状态机图、功能清单）
- 10.2 产品需求详解（逐模块：流程图 → 页面交互 → 业务规则）
- 10.3 异常情况处理方案

### 阶段 3：后置章节（11-14章）

10. [第11章 数据埋点](references/chapters/create-prd-ch11-tracking.md)
11. [第12章 角色和权限](references/chapters/create-prd-ch12-permissions.md)
12. [第13章 运营计划](references/chapters/create-prd-ch13-operations.md)
13. [第14章 待决事项](references/chapters/create-prd-ch14-tbd.md)

### 阶段 4：自检与缺口分析

所有章节生成完毕后，执行轻量自检：

14. [自检与待完善清单](references/appendices/create-prd-appendix-selfcheck.md)

## 输出规范

### 文档格式

以单个 Markdown 文档输出 PRD，结构如下：

```md
# {产品/项目名称} PRD

| PRD 审核人 | {待填写} |
| --- | --- |
| 重要性 | {高/中/低} |
| 紧迫性 | {高/中/低} |
| 需求方 | {从上下文推断或标注待填写} |
| PRD 编写人 | {用户姓名或待填写} |
| PRD 提交日期 | {当前日期} |

## PRD 修改记录

| 变更时间 | 变更内容 | 变更提出部门与理由 | 修改人 | 审核人 | 版本号 |
| --- | --- | --- | --- | --- | --- |
| {当前日期} | 初始版本 | — | {编写人} | {待填写} | v1.0 |

---

## 1、项目背景
...（各章节内容）

## 14、待决事项
...

---

## 附：待完善清单
...
```

### 内容生成规则

1. **有信息则生成实质内容**：根据用户提供的上下文，尽可能生成具体、有实质内容的初稿。
2. **信息不足则标注 `[TODO]`**：对于用户未提供足够信息的部分，用 `[TODO: 具体需要补充什么]` 标注，而不是编造内容。
3. **区分产品类型**：商业化产品与企业自研系统的内容侧重点不同，严格按照产品定型结果调整。
4. **理论框架外显**：在关键章节中，用简短提示说明所使用的方法论框架，帮助用户理解设计依据。
5. **结构化优先**：表格、列表、Mermaid 图表优先于大段叙述。
6. **图表使用 Mermaid**：架构图、流程图、状态机、ER 模型等全部使用 Mermaid 代码块生成，不使用 ASCII 伪图。

### 图表生成规则

第10章产品框架概述中，以下图表**必须使用 Mermaid 语法**：

| 图表类型 | Mermaid 语法 | 必须包含 |
| --- | --- | --- |
| 应用架构图 | `graph TB` + `subgraph` 分层 | 用户层、接入层、业务服务层、数据层、外部系统 |
| ER 数据模型 | `erDiagram` | 所有核心实体+关系+关键属性（PK/FK/状态） |
| 业务流程图 | `flowchart TD` | 主流程+关键分支+异常路径，关键节点着色 |
| 状态机图 | `stateDiagram-v2` | 正常+异常路径，附 note 说明约束 |

**注意事项：**
- Mermaid 图后面附对应的明细表格作为补充说明（如状态机图+状态转换表）
- 图表内节点文字用 `<br/>` 换行，保持简洁
- 具体模板和示例见第10章生成指引文件

### 逐章输出规则

- 每完成一章立即输出，不要等所有章节完成后再一起输出。
- 每章必须有清晰的章节标题，与 PRD 模板结构一致。
- 结构化数据（字段、权限、规则等）优先使用表格。
- 使用 `> 💡 方法论提示：` 引用块来呈现所应用的理论框架。
- 不确定的内容用 `[TODO]` 标注，并说明需要补充什么信息。

## 工作风格

- 目标是生成一份可用的 PRD 脚手架，加速产品经理的工作，而不是替代其判断。
- 用户上下文充分时，尽量具体和有实质内容；信息不足时，坦诚标注缺口。
- 保持专业的 PRD 写作风格：精确、结构化、无歧义。
- 根据用户提供的上下文丰富度调整深度——一段话的上下文生成轻量 PRD，详细上下文生成丰富 PRD。
- 如果用户提供的上下文非常有限，生成结构框架并附带指引说明，主动询问哪些补充信息有助于充实关键章节。