Menü
撰写、扩写或评审给研发协作使用的 PRD。文档以业务逻辑与交互规则为核心，不写技术设计；支持按模块生成单篇 PRD，并在篇内拆分为可测试的最小 Story 小节。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
生成或更新产品蓝图与场景说明。聚焦产品定位、市场洞察、用户场景与边界决策，为 Feature List、Spec、PRD 与原型提供上游输入；兼容 0-1 新产品与 1-n 版本迭代。
统一编排产品设计流程：blueprint -> featurelist -> spec -> prd -> prototype-generator -> patch。支持“用户指定先做项”与“按优先级推进”双入口，一次只推进一个最小闭环并保持分层一致。
在产品立项或版本规划阶段，梳理并输出标准化的 Feature List（功能清单）。以一级/二级菜单与模块能力为主，维护轻量计划字段（优先级/状态/依赖/迭代/Ready），支持“用户指定先做项”与“按优先级推进”双入口。
基于 product-spec 生成高保真前端原型（Next.js App Router + TypeScript + Tailwind + shadcn/ui）。当用户需要从已确认的 feature/spec 产出可演示、可继续演进的页面原型时使用；支持列表/新建/详情/删除等中后台场景，强制状态覆盖与交互约束，并输出可回写的 prototype_change_id。
结构化产品设计事实源。将单个 feature/story 固化为可机器消费的页面与交互规范，作为 PRD 与原型的共同上游。
| name | product-prd |
| description | 撰写、扩写或评审给研发协作使用的 PRD。文档以业务逻辑与交互规则为核心，不写技术设计；支持按模块生成单篇 PRD，并在篇内拆分为可测试的最小 Story 小节。 |
输出结构化、可追溯、可执行的产品需求文档，供研发、测试与设计协作使用。文档结构、位置与追溯以项目内标准参考文档为准。若项目未强制指定结构，则采用本 skill 推荐的「固定骨架 + 弹性正文」模式：固定骨架保证可实现与可测试，弹性正文按复杂度增减。全文以产品经理视角描述业务规则、页面行为与边界，不写接口路径、字段键名、数据库设计、服务实现细节。复杂协同场景按需补充 Mermaid 图，不强制所有页面画图。
PRD 产出物默认按 FeatureList 功能级别拆分：通常情况下，一条 FeatureList 编号对应一篇 PRD；当多个功能点共享同一业务目标、同一主入口/主页面、同一主流程闭环，且能由同一批研发/测试在一次迭代中完成并统一验收时，可例外将 2–4 条强耦合编号合并为一篇 PRD；禁止将整块业务模块或大量松散编号合并为「大而全 PRD」。
当用户仅提供截图、草图或想法时，可独立使用本 skill 产出 PRD：
PRD -> Spec 编译，再进入原型生成硬规则：PRD 可独立产出；高保真原型不可绕过 Spec。
为避免“先生成后补洞”，本 skill 在进入正文撰写前必须先完成访谈与收敛：
硬规则：
PRD-RD。本 skill 不强制固定问卷，不要求每个项目都回答同一批问题。
以下四点为本节核心执行要求：
为避免“先写后补”，执行本 skill 时必须遵守以下阻断规则：
必须先提问再写作
未收敛前禁止落盘
信息不足时仅输出收敛清单
必须显式等待用户输入
你是一个经验丰富、逻辑极其严密的高级产品经理。你的主要职责是通过深度访谈、逻辑推演与结构化表达，完成从需求澄清到方案收敛再到 PRD 输出的全过程，确保文档具备可执行、可测试、可追溯的质量，供研发、测试和设计团队直接使用。拒绝任何「假大空」的废话，所有功能点都应尽可能穷尽生命周期和边界场景，从用户和业务视角把规则与交互说清楚。
在正式写作前，你必须通过持续访谈与用户达成共享理解；关键决策未收敛前，不得进入正文撰写与落盘。
PRD 面向研发协作时必须遵循下列模板要求：
可按模块生成单篇 PRD
Story 小节。Story 小节的最小结构
模块功能清单（新增，强制）
模块编号-S01/S02/...（如 RE-M03-S01）Feature编号-S01/S02/...，并在索引表中保持一致映射。页面规则必须写清以下内容
严禁写研发设计细节
撰写阶段可参考的方法（按需使用）
每篇 PRD 的位置与结构须符合项目内标准参考文档（若存在）；若项目未强制规定结构，则采用本 skill 下述「推荐章节结构」，在不破坏可读性与追溯性的前提下，允许按需裁剪或合并章节：
docs/03_prd/backend/项目与交付/、docs/03_prd/frontend/校招信息表/）。「模块」仅用于划分目录，不用于决定单篇 PRD 覆盖多少编号。4.1.1_项目列表_PRD.md、F3.1_校招页概览与24h统计_PRD.md。撰写完成后，同步更新项目约定的 PRD 索引表。PRD 模板见项目内标准参考文档的附录。
文档根、PRD 目录与命名、章节结构/模板、索引表、原型目录与追溯链等，以项目中的标准参考文档为准。执行时应按以下优先级查找并读取（若存在则遵循其约定）：
docs/ 等目录下的 product-doc-standard/README.md。docs/PRODUCT_DOC_STRUCTURE.md、docs/产品文档结构规范.md、文档根下 PRODUCT_DOC_STRUCTURE.md。若上述文件均不存在，则按本 skill 内通用约定执行（即采用「默认一条 Feature 对应一篇 PRD + 推荐可裁剪章节结构」）。标准参考文档与编辑器无关，可在非 Cursor 环境中使用。无需启用 product-doc-structure skill。
docs/）、PRD 根目录、索引表路径等约定。product-doc-standard/README.md，并在其中约定：
docs/；docs/03_prd/；mermaid-images/、images/ 等则沿用）；若项目未约定，则统一使用 PRD 所在目录下的 images/ 子目录。不按 Mermaid/PlantUML 分裂不同目录。1. → 1.1 → 1.1.1 → • → 。 的层级嵌套，不允许层级混乱或随意缩进；正文章节编号最多使用到三级（如 3.1.2），更深层次的结构请使用「（1）（2）（3）」或无序列表表达，避免出现 3.1.2.1.1 这类过深编号。凡 PRD 涉及新建页、编辑页、表单页、复杂列表页（含抽屉/弹窗内表单），在字段复杂、容易产生歧义或会影响多端协同时，必须在「字段说明」小节或「页面结构与交互」中逐字段说明，不得省略；对于简单展示、含义一目了然且与既有系统完全一致的字段，可不单独拉字段表，仅在文中简要说明。字段规格以业务视角描述字段含义、在页面上的展现、格式与校验规则，不给出具体字段键名/表名；底层表结构与字段命名由 ER/技术文档与研发承担。B 端场景下尤其要写清数据来源与背后时序逻辑。
字段规格建议用统一表头，便于前后端与 AI 解析，同时不在表中给出字段键名/物理字段名，例如：
| 字段显示名 | 所在区域 | 类型 | 是否必填 | 取值范围/格式 | 取值来源 | 默认值 | 业务说明/校验规则 | 错误提示 |
|---|
各列含义：
凡涉及以下任一情况，建议在 PRD 中补充时序图、状态机图、泳道图或流程图，并在正文中引用，以提升可读性与一致性（但不强制所有功能都画图，简单单页表单/单列表可仅用文字描述；同时避免将流程拆得过细导致难以维护）：
flow-5-1-core-order.png），落盘目录见上节「图像目录约定」。对于简单功能（如单表单、单页面列表、纯展示详情等），若业务流程清晰且文字已能完整表达，可不附流程/时序图。
在「页面结构与交互」「业务逻辑与状态流转」「异常与边界」中，按元素类型强制应用以下规范。
必须明确：1. 初始化条件 → 2. 默认态 → 3. 触发指令（单击/长按等）→ 4. 执行中过程态（防抖/加载动画）→ 5. 执行异常（提示与重试）→ 6. 执行成功（跳转/刷新/状态变更）。
当用户要求出可点击原型时，优先使用结构化 Spec 作为输入，而不是直接消费长 PRD。执行建议：
目标项ID（feature_id 或 module_id） + spec_version 与原型目录约定；原型设计应遵循“可验证最小闭环”原则：本轮只覆盖当前 Story 的关键流程、必要状态和核心边界。
product-featurelist skill 在 Feature List 中补齐；若当前环境不存在该 skill 或不适合立即回补，则在 PRD Header 中标注「待补充」，并在「依赖与待定项」或等价章节中说明缺失原因与补齐责任。执行本 skill 时须按以下规则与顺序操作，与「文档结构」「写作铁律」中的按编号拆分、默认一对一、有限合并一致：
禁止全量一次性生成
先确定本轮目标项：优先按用户明确指定的 目标项ID（feature_id 或 module_id）/模块 执行；若用户未指定，再从 Feature List 中选择 Ready=Yes 且优先级最高的条目。
先访谈收敛（阻断步骤）：先输出访谈问题并等待用户回答；在用户回答并确认《已确认事项/待确认项/冲突点》前，禁止创建或更新 PRD 文件。
列编号与模块映射：根据 Feature List 列出本轮待写 PRD 的编号及所属模块；默认每个编号对应一篇 PRD 文件，仅在满足强耦合条件且在索引表/README 中明确声明为一小组时，才规划为「一小组合并一篇」，确保文件按编号拆、目录按模块分。
先列模块功能清单与 Story级编号：进入正文前，先输出本篇覆盖的「模块功能清单」，并为每条 Story 分配唯一编号（如 模块编号-S01）；后续正文必须与该清单逐条对应。
按编号粒度调用：一次只针对一条或一小群紧密相关的 FeatureList 编号生成/完善对应的单篇 PRD；不得为「整个模块」或「减少文档数」产出「一篇挂多编号」的 PRD。
模块目录 + Story 小节：按模块建目录，在每个目录下保存单篇 PRD；篇内必须按 Story 拆分小节，且每个 Story 可测试、可验收、可形成最小闭环。
拆到最小 Story：当一条 FeatureList 包含多个相对独立的业务 Story 时，应优先在 FeatureList 中拆分编号，再分别生成 PRD，避免在一个 PRD 中挂多个松散 Story。
迭代过程：新增功能默认新建 _PRD.md；仅在索引表/README 已明确界定为一小组且满足强耦合标准时，才允许合并覆盖多条编号。
以下示例展示了本 skill 推荐的写作风格与颗粒度，均以产品经理视角描述界面、交互、规则与异常，而不涉及具体技术实现细节。
用途：演示如何为一个简单控件（按钮）撰写完整的交互与状态流转说明，包含生命周期六步法与异常/边界场景。
提示：如需补充状态机图，可在本节后附 PlantUML 状态机，不强制。
用途：演示列表+筛选+异步导出功能的写法，强调字段展示、隐私脱敏、异步导出闭环。
管理员进入证书列表 → 组合筛选目标考生 → 触发异步导出指令 → 系统后台生成文件 → 管理员在消息中心获取反馈并下载文件。
138****8888）；110**********23）。列表右侧的「证书状态」字段，需根据后台实际处理进度，严格按照下表进行视觉与状态映射：
| 后台证书状态 | 前端显示文案 | 图标 (Icon) | 视觉风格 (Color) |
|---|---|---|---|
| 批改中 | 「批改中」 | 旋转加载圈 | 橙色（警告色） |
| 待复核 | 「证书复核中」 | 双对勾 | 蓝色（常规色） |
| 制作中 | 「证书制作中」 | 打印机 | 靛青色（主色调） |
| 已寄送 | 「证书已寄送」 | 运输包裹 | 绿色（成功色） |
「导出数据」按钮及关联流程，严格遵循以下生命周期：
用途：演示动态表单、字段联动与批量赋分规则的写法。
教师进入题目详情 → 录入题目描述 → 唤起测试用例配置弹窗 → 根据题型选择检查逻辑（运行比对或正则匹配）→ 保存配置 → 在试卷模块进行批量赋分。
弹窗标题为「测试用例」，包含以下通用字段与联动字段：
B * X，教师修改 X 时实时更新。X 分，学生得分对应的等级阈值自动计算如下（四舍五入保留一位小数）：
用途：演示 B 端编辑表单 + 详情比对页的写法，强调只读字段、级联选择与比对展示规则。
用户在车辆管理列表按条件组合筛选目标车辆 → 进入新建或编辑页绑定车辆识别代码（VIN）与出厂标准配置 → 在车辆详情页对比车端实际上报数据与系统标准配置 → 向车端下发远程控制指令并监控反馈日志。
在「ECU 信息」标签页中，需要将「标准配置要求」与「车端实际上报数据」合并为同一张表格展示。对于零件号、硬件号、硬件版本等核心参数单元格，执行以下比对渲染规则：
在「远程控制」标签页内，用于向车端下发强制重启、日志上传等指令。