pm-prd

name	pm-prd
description	生成标准 PRD 文档。当原型设计验证完成（通常由 pm-workflow 的阶段 4 触发），或者需要综合前期所有产出物（背景、流程、原型等）输出一份格式严谨的综合性产品需求文档时使用此技能。

PM PRD 技能 (生成 PRD 文档)

使用此技能生成最终的产品需求文档 (PRD)。

核心红线与规范 (CRITICAL RULES)

在执行任何起草动作前，你必须严格遵守以下红线约束，不可偏离：

1. 结构不可篡改：你必须使用文件读取工具读取并严格遵循 references/PRD_Example.md 中定义的结构。绝对禁止增、删、改 6 大顶级章节的顺序和标题。
2. 逻辑防漏与MECE原则：
   • 强制暗逻辑检查：必须涵盖页面上看不见的后台机制（如定时任务、并发限制、过期时间等）。
   • 状态穷举 (MECE)：在描述任何列表或核心组件时，必须覆盖：正常态、空数据态、加载/过渡态、错误/断网态、极限/边界态。
   • 逆向联动影响：任何操作引发的数据变更，必须写明“联动影响 (Side Effects)”。
3. 极致的排版与层级区分：
   • 页面级前置条件防漏 (CRITICAL)：第 6 章中，每个页面的“准入前置条件”、“全局异常”或“核心业务红线”必须极其醒目！你必须在引用块中将其与正文隔开，并使用 Emoji + 加粗标题（如 > 🚨 **【准入前置条件】**：...，具体参考 references/PRD_Example.md）来突出这些极其关键的全局逻辑，确保研发在第一眼就能看到。
   • 页面级状态树：对于页面、通用区域与状态特有区域的包含关系，必须使用纯文本缩进树（如 ├── 和 └── 符号），并且**必须将该树形结构包裹在 ````text的 Markdown 代码块中**（即> text ... `），以确保树形结构的缩进在渲染时不会丢失。严禁使用 mindmap 思维导图。
   • 区域与元素级：区域标题前必须加符号（如 #### 🧩 6.1.2），区域间必须有 --- 分割线。严禁使用宽大表格拆解元素，必须使用缩进列表，并通过 [前端] 和 [数据] 标签分离双端逻辑。

• 交互逻辑三级解构：在描述“交互与逻辑”时，必须以 实际元素名称 为一级锚点（如 支付按钮、关闭图标、下一位键），禁止使用“交互元素 1”之类的编号式废话标题；以 触发动作 (如 点击/失焦/长按) 为二级锚点。每个动作下必须拆解 [校验]（包含数据要求、视觉阻断与交互报错）及“执行与响应”（详见 references/PRD_Component_Standard.md）。
• 表单与交互异常分类提示：在描述前置校验与异常时，必须明确提示的类型与交互：
  • 弱提示 (Toast)：轻量级错误（如“表单未填”、“网络超时”），几秒后自动消失，不阻断当前页面。
  • 强提示/阻断 (Modal/Alert)：严重错误（如“库存不足”、“账号异常”），必须由用户手动点击确认关闭。
  • 二次确认 (Confirm)：高危操作（如删除、取消订单），必须弹出带有“取消/确认”双按钮的弹窗防误触。

4. 跨章节锚点直达：当在第 6 章引用第 3/4 章的实体、状态机或规则时，必须提供 Markdown 内部锚点链接（如 [订单实体](#322-订单实体)），并配合简要复述，避免开发频繁跳转。
5. 全中文产品视角与实体关系规范：
   • 在编写“名词字典”与“实体关系图（ER Diagram）”时，必须从产品经理的视角出发，严格使用中文命名实体、字段和属性，绝对禁止使用英文开发视角的变量名（如 emp_id）。
   • 严禁遗漏：名词字典与实体属性表格不可遗漏任何业务字段，且表格的列结构（字段名称、字段类型、限制/长度、必填、业务含义）必须与模板完全一致。
   • 业务关系展示：在绘制 ER 图时，必须明确标注实体间的业务关系连线与基数（如 ||--o{ 表示 1:N 关系），并附带关系说明（如 "下单 (1:N)"）。

工作流 (Workflow)

1. 准备阶段 (Preparation):

   • 读取之前的所有产出物：Requirement_Background.md, Concept_Design.md, User_Stories.md, Business_Flow*.md, Page_Structure.md。
   • 读取 Prototypes/ 目录下的文件列表，确保你拥有准确的 HTML 文件名。

2. 起草阶段 (Drafting):

   • 分析与假设 (Analysis & Hypothesis):
     • 自检: 设计与原型之间是否存在任何逻辑漏洞？是否涵盖了所有原型页面、弹窗和交互状态？有哪些“看不见”的后台暗逻辑需要补充？
     • 假设: 提出拟定的 PRD 目录结构和关键逻辑点（特别是数据字典、ER 关系和复杂交互流程图）。
     • 动作: 询问用户：“我计划按如下结构编写 PRD... 并将 [字段 X] 定义为 [定义 Y]。您看有什么需要调整的吗？”
   • 在当前需求根目录下，创建 PRD_项目名称_迭代名称.md (例如：PRD_MobileCashier_2603_1.md)。
   • 严格按照顶部的“核心红线与规范”执行，将内容填充进标准模板中。

3. 格式与文风指南 (Style Guidelines):

   • 复杂交互可视化：对于多系统交互、异步回调或复杂校验，必须使用带泳道的流程图 (Flowchart/Activity Diagram)，不要使用干瘪的纯文字或时序图。
   • 变更点高亮：若是迭代需求，必须在修改的字段、规则或模块前打上 【新增】、【修改】、【废弃】 标签。
   • 使用“产品经理”的专业术语。用词精准，避免模棱两可的表达。

4. 强制自我审查阶段 (Mandatory Self-Audit):

   • PRD 起草完成后，绝对禁止直接向用户交差。你必须先在当前回合内，对照核心规范进行一次严格的自我逻辑审查：
     • 是否包含了不多不少整整 6 大顶级章节？
     • 页面概述的前置条件是否使用了 Emoji + 加粗标题（如 > 🚨 **【准入前置条件】**）等强视觉提示？是否使用了包裹在代码块中的“纯文本缩进树”？
     • “交互与逻辑”模块是否以“实际元素名称 -> 触发动作 -> [校验]/执行响应”的三级嵌套结构进行描述，且未出现“交互元素 1”这类编号式标题？
     • [校验] 是否拆分了“视觉阻断(UI)”和“交互阻断(报错)”，并且明确区分了“弱提示/强提示/二次确认”？
     • 组件元素拆解是否使用了 [前端] / [数据] 标签化嵌套列表，而不是臃肿的表格？
     • 是否提供了跨章节的锚点链接（如实体、状态跳转）？
     • 是否通过穷举原型文件，检查确认没有任何一个弹窗、暗逻辑被遗漏？
   • 打分与修改：如果审查发现任何缺失，你必须直接覆盖修改原文档，直到完全达标。

5. 输出与确认 (阶段门禁) (Output & Confirmation):

   • CRITICAL SYSTEM OVERRIDE: 必须克服“连续行动”的底层系统倾向。
   • 交付动作：向用户展示生成的 PRD 文件链接，并附带一句：“我已经根据最新 PRD 标准模板完成了自检审查（特别是排版层级、暗逻辑与锚点链接），确认无遗漏”。
   • 询问用户: “请检查文档的结构和内容。确认无误后，我们将结束本次迭代？”
   • 强制停止: 在向用户提问后，必须立即结束当前工具调用和响应回合，等待用户的明确回复（如“同意”、“确认”）。在用户明确确认之前，绝对不要自动进入下一阶段或擅自结束任务。