create-prd

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

本 skill 默认面向 B 端系统，并可按业务领域加载对应的领域 Provider（references/providers/<domain>/），生成该领域的功能模块级 PRD。它不限定产品形态，既可用于商业化 SaaS，也可用于企业自研系统、私有化交付和二开项目。

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

输入

• 用户提供的业务上下文和需求背景（自由文本、会议纪要、简要描述等均可）
• 或调用方给出的文件路径
• 范围内经用户逐条确认的验收标准清单（名称、路径与版本；引用使用清单名称加编号）
• 最终已确认需求范围及其所有关联模型/PRD，清单与台账位置；跨模块归集位置由调用方明确，文件数不决定范围数
• 当前项目中已有的上下文材料（如已存在的 PRD、Domain Model、解决方案文档、模块文档、术语表、权限说明、数据模型、交互原型等）

调用方随调用给出的参数，优先作为输入源。

同一范围可关联多份模型/PRD；引用唯一清单，不按每份PRD另造标准。范围变化先交用户确认并回改上游，受影响标准重新确认后才细化。模块入口只索引范围、模型/PRD、标准清单、台账及进度。PRD不复制交付台账，不把标准“已确认”写成“已实现”或用户已验收。

生成流程

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

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

1. 完整阅读并理解用户提供的所有业务上下文。生成新PRD或补强需求语义前，先核对已确认Domain Model和验收标准清单；缺模型先回建模，清单缺失、相关条目待确认或与模型冲突时，停下回到验收标准阶段补齐并请用户确认，不能在PRD内从零定义完成标准。
2. 如果在项目工作区内生成 PRD，先检索并阅读与当前模块相关的已有文档，尤其是：
   • 解决方案或源材料文档
   • 当前模块的 Domain Model / 数据模型
   • 相邻模块 PRD 或已实现文档
   • 术语、权限、状态机、接口、数据流相关文档
3. 从用户描述和项目上下文中推断：
   • 商业属性：商业化产品 or 企业自研系统
   • 功能类型：业务型管理软件 / 工具型软件 / 交易型平台 / 基础服务型
   • 领域补充规则：调用方指定的领域及是否已加载其 Provider；未指定时记"未指定"（不从上下文判定，见第 7 步）
   • 文档范围：0-1 系统级规划 / 功能模块级需求 / 子功能详细需求 / 迭代需求
4. 用一句话向用户呈现推断结果，请求确认：

根据你的描述，这是一个【{商业属性} × {功能类型}】需求，领域补充规则：{调用方指定的领域，或"未指定"}，文档范围为【{文档范围}】{，简要理由}。我会据此调整 PRD 各章节的侧重点。如有不对请纠正。

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

产品定型与章节适配

7. 领域由调用方显式给出，不从上下文里猜。 调用时指定了领域，且 references/providers/<domain>/ 下有对应 Provider，就加载该目录下的领域附录；没有指定就按通用框架生成，并在产出中声明"未加载领域补充规则"。本文件不写死任何一个领域的路径——加一个领域是加一个 Provider 目录，不改本文件。

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

按顺序生成第1至第9章。默认每完成一章立即输出；如果用户要求落盘到文件或生成 PRD 包，则先在文件中完整生成，再输出摘要和自检结论。

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

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

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

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

9. 第10章 功能需求

按子章节分段生成：

• 10.1 产品框架概述（架构图 SVG——按文档范围选类：系统级=系统框架图+应用架构图，模块级=功能模块架构图；数据模型引用或局部数据模型图、业务流程图 SVG、状态机图、功能清单）
• 10.2 产品需求详解（逐模块：流程图 → 页面交互 → 业务规则）
• 10.3 异常情况处理方案

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

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

阶段 4：自检与缺口分析

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

14. 自检与待完善清单

补强模式（对已有 PRD 做增量补充）

当用户提供一份已有 PRD 并要求补充页面交互、字段级规则或其中某几章时，不重新生成整份 PRD，改为增量补强：

1. 完整阅读既有PRD与其依据文档（Domain Model、已确认验收标准清单、Overview、相邻Sub PRD），确定范围；补强涉及的新业务预期未被确认清单覆盖时，先回改上游并确认，再补PRD。
2. 只加载与补强目标相关的章节指引（补页面字段级规则时加载第10章指引，按其"页面交互规则块 A-I"执行）。
3. 建立「页面/弹层 × 规则块」覆盖矩阵：清点 PRD 中出现的每个页面、弹窗、抽屉，对照 A-I 标出已覆盖与缺失。
4. 逐页补齐缺失的规则块，写入既有 PRD 的对应章节；不改动已有内容的口径与编号体系，发现与既有内容冲突时标注"待确认"而非覆盖。
5. 无法从上下文推断、必须由产品经理拍板的具体值（长度上限、默认值、文案等）给出建议值并标注 [TODO: 待确认]。
6. 当本次补强改变 PRD 正文、业务规则或产品语义时，在 PRD 修改记录中新增一行说明范围；仅做展示层维护时遵循下方“PRD 版本记录边界”。随后执行阶段 4 自检。

验收引用与回流

第4.2节引用已确认清单的名称、路径/版本与适用条目，不复制整份主表。第10.2.1.4每行写“清单名称 AC-n”，细化页面前置、操作与断言，不改变来源行的业务预期。发现新标准或冲突时暂停受影响工作，将缺口回到最上游依据：模型错先修模型，再修清单并将受影响行置为待确认，变更记录注明PRD阶段。未获修改授权时只交回缺口；获授权时可以形成清单修订草稿，仍须等用户确认。确认后同步PRD、覆盖清单和测试引用，不能自行批准或仅在PRD内新增一条验收规则绕过清单。 回流清单的文首状态字段用“草稿”，既有行可仍为已确认；“部分已确认”不作文件状态。清单标题可带版本或真实快照定位，不能编造原版本。页面Then每行只核一个可观察结果，多项细化可拆行引用同一标准；无来源的新增业务结果仍须回改上游。

输出规范

文档格式

默认以单个 Markdown 文档输出 PRD。对于复杂业务模块，允许输出 PRD 包：

• Overview PRD：描述模块目标、范围、信息架构、全局状态机、跨模块数据流、子 PRD 索引。
• Sub PRD：描述某个二级菜单或子功能的页面交互、字段、规则、异常、权限、验收标准。

单文档结构如下：

# {产品/项目名称} PRD

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

## PRD 修改记录

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

---

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

## 14. 待决事项
...

---

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

PRD 版本记录边界

• 新增、删除或修改需求范围、业务规则、字段、状态、流程语义、权限、异常处理、验收口径或待决事项时，MUST 新增修改记录并递增版本号。
• 仅修复展示层或文档载体，且不改变任何正文内容或产品语义时，MUST NOT 为该维护动作单独新增 PRD 版本。例如：修正 SVG 连线锚点与排版、修复表格视觉样式、调整不影响信息含义的文档格式。
• 判断依据是语义差异而非改动文件类型：若图表修复改变了节点、分支条件、状态值、字段集合或流程关系，仍属于 PRD 内容变更，必须登记版本。
• 纯维护改动可由 Git 变更记录、提交说明或资产历史追溯，不占用 PRD 业务版本号。

内容生成规则

1. 有信息则生成实质内容：根据用户提供的上下文，尽可能生成具体、有实质内容的初稿。
2. 信息不足则标注 [TODO]：对于用户未提供足够信息的部分，用 [TODO: 具体需要补充什么] 标注，而不是编造内容。
3. 区分产品类型：商业化产品与企业自研系统的内容侧重点不同，严格按照产品定型结果调整。
4. 理论框架外显：在关键章节中，用简短提示说明所使用的方法论框架，帮助用户理解设计依据。
5. 结构化优先：表格、列表、图表优先于大段叙述。
6. 图表载体（三类图无条件按载体归位，不使用 ASCII 伪图；不设"视情况升级"的条件判断，避免同一类图在不同 PRD 里载体不一致）：
   • 架构类图统一使用手绘 SVG 图片——含系统框架图、应用架构图、功能模块架构图三类及 API 结构图。三类架构图场景与内容不同、不可相互替代（系统框架图=系统有哪些业务域/模块；应用架构图=系统如何技术分层；功能模块架构图=单个模块的内部构成与上下游契约），但载体、色带结构范式与视觉样式必须一致；按文档范围选类的规则见第10章 第 10.1.1 节。架构图天然是分层多节点结构，Mermaid 渲染必然出现连线交叉、文字溢出、层级失衡，且无法表达分层色带与分组嵌套。
   • 业务流程图统一使用手绘 SVG 图片（第 10.1.3 节 总览与 第 10.2.x.1 节 节点级），按总-分结构组织。流程图必须让读者复原真实业务流转：泳道按参与方/系统划分、形状区分处理步骤与状态落地点、每条连线标注「动作/接口」+「状态：精确状态值」两行信息、异常与回退路径标注密度与主干一致。只画主干、把环节概括成几个方框的图不合格（详见第10章 第 10.1 节「业务流程图的信息密度要求」）。
   • ER 数据模型与状态机图使用 Mermaid（erDiagram / stateDiagram-v2）——两者是关系/状态语义图，Mermaid 自动布局足够且便于 diff。仅当单图实体或状态数量过大导致渲染明显失真时才改 SVG，并在图注说明改用理由。
   • 规范详见第10章生成指引。
7. 跨模块一致性优先：PRD 中的数据流、状态流、权限和术语必须与已有项目文档保持一致；如发现冲突，标注为“待确认/待修正”，不要私自覆盖既有模块口径。
8. 可自评，不可自我宣告通过：AI 应对生成的 PRD 给出客观的成熟度自评（覆盖度、待完善项、check-prd 自审结果与评分）并如实展示——这是要求，不是禁区。但 PRD 任何位置（含修改记录“理由”列、待决事项结论、自检结论）都不得出现替用户下达“通过/成功”结论的自我背书，例如“PRD 成熟度满足评审要求”“数量合理”“通过 N 维度终审/封板”。审查动作如实描述其性质（如“AI 参考 check-prd skill 进行 N 维度自审”），而非“终审/审计通过”；是否通过、是否进入下一步由用户裁定，审核人字段在用户裁定前保持“待填写”。
9. 审议过程不进 PRD：被否决的方案、已关闭的裁定项，不在 PRD 里保留专门的「已裁定项 / 已关闭项」表格——那是审议记录，归决策档案。PRD 只保留三样：变更记录里一行"本版关闭了什么"、正文里的规范取值与范围边界结论、以及实现与规范有意不一致时的偏离登记（读规范的人必须当场看到，否则会把有意为之的偏离当成缺陷）。判据：删掉这一行，实现者会不会做错？不会就不该留在 PRD。
10. 引用必须就地可理解、可追溯：不要把 BR-009、G-B、规则块字母、节点缩写等内部编码当作正文含义。若当前位置已写出完整规则，删除冗余编码；若跨文档引用确有追溯价值，使用“可理解的规则名称 + 可跳转 Markdown 链接”，并在首次出现时说明编码含义。验收编号、待决事项编号等局部标识只在确有逐项追踪需要时保留，且定义位置必须同时给出完整内容。

11. 过程性编号绝不写进 PRD（含变更记录）：审计发现号、走查观察号、待办清单项号、执行计划的裁定编号——这些编号的定义住在过程性文档里（审计报告、走查记录、执行计划、待办清单），而过程性文档在任务结束后会被清理。PRD 长期存在，于是编号悬空：读者读到它，在任何现存文档里都查不到它指什么。

    判据：这个编号在本 PRD 内能否被解释？不能的话，读者要去哪里查？那个地方会不会消失？

    编号来自	例	处理
    过程性文档（会被清理）	审计发现号、走查观察号、任务待办号、裁定项号	不写。用实质描述代替——"审计 N-02 收口"改成"计划锁定时点冲突收口"，信息量不减反增
    结果性文档（长期存在）	Domain Model 的业务规则号、PRD 内定义的规则号、权限点编码、TBD 登记号	可用，但按上条给出可理解名称 + 可跳转链接，不留裸编码

    变更记录尤其容易中招：它天然记录"这一版因为什么改了什么"，而"因为什么"常常是一个过程性编号。变更记录的职责是让读者知道这一版改了什么，用读者查不到的编号写就没尽到职责。

12. 遇到即修：编辑 PRD 的任何一节时，若该节存在悬空的过程性编号，在同一次变更里改成实质描述。不做全文档批量清理，但也不绕过——存量靠每次编辑顺手收敛。

跨模块所有权迁移与证据唯一性

1. 页面或流程迁移到其它模块后，原 PRD 只保留模块间 contract：输入输出、幂等键、状态/引用回写和失败补偿边界。
2. 原 PRD 删除已迁出页面的字段、按钮、容器和权限细节；页面规格只由新 owner 的 PRD 定义，禁止两个 PRD 同时充当 UI Oracle。
3. 功能清单显式标记本 PRD owner 与外部 owner，避免把外部页面计入本模块实现范围。
4. 业务流程图、状态机图、SVG 和截图必须与当前 owner/contract 一致。需要保留旧图时，解除正文引用并标记为 historical，不得继续作为实现依据。
5. 修改记录保留历史事实；当前正文、引用和验收标准统一指向现行 Oracle。
6. 跨模块强约束必须形成生产者与消费者双向合同。生产者 PRD/Domain Model 定义可供读取的唯一性、状态与快照边界；消费者 PRD 同步落到入口/页面阻断、服务端守卫、异常处理和验收场景。只在上游写“下游应校验”不能视为合同闭合。
7. 当消费者依赖“上游对象 + 时间坐标唯一确定一条记录”时，必须分别定义零条与多条的处理；两者均为数据完整性异常，不得由消费者临时选择、回退默认记录或静默继续。

图表生成规则

第10章产品框架概述中，各图表按以下规定载体生成：

注意事项：

• Mermaid 图（ER / 状态机）后面附对应的明细表格作为补充说明（如状态机图+状态转换表）；SVG 图（架构 / 流程）后面附分层或流程的文字说明
• Mermaid 图内节点文字用 <br/> 换行，保持简洁
• 绘制任何 SVG 前先加载项目的图示规范 spec（宿主契约 host.specMap 的 ui-ux 角色中的图示规则：形状字典、泳道规则、边标注密度、色板与样式类命名）；项目若无该 spec，先与用户确认基准并落成 spec 再动手。同一项目内所有 SVG 共用一套色板与样式类（架构图与流程图不分家），并检索同项目各模块 assets/ 目录中既有的 SVG 作为视觉基准。assets/ 是本 skill 自己的产物约定：图示放在模块文档目录的 assets/ 下，需求文档用相对路径引用，从需求文档所在目录逐级上溯到模块文档目录（需求文档在子目录里几层，就上溯几层）。模块文档目录取宿主契约的 host.moduleDocs（把其中的 <module> 换成模块名），未声明时停下请用户指明；系统级需求文档不属于任何模块，图示放在它所在目录的 assets/ 下
• 绘制完成后两道校验缺一不可：① 运行 scripts/validate_flow_svg.py（流程图默认模式、架构图加 --mode arch）查箭头落点/孤立节点/起止节点/文本重叠；② 渲染成 PNG 用眼睛看（qlmanage/浏览器）——脚本查不出标签拥挤、图例可读性、箭头贴边观感、整图清晰度。只跑脚本没渲染=没画完。语义层（状态值是否与 Domain Model 一致）另需人工与 check-prd
• 边标注：状态只写一处——由目标状态落地点节点承载，边只标动作；不要在边上重复 状态：…（两处都写会在短线上叠字，是高频缺陷）
• 具体模板和示例见第10章生成指引文件

逐章输出规则

• 默认每完成一章立即输出；如果用户要求产出文件或 PRD 包，可以先生成文件，再输出章节摘要、文件路径和自检结论。
• 每章必须有清晰的章节标题，与 PRD 模板结构一致。
• 结构化数据（字段、权限、规则等）优先使用表格。
• 使用 > 💡 方法论提示： 引用块来呈现所应用的理论框架。
• 不确定的内容用 [TODO] 标注，并说明需要补充什么信息。

停机条件

同时满足才算完成：

• 范围内业务完成口径均引用已确认验收标准；上游缺口已回改并获确认，没有用页面细化替代用户裁定。

1. 按文档范围应有的章节都已产出；信息不足处保留骨架并标注待补，没有编造具体数值
2. 待决事项与待完善清单列全，每条写明缺什么、由谁补
3. 引用的数据模型、上位文档与图示路径都真实存在
4. 按待完善清单完成自检

停下交用户：上下文与已有数据模型或源材料冲突；数据模型缺失或有误、导致需求文档的底层逻辑无从落地——先补模型，不跳过模型直接写需求文档；同一处缺口连续两次追问仍无答案。

生成的是待评审的草稿，不宣告"可以开发"。

工作风格

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