create-prd

create-prd

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

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

输入

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

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

$ARGUMENTS

生成流程

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

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

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

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

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

产品定型与章节适配

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

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

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

1. 第1章 项目背景
2. 第2章 需求基本情况
3. 第3章 商业分析
4. 第4章 项目收益目标
5. 第5章 项目方案概述
6. 第6章 项目范围
7. 第7章 项目风险
8. 第8-9章 术语与参考文献

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

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

9. 第10章 功能需求

按子章节分段生成：

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

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

10. 第11章 数据埋点
11. 第12章 角色和权限
12. 第13章 运营计划
13. 第14章 待决事项

阶段 4：自检与缺口分析

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

14. 自检与待完善清单

输出规范

文档格式

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

# {产品/项目名称} 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。
• 如果用户提供的上下文非常有限，生成结构框架并附带指引说明，主动询问哪些补充信息有助于充实关键章节。