| name | create-prd |
| description | 根据用户提供的业务上下文,生成结构化的 B端 PRD 文档(含初始内容)。当用户要求创建、撰写、生成 PRD、需求文档、产品方案、系统设计文档时自动触发,即使用户只说"帮我写个 PRD/方案/需求文档"。 |
create-prd
根据用户提供的业务上下文和需求背景,生成结构化的、带有初始内容的 B端 PRD 文档。
支持显式调用(如 /create-prd)和自动触发(当用户明确要求创建、撰写 PRD、需求文档、产品方案或企业系统设计时)。
输入
- 用户提供的业务上下文和需求背景(自由文本、会议纪要、简要描述等均可)
- 或通过
$ARGUMENTS 传入的文件路径
如有参数传入,优先作为输入源:
$ARGUMENTS
生成流程
严格按以下顺序执行,不可跳过或调换步骤。
阶段 0:理解上下文与产品定型
- 完整阅读并理解用户提供的所有业务上下文。
- 从用户描述中推断:
- 商业属性:商业化产品 or 企业自研系统
- 功能类型:业务型管理软件 / 工具型软件 / 交易型平台 / 基础服务型
- 用一句话向用户呈现推断结果,请求确认:
根据你的描述,这是一个【{商业属性} × {功能类型}】产品{,简要理由}。我会据此调整 PRD 各章节的侧重点。如有不对请纠正。
- 等待用户确认后再继续。
- 确认后,加载定型参考文件以确定各章节的适配规则:
产品定型与章节适配
阶段 1:前置章节(1-9章)
按顺序生成第1至第9章。每完成一章,立即输出该章内容,不要等所有章节完成后再一起输出。
每章加载对应的生成指引:
- 第1章 项目背景
- 第2章 需求基本情况
- 第3章 商业分析
- 第4章 项目收益目标
- 第5章 项目方案概述
- 第6章 项目范围
- 第7章 项目风险
- 第8-9章 术语与参考文献
阶段 2:核心功能需求(第10章)
这是 PRD 中最大、最核心的章节。加载生成指引:
- 第10章 功能需求
按子章节分段生成:
- 10.1 产品框架概述(系统框架图、数据模型图、业务流程图、状态机图、功能清单)
- 10.2 产品需求详解(逐模块:流程图 → 页面交互 → 业务规则)
- 10.3 异常情况处理方案
阶段 3:后置章节(11-14章)
- 第11章 数据埋点
- 第12章 角色和权限
- 第13章 运营计划
- 第14章 待决事项
阶段 4:自检与缺口分析
所有章节生成完毕后,执行轻量自检:
- 自检与待完善清单
输出规范
文档格式
以单个 Markdown 文档输出 PRD,结构如下:
# {产品/项目名称} PRD
| PRD 审核人 | {待填写} |
| --- | --- |
| 重要性 | {高/中/低} |
| 紧迫性 | {高/中/低} |
| 需求方 | {从上下文推断或标注待填写} |
| PRD 编写人 | {用户姓名或待填写} |
| PRD 提交日期 | {当前日期} |
## PRD 修改记录
| 变更时间 | 变更内容 | 变更提出部门与理由 | 修改人 | 审核人 | 版本号 |
| --- | --- | --- | --- | --- | --- |
| {当前日期} | 初始版本 | — | {编写人} | {待填写} | v1.0 |
---
## 1、项目背景
...(各章节内容)
## 14、待决事项
...
---
## 附:待完善清单
...
内容生成规则
- 有信息则生成实质内容:根据用户提供的上下文,尽可能生成具体、有实质内容的初稿。
- 信息不足则标注
[TODO]:对于用户未提供足够信息的部分,用 [TODO: 具体需要补充什么] 标注,而不是编造内容。
- 区分产品类型:商业化产品与企业自研系统的内容侧重点不同,严格按照产品定型结果调整。
- 理论框架外显:在关键章节中,用简短提示说明所使用的方法论框架,帮助用户理解设计依据。
- 结构化优先:表格、列表、Mermaid 图表优先于大段叙述。
- 图表使用 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。
- 如果用户提供的上下文非常有限,生成结构框架并附带指引说明,主动询问哪些补充信息有助于充实关键章节。