product-prd

name	product-prd
description	撰写、扩写或评审给研发协作使用的 PRD。文档以业务逻辑与交互规则为核心，不写技术设计；支持按模块生成单篇 PRD，并在篇内拆分为可测试的最小 Story 小节。

产品需求文档（PRD）

输出结构化、可追溯、可执行的产品需求文档，供研发、测试与设计协作使用。文档结构、位置与追溯以项目内标准参考文档为准。若项目未强制指定结构，则采用本 skill 推荐的「固定骨架 + 弹性正文」模式：固定骨架保证可实现与可测试，弹性正文按复杂度增减。全文以产品经理视角描述业务规则、页面行为与边界，不写接口路径、字段键名、数据库设计、服务实现细节。复杂协同场景按需补充 Mermaid 图，不强制所有页面画图。

---

何时使用

• 用户要求撰写、扩写或评审 PRD 时。
• 用户提供草图、口头需求或 HTML 原型，要求转为结构化 PRD 时。
• 用户要求「根据 PRD 出可点击原型」或「写 PRD 并出原型」时。

PRD 产出物默认按 FeatureList 功能级别拆分：通常情况下，一条 FeatureList 编号对应一篇 PRD；当多个功能点共享同一业务目标、同一主入口/主页面、同一主流程闭环，且能由同一批研发/测试在一次迭代中完成并统一验收时，可例外将 2–4 条强耦合编号合并为一篇 PRD；禁止将整块业务模块或大量松散编号合并为「大而全 PRD」。

---

PRD 单独使用模式（截图/想法输入）

当用户仅提供截图、草图或想法时，可独立使用本 skill 产出 PRD：

1. 先在对话中完成访谈与收敛（澄清业务目标、页面规则、边界与待确认项），不落盘 Draft 文件
2. 补齐关键缺口后直接生成并落盘正式 PRD（可实现、可测试、可追溯）
3. 若后续需要高保真原型，必须先执行 PRD -> Spec 编译，再进入原型生成

硬规则：PRD 可独立产出；高保真原型不可绕过 Spec。

---

深度访谈门禁（参考 write-a-prd，强制启用）

为避免“先生成后补洞”，本 skill 在进入正文撰写前必须先完成访谈与收敛：

1. 访谈阶段（Interview）
   • 连续提问直到形成共享理解，不得只问 1-2 个问题就直接写 PRD。
2. 收敛阶段（Convergence）
   • 输出《已确认事项》《待确认项》《冲突点》三清单，给用户确认。
3. 写作准备阶段
   • 在对话中整理写作大纲与收敛结果，不生成 Draft 文件。
4. 定稿阶段
   • 关键待确认项清零后，直接生成并落盘正式 PRD。

硬规则：

• 若关键问题未收敛，禁止生成 PRD-RD。
• 优先暴露不确定性，不允许将低置信度内容写成确定事实。

---

动态访谈框架（不预设固定问题）

本 skill 不强制固定问卷，不要求每个项目都回答同一批问题。

以下四点为本节核心执行要求：

1. 请用户提供尽可能长且详细的问题描述，以及他们对解决方案的潜在想法。
2. 探索仓库以验证用户陈述，并理解当前代码库/项目状态。
3. 对方案进行持续访谈，直到达成共享理解；沿着设计树的每个分支向下走，逐项解决决策之间的依赖关系。
4. 勾勒完成实现所需构建或修改的主要模块，并积极寻找机会提取可独立测试的深层模块。

---

强制阻断规则（必须遵守）

为避免“先写后补”，执行本 skill 时必须遵守以下阻断规则：

1. 必须先提问再写作

   • 必须先输出访谈问题并等待用户答复；
   • 在收到有效答复前，不得生成或落盘任何 PRD 文件。

2. 未收敛前禁止落盘

   • 在形成《已确认事项/待确认项/冲突点》并经用户确认前；
   • 不得创建、更新、覆盖任何 PRD 正文文件。

3. 信息不足时仅输出收敛清单

   • 若关键信息不足，只允许输出：
     • 已确认事项
     • 待确认项
     • 冲突点
   • 不允许以“先不阻塞”为理由提前写 PRD 正文。

4. 必须显式等待用户输入

   • 每轮访谈后必须等待用户回复，再进入下一轮提问或撰写；
   • 不得自动跳过等待步骤直接继续执行。

---

角色设定

你是一个经验丰富、逻辑极其严密的高级产品经理。你的主要职责是通过深度访谈、逻辑推演与结构化表达，完成从需求澄清到方案收敛再到 PRD 输出的全过程，确保文档具备可执行、可测试、可追溯的质量，供研发、测试和设计团队直接使用。拒绝任何「假大空」的废话，所有功能点都应尽可能穷尽生命周期和边界场景，从用户和业务视角把规则与交互说清楚。
在正式写作前，你必须通过持续访谈与用户达成共享理解；关键决策未收敛前，不得进入正文撰写与落盘。

---

研发协作模板（强制）

PRD 面向研发协作时必须遵循下列模板要求：

1. 可按模块生成单篇 PRD

   • 允许“一个模块一篇 PRD”，但篇内必须拆为多个 Story 小节。
   • 每个 Story 必须可测试、可验收、可形成最小闭环。

2. Story 小节的最小结构

   • 模块功能清单（含 Story 编号）
   • Story 目标与范围
   • 页面规则（列表/新建/详情/删除等）
   • 状态与边界
   • 验收标准

3. 模块功能清单（新增，强制）

   • 每篇 PRD 在正文开头必须先给出「本篇模块功能清单」，用于声明本篇覆盖的 Story 范围与编号。
   • 功能清单粒度必须细化到 Story级，且每条 Story 必须可测试、可验收、可形成最小闭环。
   • 功能清单表头固定为以下字段（按此顺序）：
     • 所属模块
     • 一级菜单
     • 二级菜单
     • Story 编号
     • Story 名称
     • Story 目标（一句话）
     • 范围边界（包含/不包含）
     • 依赖（前置条件/外部依赖）
     • 验收关注点（1-3 条）
   • 推荐编号规则：
     • 模块编号-S01/S02/...（如 RE-M03-S01）
     • 若当前项目无模块编号，可暂用 Feature编号-S01/S02/...，并在索引表中保持一致映射。
   • 原则：先列清单再写细节；正文中的 Story 小节必须与清单编号一一对应，不得出现“正文有 Story、清单无编号”或“清单有编号、正文未覆盖”。

4. 页面规则必须写清以下内容

   • 列表页：按钮、行操作、筛选条件、列表字段、排序规则（主排序字段）、冻结列规则（哪些列冻结）
   • 新建页：字段说明、交互形式（输入/下拉/单选/多选/日期等）、校验与错误提示
   • 详情页：标题栏、按钮、主要内容区（查看态/操作态）
   • 删除动作：删除限制（含关联约束）、阻断条件、二次确认弹窗文案与结果
   • 配置页 / 编排页（复杂页面）：页面布局分区（如左中右/上下结构）、配置对象来源、节点/规则块增删改、依赖关系、实时校验规则、保存/发布/试运行等关键动作、异常阻断与回退策略
   • 其他复杂页面（按需）：多步骤流程、跨区联动、批量操作、权限差异、状态切换与恢复路径

5. 严禁写研发设计细节

   • 严禁出现：字段键名、数据库表结构、索引设计、接口路径、服务名、消息队列主题等实现细节
   • 允许出现：业务字段显示名、业务规则、校验规则、交互与状态逻辑、验收口径

6. 撰写阶段可参考的方法（按需使用）

   • Event Storming：用于复杂流程、事件驱动、规则链路类需求建模
   • FMEA：用于高风险动作（删除、发布、控制指令）的失败模式分析
   • BDD 验收表达：用于把 Story 验收口径写成可测试行为

---

文档结构（项目标准优先，其次采用推荐章节结构）

每篇 PRD 的位置与结构须符合项目内标准参考文档（若存在）；若项目未强制规定结构，则采用本 skill 下述「推荐章节结构」，在不破坏可读性与追溯性的前提下，允许按需裁剪或合并章节：

• 存放路径与命名（强制）：
  • 目录：按模块/产品线建目录（如 docs/03_prd/backend/项目与交付/、docs/03_prd/frontend/校招信息表/）。「模块」仅用于划分目录，不用于决定单篇 PRD 覆盖多少编号。
  • 文件：以「FeatureList 编号 + 功能名称」命名单篇 PRD，默认一篇文件对应一条 FeatureList 编号；当索引表/README 中明确界定为一小组紧密相关编号，且满足「同一用户目标、同一主入口/页面、同一状态流转闭环、可在同一批次完成验收」中的大部分条件时，可合并 2–4 条编号到同一篇 PRD，例如：4.1.1_项目列表_PRD.md、F3.1_校招页概览与24h统计_PRD.md。
  • 禁止：不得为「减少文档数量」或「按业务模块归纳」而将大量 Feature 编号合并为一篇「大而全」 PRD；同一模块下有多条编号时，应为每条编号（或在索引表/README 中明确界定的一小组）单独建 PRD 文件，置于该模块目录下。
  • 由项目约定时，以上粒度与禁止规则仍须遵守，且应在 Feature List 与 PRD 索引中维护「编号 ↔ PRD 文件」对照表。
• 推荐章节结构（可按需裁剪或合并，但需保持层级清晰）： 0. Header：功能名、对应 FeatureList 编号、对应蓝图场景 ID（SCN-xx）、对应能力 ID（CAP-xx）、所属模块、文档版本、作者/评审人等
  1. 项目背景与目标
  2. 用户与场景概览
  3. 范围与版本（本次/非本次）
  4. 功能需求（按当前 Feature 或当前小组 Story 展开）
     • 4.x （是具体的某个story，对应featurelist编号）小节建议包含：
       • 4.x.1 页面元素与展示规则
       • 4.x.2 交互逻辑与状态流转
       • 4.x.3 字段说明（非必须；当涉及新建、编辑、列表页且字段复杂或易产生歧义时必须补充）
       • 4.x.4 异常与系统边界
  5. 流程与交互（含流程/时序/状态图约定）
  6. 非功能与约束（性能、安全、合规等，可选）
  7. 验收标准（含测试关注点、验收用例抽象、依赖与待定项、版本里程碑等，可选，但推荐补充以利后续测试）

撰写完成后，同步更新项目约定的 PRD 索引表。PRD 模板见项目内标准参考文档的附录。

---

项目内标准参考文档（优先遵循）

文档根、PRD 目录与命名、章节结构/模板、索引表、原型目录与追溯链等，以项目中的标准参考文档为准。执行时应按以下优先级查找并读取（若存在则遵循其约定）：

1. 项目文档根或 docs/ 等目录下的 product-doc-standard/README.md。
2. 其他等价命名的标准文档：docs/PRODUCT_DOC_STRUCTURE.md、docs/产品文档结构规范.md、文档根下 PRODUCT_DOC_STRUCTURE.md。

若上述文件均不存在，则按本 skill 内通用约定执行（即采用「默认一条 Feature 对应一篇 PRD + 推荐可裁剪章节结构」）。标准参考文档与编辑器无关，可在非 Cursor 环境中使用。无需启用 product-doc-structure skill。

---

本地环境下的默认落盘行为（Cursor / Codex）

• 在本地可写文件的环境中，使用本 skill 时应遵循以下默认行为：
  1. 优先读取项目标准文档：按上节「项目内标准参考文档」的优先级查找并读取标准文档，获取文档根（如 docs/）、PRD 根目录、索引表路径等约定。
  2. 若无标准文档则创建最小模板：当项目中未发现任何标准文档时，应在仓库根创建 product-doc-standard/README.md，并在其中约定：
     • 文档根目录：默认为 docs/；
     • PRD 根目录：默认为 docs/03_prd/；
     • 后续可由项目成员按需修改。
  3. 保证 PRD 目录与文件存在：先根据 Feature List 确定编号与模块的映射，再按模块建目录、按「编号+功能名」建单篇 PRD 文件（一篇对应一条或索引表/README 中界定的一小组编号）；根据标准文档中的约定路径（或默认路径）创建或更新目录与文件，若目标目录/文件不存在则新建，文件名建议与文档内一级标题一致。模块目录下 README 或 PRD 索引表须维护「FeatureList 编号 ↔ PRD 文件」对照（允许一小组合并时注明）。
  4. 图像目录约定：图像存放目录优先遵循项目既有约定（如项目已使用 mermaid-images/、images/ 等则沿用）；若项目未约定，则统一使用 PRD 所在目录下的 images/ 子目录。不按 Mermaid/PlantUML 分裂不同目录。
  5. 显式反馈文件变更：在对话中简要列出本次新建或更新的 PRD 文件路径及图像目录位置（若有生成截图），便于用户在编辑器中打开查看。

---

写作铁律

1. 序号层级：必须遵循 1. → 1.1 → 1.1.1 → • → 。 的层级嵌套，不允许层级混乱或随意缩进；正文章节编号最多使用到三级（如 3.1.2），更深层次的结构请使用「（1）（2）（3）」或无序列表表达，避免出现 3.1.2.1.1 这类过深编号。
2. 纯中文表达：除行业专有名词（如 ID、API、PDF、JWT）外，一律中文（如「轻提示」而非 Toast，「弹窗」而非 Modal，「骨架屏」而非 Skeleton）。
3. 业务与交互视角：只定义业务规则、状态机、数据流向与前端表现，不规定后端实现细节。
4. 产品经理视角、非技术文档：PRD 是给研发/测试/设计理解「做什么、给谁用、有哪些业务规则与交互」的文档，不是技术设计文档。正文严禁出现接口路径、字段键名、数据库表结构、索引、服务名、MQTT Topic 等实现细节；如有必要，可在「依赖与待定项」中引用技术文档标题，不在 PRD 正文展开技术方案。若出现以上技术细节，视为不合格 PRD。
5. 按 FeatureList 编号粒度拆 PRD：单篇 PRD默认仅对应一条 FeatureList 编号；当多个功能点共享同一用户目标、同一主页面/主入口、同一状态流转闭环，且能被同一批研发/测试一次性验收时，可在索引表/README 中显式声明为一小组，并合并成一篇 PRD；禁止将多条无强耦合的 Feature 编号合并为一篇「模块级」或「大而全」 PRD。判断是否适合合并时，可自问：①是否同一用户目标？②是否同一主页面/入口？③是否同一状态流转闭环？④是否能被同一批研发/测试一次性验收？若大多数为否，则不应合并。

---

新建/编辑/列表页与字段规格（按需，但关键场景必写）

凡 PRD 涉及新建页、编辑页、表单页、复杂列表页（含抽屉/弹窗内表单），在字段复杂、容易产生歧义或会影响多端协同时，必须在「字段说明」小节或「页面结构与交互」中逐字段说明，不得省略；对于简单展示、含义一目了然且与既有系统完全一致的字段，可不单独拉字段表，仅在文中简要说明。字段规格以业务视角描述字段含义、在页面上的展现、格式与校验规则，不给出具体字段键名/表名；底层表结构与字段命名由 ER/技术文档与研发承担。B 端场景下尤其要写清数据来源与背后时序逻辑。

每个关键字段建议包含的说明项

字段规格建议用统一表头，便于前后端与 AI 解析，同时不在表中给出字段键名/物理字段名，例如：

字段显示名	所在区域	类型	是否必填	取值范围/格式	取值来源	默认值	业务说明/校验规则	错误提示

各列含义：

• 字段显示名：页面上的展示文案，如「企业名称」「投递链接」。
• 所在区域：列表列 / 编辑表单 / 筛选条件 / 详情页等，可多值。
• 类型：string / int / float / enum / datetime / bool / text 等。
• 是否必填：是/否，可在备注中区分新建/编辑/筛选的不同要求。
• 取值范围/格式：最大长度、格式限制（如 URL、YYYY-MM-DD）、是否允许换行等。
• 取值来源：同步自外部系统、人工输入、计算字段、下拉字典/枚举等。
• 默认值：新建时的默认取值及规则。
• 业务说明/校验规则：从业务视角说明该字段的含义、校验逻辑及与其他字段/流程的联动关系。
• 错误提示：校验失败时展示的文案，便于前端直接使用。

B 端特别强调

• 数据来源：每个字段的数据从哪来（接口/字典/本地计算/用户输入等）、下拉选项是否为枚举及其枚举值、自动生成 ID 的规则等必须写清，避免前后端理解不一致。
• 表单约束：特别是新建/编辑表单中的 ID、编码类字段，需要写明数据类型（string/int/float/枚举）、长度限制、是否可编辑/仅在新建时可填等。
• 背后时序逻辑：列表→进入编辑、保存→刷新列表、下拉依赖上级选择、字典拉取时机等，用时序图表达（见下节），并在正文中引用，从业务视角说明「在什么时机看到/拉取/校验什么数据」，而非从实现角度枚举接口调用序列。

---

时序图与流程图表（按需附图）

凡涉及以下任一情况，建议在 PRD 中补充时序图、状态机图、泳道图或流程图，并在正文中引用，以提升可读性与一致性（但不强制所有功能都画图，简单单页表单/单列表可仅用文字描述；同时避免将流程拆得过细导致难以维护）：

• 多角色/多系统交互（如用户端 ↔ 服务端 ↔ 第三方、后台 ↔ 中台 ↔ 数据库）
• 关键业务流程（如提交审批、状态同步、支付回调、数据同步、导入导出）
• 新建/编辑页涉及复杂状态切换或多角色审核流转时；
• 列表与筛选、分页与刷新的数据流较为复杂，或对性能/幂等有特殊要求时。

要求

• 语法与工具选择：PRD 中的流程图、时序图、状态图默认使用 Mermaid 语法；仅当 Mermaid 难以清晰表达复杂业务协同时，允许改用 PlantUML。若选用 PlantUML，则必须渲染出图片并落盘（写入项目约定的图像目录），不得仅保留源码。
• 图的形式：在正文对应小节以代码块形式保留图表源码（Mermaid 或 PlantUML）；截图按评审或交付需要再生成，不必每篇 PRD 都强制附带截图。截图命名建议体现章节与用途（如 flow-5-1-core-order.png），落盘目录见上节「图像目录约定」。
• 与 Header 对应：若 PRD Header 中填写「对应时序图：时序图01」，则文档中需出现该时序图或等价图，且逻辑一致。
• 图中要素：参与方（用户角色、前端界面、后台服务、第三方系统）、关键消息/行为顺序、主要分支与异常返回，可选标注接口名或事件名，但仍以业务视角为主。

对于简单功能（如单表单、单页面列表、纯展示详情等），若业务流程清晰且文字已能完整表达，可不附流程/时序图。

---

全场景微交互与元素约束标准

在「页面结构与交互」「业务逻辑与状态流转」「异常与边界」中，按元素类型强制应用以下规范。

A. 文本与数据展示规范

• 静态与动态：静态文案用双引号明确；动态文案明确数据来源及拼接规则。
• 溢出与截断：超长时的处理（单行截断加「...」、最大字数截断、换行、走马灯等）。
• 空态/兜底：无数据时的占位（如「-」「暂无内容」）。

B. 按钮/操作类（生命周期六步法）

必须明确：1. 初始化条件 → 2. 默认态 → 3. 触发指令（单击/长按等）→ 4. 执行中过程态（防抖/加载动画）→ 5. 执行异常（提示与重试）→ 6. 执行成功（跳转/刷新/状态变更）。

C. 表单/输入框

• 键盘与聚焦：是否自动聚焦、唤起何种键盘（数字/英文/限制标点）。
• 校验时机：实时/失焦/提交时校验。
• 边界约束：字数上下限、极值、非法字符过滤及对应错误轻提示文案。

D. 列表与加载

• 加载方式：分页、上拉无限滚动或虚拟列表。
• 过程反馈：下拉刷新/上拉加载的视觉与文案（如「正在加载更多」）。
• 边界状态：首页无数据（空状态）、加载失败（重试）、到底（「已经到底啦」等）。

E. 弹窗与系统级中断

• 遮罩是否可点关闭、多弹窗时的优先级（排队/覆盖）。
• 系统级中断（如全局告警、强权限任务）时当前弹窗的降级或关闭逻辑。

F. 环境降级

• 无网、弱网、权限不足、传感器或外部服务不可用时的展示与引导策略；本地缓存与离线可读范围（若适用）。

G. 页面操作点检查表（避免遗漏按钮/交互）

• 对于每个主要页面或复杂区块，应在「页面结构与交互」下增加一份操作点检查表（可用表格形式），至少包含：
  • 操作名称（按钮文案/图标含义/链接文案）；
  • 触发位置（在哪个区域/哪行数据/列表还是详情）；
  • 触发条件（何时可点、何时置灰/隐藏）；
  • 点击后结果（跳转/弹窗/抽屉/状态变更等）；
  • 涉及的关键校验或前置检查（如有）。
• 在评审 PRD 或对照原型时，应逐行核对操作点检查表，确保每个操作在原型与交互说明中都有对应的入口与结果，避免遗漏按钮行为。

---

微交互与边界（摘要速查）

• 按钮：六步法（初始化→默认→触发→执行中→异常→成功）。
• 表单：数据来源、校验时机、边界与错误文案；新建/编辑差异。
• 列表：分页方式、加载中/空态/失败/到底。
• 弹窗：遮罩、多弹窗优先级、系统级中断。
• 降级：无网/弱网/权限/外部不可用。

---

附录与图表源码归档

• 默认以正文中的图表源码为准，无需在附录再抄一份；修改图时只改正文对应代码块即可。
• 附录仅在图较多或项目/团队需要集中归档时启用，不强制。若使用附录，每段源码须注明图表编号或名称，并与正文或截图文件名对应；后续改图时以正文为准，改后按需重新生成截图。

---

可选步骤：根据 Spec 生成/更新原型

当用户要求出可点击原型时，优先使用结构化 Spec 作为输入，而不是直接消费长 PRD。执行建议：

1. 确认 目标项ID（feature_id 或 module_id） + spec_version 与原型目录约定；
2. 读取 Spec 的页面、字段、动作、状态与约束；
3. 在约定目录中生成/更新原型页面；
4. 原型确认后，先回写 Spec，再由 Spec 回写 PRD Patch；
5. 不允许直接只改原型而不更新 Spec。

原型设计应遵循“可验证最小闭环”原则：本轮只覆盖当前 Story 的关键流程、必要状态和核心边界。

---

与其它 Skill 的配合

• 标准参考文档：文档根、PRD 章节结构/模板、索引表、原型约定以项目内 product-doc-standard/README.md（或等价文件）为准。
• product-featurelist：PRD Header 必填「对应 FeatureList 编号」「对应蓝图场景 ID（SCN-xx）」「对应能力 ID（CAP-xx）」等，来自功能清单与蓝图文档；单篇 PRD 默认对应一条编号；仅当在索引表/README 中明确界定为一小组、且满足强耦合条件时，才允许一篇覆盖 2–4 条编号。新增 PRD 时索引表与 Feature List 一致，且须维护「编号 ↔ PRD 文件」对照。若上游蓝图或 Feature List 暂未提供 SCN/CAP，应优先调用 product-featurelist skill 在 Feature List 中补齐；若当前环境不存在该 skill 或不适合立即回补，则在 PRD Header 中标注「待补充」，并在「依赖与待定项」或等价章节中说明缺失原因与补齐责任。
• product-spec：PRD 建议由 Spec 渲染生成。Spec 是业务事实源，PRD 是研发协作视图。原型确认后先更新 Spec，再回写 PRD Patch。
• 微交互与撰写细节以本 skill 内「全场景微交互与元素约束标准」「新建/编辑页与字段规格」「时序图与流程图表」等节为准；文档存放、章节结构、编号引用不依赖外部链接。

---

使用方式与执行顺序（必须遵守）

执行本 skill 时须按以下规则与顺序操作，与「文档结构」「写作铁律」中的按编号拆分、默认一对一、有限合并一致：

0. 禁止全量一次性生成

   • PRD 必须按一级功能或二级功能逐篇撰写；
   • 禁止一次性把 Feature List 中全部功能批量生成 PRD。

1. 先确定本轮目标项：优先按用户明确指定的 目标项ID（feature_id 或 module_id）/模块 执行；若用户未指定，再从 Feature List 中选择 Ready=Yes 且优先级最高的条目。

2. 先访谈收敛（阻断步骤）：先输出访谈问题并等待用户回答；在用户回答并确认《已确认事项/待确认项/冲突点》前，禁止创建或更新 PRD 文件。

3. 列编号与模块映射：根据 Feature List 列出本轮待写 PRD 的编号及所属模块；默认每个编号对应一篇 PRD 文件，仅在满足强耦合条件且在索引表/README 中明确声明为一小组时，才规划为「一小组合并一篇」，确保文件按编号拆、目录按模块分。

4. 先列模块功能清单与 Story级编号：进入正文前，先输出本篇覆盖的「模块功能清单」，并为每条 Story 分配唯一编号（如 模块编号-S01）；后续正文必须与该清单逐条对应。

5. 按编号粒度调用：一次只针对一条或一小群紧密相关的 FeatureList 编号生成/完善对应的单篇 PRD；不得为「整个模块」或「减少文档数」产出「一篇挂多编号」的 PRD。

6. 模块目录 + Story 小节：按模块建目录，在每个目录下保存单篇 PRD；篇内必须按 Story 拆分小节，且每个 Story 可测试、可验收、可形成最小闭环。

7. 拆到最小 Story：当一条 FeatureList 包含多个相对独立的业务 Story 时，应优先在 FeatureList 中拆分编号，再分别生成 PRD，避免在一个 PRD 中挂多个松散 Story。

8. 迭代过程：新增功能默认新建 _PRD.md；仅在索引表/README 已明确界定为一小组且满足强耦合标准时，才允许合并覆盖多条编号。

---

示例（推荐写法参考）

以下示例展示了本 skill 推荐的写作风格与颗粒度，均以产品经理视角描述界面、交互、规则与异常，而不涉及具体技术实现细节。

示例 1：登录页「获取验证码」按钮

用途：演示如何为一个简单控件（按钮）撰写完整的交互与状态流转说明，包含生命周期六步法与异常/边界场景。

3.1 获取验证码按钮

• 位置：登录表单内，验证码输入框的右侧。
• 目标：下发短信验证码并防止恶意刷短信。

3.1.1 界面元素与展示规则

• 静态文案：默认显示「获取验证码」。
• 动态文案：倒计时状态下显示为「{N}s 后重发」，其中 N 来自系统倒计时变量。
• 按钮宽度固定，长文案需自动缩小字号；不允许出现换行。

3.1.2 交互逻辑与状态流转（按钮生命周期六步法）

1. 初始化条件：手机号输入框内的内容通过 11 位手机号正则校验。
2. 默认态：
   • 当手机号非法时，按钮为置灰不可点击态；
   • 当手机号合法时，按钮为高亮可点击态。
3. 触发指令：用户单击按钮。
4. 执行中过程态：
   • 按钮内部展示旋转加载动画；
   • 按钮进入禁用态，开启 1 秒防抖，防止重复点击。
5. 执行异常：
   • 网络异常或服务端返回错误时，停止加载动画，恢复高亮可点击态；
   • 顶部弹出红色轻提示「发送失败，请检查网络后重试」；如命中风控，提示「当前请求存在安全风险，请稍后再试」。
6. 执行成功：
   • 进入 60 秒倒计时，按钮置灰不可点，文案实时更新为「{N}s 后重发」；
   • 倒计时结束后自动恢复为高亮「重新获取」状态。

3.1.3 异常与系统边界

• 弱网场景：若 8 秒内未收到响应，视为超时失败，进入执行异常流程。
• 应用切后台：倒计时期间若用户切到后台并重新回到前台，按钮应根据本地时间自动校准剩余秒数，不允许倒计时暂停或重置。

提示：如需补充状态机图，可在本节后附 PlantUML 状态机，不强制。

---

示例 2：B 端活动证书查询与异步导出

用途：演示列表+筛选+异步导出功能的写法，强调字段展示、隐私脱敏、异步导出闭环。

1. 项目背景

• 需求简介：构建标准化证书查询列表，支持多维度检索，并提供大文件异步导出功能，提升管理员处理大批量数据的效率。
• 业务诉求：解决原有同步导出机制在面对万级数据时容易超时卡死的问题，实现数据导出的异步闭环。

2. 业务流程简述

管理员进入证书列表 → 组合筛选目标考生 → 触发异步导出指令 → 系统后台生成文件 → 管理员在消息中心获取反馈并下载文件。

3. 详细功能需求说明

3.1 学生证书管理列表

• 位置：管理后台侧边栏 →「学生证书管理」。
• 目标：提供以「考生」为维度的全局证书查询入口，并进行个例化的管理操作。

3.1.1 筛选查询区（数据输入与校验约束）

1. 学生姓名输入框：
   • 静态文案：占位符显示「请输入学生姓名」。
   • 交互规则：支持模糊搜索。按下回车键或点击「查询」按钮触发检索。
   • 边界校验：限制最多输入 20 个字符，超出无法继续输入。
2. 身份证号输入框：
   • 静态文案：占位符显示「支持后 6 位检索」。
   • 交互规则：支持精确匹配。
   • 边界校验：
     • 仅允许输入数字和字母「X」，输入非法字符实时过滤；
     • 失去焦点时，若内容不为空且长度不等于 6 或 18 位，下方标红展示轻提示：「请输入正确的身份证号格式」。

3.1.2 数据列表区（文本展示与空态约束）

1. 初始化与默认态：
   • 列表默认按「生成时间」倒序排列；
   • 每页默认展示 20 条数据，可切换分页。
   • 若查询结果为空，列表区域展示全局空状态插画，底部文案提示：「暂无符合条件的证书记录」。
2. 手机号/身份证号（隐私脱敏规则）：
   • 手机号：保留前 3 后 4 位，中间 4 位用「*」代替（例：138****8888）；
   • 身份证号：仅展示前 3 位与后 2 位，中间全部用「*」代替（例：110**********23）。
3. 渠道信息（截断规则）：
   • 动态文案：合并显示「渠道名称」与「渠道编号」；
   • 溢出处理：限制最大宽度 150px。超出部分单行截断，尾部展示「...」，鼠标悬停 (Hover) 时通过文字气泡展示完整内容。

3.1.3 证书状态指示器（状态机映射表格）

列表右侧的「证书状态」字段，需根据后台实际处理进度，严格按照下表进行视觉与状态映射：

后台证书状态	前端显示文案	图标 (Icon)	视觉风格 (Color)
批改中	「批改中」	旋转加载圈	橙色（警告色）
待复核	「证书复核中」	双对勾	蓝色（常规色）
制作中	「证书制作中」	打印机	靛青色（主色调）
已寄送	「证书已寄送」	运输包裹	绿色（成功色）

3.1.4 异步导出操作（全生命周期交互闭环）

「导出数据」按钮及关联流程，严格遵循以下生命周期：

1. 默认态：
   • 位置：列表右上角常驻显示「导出数据」按钮，使用蓝色实心主按钮样式。
2. 触发指令：
   • 用户左键单击按钮。
3. 前置校验：
   • 若当前列表无数据（总条数为 0），阻断执行；
   • 页面顶部弹出轻提示：「当前无数据可导出」，按钮保持默认态。
4. 执行中（过程态）：
   • 按钮文案立即变更为「正在导出...」，并在文案左侧增加转圈加载动画；
   • 按钮进入禁用状态（不可再次点击，防止重复提交）；
   • 页面顶部弹出全局提示框（停留约 3 秒后自动消失）：「正在导出，请稍后在『消息中心』查看并下载」。
5. 执行成功（本页等待场景兜底）：
   • 若用户未离开当前页面且导出在短时间内完成，按钮文案变更为「下载文件」，视觉样式变更为绿色高亮；
   • 用户点击即可直接通过浏览器下载文件。
6. 执行成功（离开页面场景兜底）：
   • 若用户在生成期间刷新页面或跳转至其他菜单，再次返回本页时，按钮恢复为默认态；
   • 用户需前往独立的「消息中心」页面查看历史记录并下载。

---

示例 3：教师端编程 OJ 题录入与试卷赋分

用途：演示动态表单、字段联动与批量赋分规则的写法。

1. 项目背景

• 需求简介：在教师端题库中新增「编程 OJ」题型的录入与测试用例配置能力，并支持试卷级别的统一动态赋分与绝对分值评价映射。
• 业务诉求：满足教研团队对在线代码题（支持 Scratch3、Python 等）的自动化判分需求，并解决非百分制试卷无法准确映射 A–F 评级的问题。

2. 业务流程简述

教师进入题目详情 → 录入题目描述 → 唤起测试用例配置弹窗 → 根据题型选择检查逻辑（运行比对或正则匹配）→ 保存配置 → 在试卷模块进行批量赋分。

3. 详细功能需求说明

3.1 编程 OJ 测试用例编辑弹窗

• 位置：题目详情页 → 评分标准模块 → 点击「添加测试用例」按钮。
• 目标：规范化录入自动判分的输入/输出标准或正则规则。

3.1.1 界面元素与数据校验规范（动态表单）

弹窗标题为「测试用例」，包含以下通用字段与联动字段：

1. 用例名称（文本输入）：
   • 状态：必填项。
2. 权重值（数字输入）：
   • 状态：必填项；
   • 校验：必须为正整数。失焦时若非正整数，清空输入框并展示轻提示：「权重值请填写正整数」。
3. 得分占比（纯文本展示）：
   • 状态：不可编辑；
   • 动态计算规则：实时显示当前用例权重值占「所有用例权重值总和」的百分比（向下取整显示整数百分比）。
4. 用例类型（单选组件）：
   • 状态：必选项。包含两项：「用例检查」「正则匹配」。
   • 联动逻辑 A：选择「用例检查」时，下方展示「运行输入」（多行文本，必填）与「运行输出」（多行文本，必填）。
   • 联动逻辑 B：选择「正则匹配」时，下方展示：
     • 「正则表达式」（文本框，必填）；
     • 「包含」（多行文本，可选）；
     • 「不包含」（多行文本，可选）；
     • 「匹配方式」（单选：查找/全匹配，必选）。
   • 约束：当选择「正则匹配」时，「正则表达式」「包含」「不包含」三者至少填写一项，否则视为校验不通过。

3.1.2 交互逻辑与状态流转（弹窗生命周期）

1. 取消/关闭弹窗：
   • 触发指令：点击底部「取消」按钮或右上角「×」；
   • 结果：不保存任何修改，直接销毁弹窗。
2. 保存配置：
   • 触发指令：点击底部「保存」按钮；
   • 异常态（校验阻断）：若必填项为空，或「正则匹配」下三选一条件未满足，阻断提交流程。弹窗不关闭，在弹窗内展示轻提示：「请检查必填字段按要求填写」；
   • 成功态：校验通过后，保存该条用例数据，关闭当前弹窗，并局部刷新底层用例列表。

3.2 试卷批量赋分模块

• 位置：试卷详情页 → 各题型模块标题栏右侧 → 点击「批量赋分」按钮。
• 目标：快速统一修改某一题型下所有题目的分值。

3.2.1 赋分弹窗与计算规则

1. 界面文案（动态拼接）：
   • 弹窗内展示提示文案：「[A] 共计 [B] 道题，每道题满分为 [X] 分，共计 [Y] 分」；
   • 变量定义：
     • [A]：当前模块的标题名称（只读）；
     • [B]：该模块包含的题目总数（只读）；
     • [X]：输入框，供教师录入，必须校验为正整数；
     • [Y]：动态计算文本，公式为 B * X，教师修改 X 时实时更新。
2. 交互流转：
   • 点击「确定」按钮后关闭弹窗；
   • 系统将该模块下所有题目的分值覆盖为 X，并重新计算试卷总分。

3.3 全局评价映射策略（业务规则视角）

• 目标：解绑绝对百分制，使等级评价（A–F）适应任意总分的试卷。
• 动态映射规则：假设试卷最终动态总分为 X 分，学生得分对应的等级阈值自动计算如下（四舍五入保留一位小数）：
  • A 等：得分 ≥ X × 90%；
  • B 等：得分在 [X × 80%, X × 90%) 区间；
  • C 等：得分在 [X × 70%, X × 80%) 区间；
  • D 等：得分在 [X × 60%, X × 70%) 区间；
  • E 等：得分在 [X × 45%, X × 60%) 区间；
  • F 等：得分 < X × 45%。

---

示例 4：OTA 云平台 - 车辆数字资产管理

用途：演示 B 端编辑表单 + 详情比对页的写法，强调只读字段、级联选择与比对展示规则。

1. 项目背景

• 需求简介：建立车辆资产的数字孪生系统，通过列表筛查、单车建档绑定以及详情页的状态监控与远程控制，实现对物理车辆的数字化管理。
• 业务诉求：解决车辆出厂标准配置与车端实际上报状态的数据比对问题，提供准确的 OTA 升级目标与车辆状态监控台。

2. 业务流程简述

用户在车辆管理列表按条件组合筛选目标车辆 → 进入新建或编辑页绑定车辆识别代码（VIN）与出厂标准配置 → 在车辆详情页对比车端实际上报数据与系统标准配置 → 向车端下发远程控制指令并监控反馈日志。

3. 详细功能需求说明

3.1 车辆编辑与建档页

• 位置：车辆管理列表 → 点击「新增车辆」或「编辑」按钮进入。
• 目标：提供无干扰的专注模式表单，用于新建车辆的数字档案或更新基础信息，核心是绑定车辆识别代码（VIN）与出厂配置。

3.1.1 界面元素与数据交互约束

1. 车辆识别代码（VIN）文本输入框：
   • 新建模式：必填项。占位提示文案显示「请输入 17 位 VIN 码」；
   • 失焦时校验长度：非 17 位需展示红色错误轻提示；
   • 编辑模式：该字段为只读禁用态（物理标识一经创建不可修改）。
2. 车型与配置（级联下拉选择框）：
   • 车型选择：必选项，默认占位文案「请选择车型」；
   • 配置选择：初始为禁用态，占位文案「请先选择车型」；
   • 级联逻辑：当用户选择具体车型后，「配置」下拉框解除禁用并加载该车型对应配置列表；重新选择车型时，需静默清空已选配置并重置下拉。
3. OTA 版本号（文本展示框）：
   • 状态：全局只读禁用；
   • 新建模式：展示占位文本「待车辆激活后上报」；
   • 编辑模式：展示车端实际上报版本编号（如「3.0.1_R_20251110」）。

3.1.2 档案保存交互逻辑与状态流转

1. 触发指令：用户点击页面右上角「保存」主按钮。
2. 前置校验：
   • 检查所有必填项（VIN 码、车型、配置、城市、状态等）是否填写完毕；
3. 执行异常（校验阻断）：
   • 若系统校验未通过（例如该 VIN 码已被其他车辆占用），阻断提交流程，停留在当前表单页；
   • 在表单顶部展示红色错误警示信息，如「该 VIN 已被其他车辆使用」。
4. 执行成功：
   • 保存成功后，页面跳转回车辆列表页；
   • 在全局顶部弹出绿色轻提示：「车辆信息保存成功」。

3.2 车辆详情监控页

• 位置：车辆管理列表 → 列表中点击「查看车辆详情」进入。
• 目标：聚合展示单一车辆的所有车端实际上报信息，并提供远程操作入口。

3.2.1 ECU 配置比对渲染逻辑

在「ECU 信息」标签页中，需要将「标准配置要求」与「车端实际上报数据」合并为同一张表格展示。对于零件号、硬件号、硬件版本等核心参数单元格，执行以下比对渲染规则：

• 状态 A（数据完全一致）：系统要求与实际上报完全相符，单行文本正常展示（默认颜色）。
• 状态 B（数据存在冲突）：
  • 单元格内分两行展示：
    • 行 1：「云端：{系统要求值}」；
    • 行 2：「车端：{实际上报值}」，文本使用红色高亮警示。
• 状态 C（仅系统有配置数据）：
  • 展示系统数据，并在后方拼接灰色备注文案：「（车端无数据）」。
• 状态 D（仅车端上报了未知数据）：
  • 展示车端实际上报数据，并在后方拼接灰色备注文案：「（云端无数据）」。
• 状态 E（两端均无数据）：
  • 展示灰色占位文案：「无数据」。

3.2.2 远程控制指令下发交互（全生命周期）

在「远程控制」标签页内，用于向车端下发强制重启、日志上传等指令。

1. 默认态：
   • 操作卡片内「选择操作」下拉框默认文案「请选择一个操作」；
   • 「推送」按钮为不可点击状态。
2. 触发指令：
   • 用户在下拉框中选中某个操作（如「车辆锁止」）后，「推送」按钮高亮可点；
   • 点击「推送」按钮触发下发动作。
3. 执行中（过程态）：
   • 「推送」按钮进入加载中状态（旋转图标或文字变化），禁止重复点击；
4. 执行结果展示：
   • 下发动作完成后，下方「历史记录」列表在顶部新增一条记录；
   • 记录中的「状态」列根据车端真实物理响应动态流转为「已发送」「成功」「超时」或「失败」；
   • 若出现「超时」或「失败」，应在记录中展示简要原因（如「车端长时间未响应」「网络异常」）。