pm-prd

用途

pm-prd 用于从一段功能描述生成可直接交付的 PRD（产品需求文档）。它属于 Personal Corp 框架，该框架用于通过 AI 智能体运营一人公司。生成过程会按产品类型分支，不同类型强调不同模块，并在生成后执行 10 项质量自检。

输入字段

功能描述：必填。说明功能做什么、解决什么问题，至少一句话。
目标用户：选填。不提供时从功能描述推断。
业务目标：选填。预期业务指标，如 DAU、转化率、收入等。
产品类型：选填。B2C / B2B / internal / platform，不提供时自动识别。
约束条件：选填。技术限制、截止时间、资源限制。
深度：选填。Outline（用于评审）/ detailed（用于开发），默认 detailed。

如果用户只说“写一份 PRD”而没有功能描述，技能会先询问功能描述；如果已给出功能、用户和目标，则直接生成。

主要能力

按产品类型分支

B2C：强调 UX 流程、增长指标、A/B 测试计划；重交互、重数据，撰写用户旅程。
B2B：强调权限模型、多租户、SLA、集成 API；重完整性、安全性、API 契约。
内部工具：强调运营效率、与现有系统集成、培训成本；重实用性，轻视觉。
平台：强调多角色交互、供需匹配、生态规则；重角色分离、规则引擎。

自动识别规则：提及“user / member / loyalty / marketplace”归为 B2C；提及“enterprise / SaaS / CRM / admin panel”归为 B2B；提及“internal / management system / ticketing”归为内部工具；提及“platform / marketplace / two-sided”归为平台。

B2B PRD 必须额外覆盖：权限矩阵（角色 × 功能 × 数据范围）、多租户数据隔离方案、与客户现有系统的集成接口。

平台 PRD 必须额外覆盖：每个角色（供应方 / 消费方 / 平台运营）的独立功能视图、匹配规则与排序策略、佣金 / 抽成 / 结算规则。

结构化需求拆解

采用三种方法拆解功能：

用户旅程：追踪用户从进入到完成目标的路径，每个节点对应一个功能点。
角色拆分：列出涉及的所有角色（终端用户、管理员、运营），每个角色的操作对应一个功能模块。
CRUD：对每个核心数据对象，走查创建、读取、更新、删除。

每个功能模块需填写：功能描述（一句话）、用户故事（作为 {角色}，我希望 {操作}，以便 {价值}）、业务规则（穷举，不写“等等”或“其他情况”）、交互流程（入口 → 步骤 → 成功/失败反馈）、异常处理（超时、数据异常、权限拒绝、边界情况）。

PRD 模板结构

生成的文档包含以下章节：

背景与目标：背景（为何现在做、不做会怎样、做了会改变什么）、目标用户（角色 + 特征 + 场景，不写“所有用户”）、业务目标与成功指标（SMART 化，含具体数字与截止时间）。
需求概览：一段话，最多 30 词，概括核心需求。
详细功能设计：每个模块含描述、用户故事、优先级（P0 必须上线 / P1 强烈建议 / P2 锦上添花）、业务规则、交互流程、异常处理表。
非功能需求：性能、安全、兼容性等，含验收标准。
数据需求（埋点事件）：事件名 + 触发时机 + 属性 + 目的。
验收标准：每个功能模块至少 3 条，采用 Given-When-Then 格式。
排期：设计 / 开发 / 联调 / 上线各阶段，含估算、依赖、风险。
风险与依赖：概率、影响、缓解措施。附录：相关文档、竞品参考、设计文件。

生成后质量自检

生成后运行 10 项检查，未通过项会标记并给出修复建议：

背景不空泛：回答“为什么做”，而不只是“我们需要做”。
目标可量化：至少一个数字化的成功指标。
用户画像具体：不出现“所有用户”“每个人”。
业务规则穷举：不出现“等等”“其他情况”“诸如此类”。
异常流程覆盖：每个功能至少 2 个异常场景。
验收可测试：使用 Given-When-Then 格式。
埋点完整：所有核心操作路径都有事件。
不涉及技术实现：描述“做什么”，而非“怎么建”。
优先级已分配：每个模块标注 P0/P1/P2。
排期有依据：估算覆盖设计 + 开发 + 测试 + 联调。

使用方式

向技能提供功能描述即可生成。可附带目标用户、业务目标、产品类型、约束条件、深度等选填信息以提升针对性。若只要求“写一份 PRD”但未给功能描述，技能会先索要功能描述并给出示例；若只有一句话需求（如“建一个交易市场”），会产出大纲级 PRD 框架，并在关键缺失处标记 [需要输入]；若需求过大，会建议拆分为多份 PRD，先就 MVP 范围达成一致。

适用场景

适用于产品经理或独立开发者需要从功能想法快速产出结构化、可交付 PRD 的场合，尤其适合需要按 B2C、B2B、内部工具、平台不同类型差异化覆盖模块的项目，也适合在评审前生成大纲级文档。

限制与红线

PRD 不指定实现：不写数据库类型、语言、框架。
PRD 不替代设计稿：不写详细 UI 布局、颜色、尺寸。
不编造数据：用户未提供的业务数据（DAU、转化率等）写 [TBD]。
不遗漏角色：多角色功能必须覆盖每个角色的视角。
常见反模式会被规避：镀金（v1 塞 50 个功能，应拆分 MVP/v1.1/v2，v1 保留 3-5 个核心功能）、伪需求（“用户可能想要”但无数据，应标注来源：反馈 / 分析 / 竞品 / 假设）、设计越界（规定按钮颜色、字号、布局）、技术越界（规定 Redis、MySQL、框架）、规则黑洞（写“按业务规则”却不列出规则）。

技能介绍

用途