write-prd

name write-prd description 输入一个产品 idea（一句话或详细描述均可），自动生成图文并茂、结构完整的 PRD（产品需求文档），以 Markdown 格式保存到当前项目 markdown/ 目录，同时输出配套 SVG 图表文件。触发条件：用户提到"写 PRD"、"帮我写需求文档"、"生成 PRD"、"写产品需求文档"、"写商业需求文档"、"我有个产品想法"、"帮我把这个 idea 写成文档"、"PRD 模板"、"产品立项文档"、"产品需求"、"功能需求文档"。即使用户只给出一句简短的产品描述如"我想做一个 XX 产品"，也应立即使用本 skill 生成 PRD。本 skill 面向产品经理、创业者、产品负责人，输出可直接用于团队评审和立项决策的专业文档，深度整合 JTBD 用户洞察框架、MoSCoW 优先级方法论和北极星指标体系。 Write PRD Skill 将一个产品 idea 转化为完整、可直接评审的 PRD（Product Requirements Document）。 核心理念：PRD 是团队在不确定性中的共同契约。它的价值不在于格式，而在于把 WHY → WHAT → HOW → MEASURE 四个维度讲清楚。 工作流总览 用户输入 Idea ↓ Step 1: 信息补全 & JTBD 推演（不急于提问，先推断） ↓ Step 2: 搜索市场背景与竞品（web search） ↓ Step 3: 生成配套 SVG 图表（独立文件） ↓ Step 4: 生成完整 PRD Markdown 文件 ↓ 输出到 markdown/ 目录 Step 1：信息补全与 JTBD 推演 拿到用户的 idea 后， 不要立刻问问题 ，先做推演： 1.1 JTBD 框架推断用户痛点 用以下格式在内部推断，不要直接展示给用户： 当 [目标用户] 在 [特定场景] 时， 他们需要 [完成某项工作/达到某个目标]， 但目前面临 [具体障碍]， 导致 [可量化的业务/体验影响]。 1.2 五维推断清单 目标用户 ：谁会用这个产品？主用户 vs. 次要用户区分 核心痛点 ：用 JTBD 格式描述，不是"用户想要功能"，而是"用户想完成什么任务" 商业模式 ：产品如何盈利？服务于什么更大的商业目标？ 差异化 ：和竞品相比，核心的差异化价值主张是什么？ 成功指标 ：什么数字能证明这个产品成功了？（北极星指标） 1.3 推断优先于询问 如果信息足够推断，直接进入 Step 2 在 PRD 中用 [待确认] 标注推断字段 如需询问， 一次性问不超过 3 个 最关键的问题后再执行 Step 2：搜索市场背景（使用 web_search） 搜索以下信息，充实 PRD 背景章节： 市场规模 ： [产品领域] market size 2024/2025 主要竞品 ： [产品类型] top competitors features comparison 行业趋势 ： [用户痛点] trends [当前年份] 参考案例 ： [类似产品] success failure case study 搜索后提炼关键数据点，填入 PRD 对应章节。 Step 3：生成 SVG 图表 必须生成以下至少 2 个 SVG 图表 ，保存到 markdown/ 目录： 图表 A：产品功能架构图（必选） 展示核心功能模块及其层级关系。 文件名： [product-name]-architecture.svg 风格：分层色块 + 箭头，清晰展示模块间关联 必须包含：用户层、功能层、数据层（或类似的三层结构） 图表 B：核心用户旅程图（必选） 展示用户从发现问题到完成目标的完整路径， 必须包含异常路径 。 文件名： [product-name]-user-journey.svg 风格：横向流程 + 状态标注 + 情绪曲线（可选） 必须包含：触发点、关键节点、决策分叉、异常处理、成功终态 图表 C（视产品类型选择其一）： 竞品对比矩阵 （有明确竞品时）： [product-name]-competitor-matrix.svg 数据流图 （技术型/数据型产品）： [product-name]-data-flow.svg 商业模式关键要素 （B端/平台类产品）： [product-name]-business-model.svg SVG 技术规范 viewBox="0 0 860 [适当高度]" font-family="'PingFang SC', 'Helvetica Neue', Arial, sans-serif" 使用 defs 定义 linearGradient 和 filter shadow 配色方案： 主色：#4f46e5（靛蓝）或 #0f766e（深青） 成功/正向：#10b981（绿） 警告/注意：#f59e0b（琥珀） 错误/风险：#ef4444（红） 辅助文字：#64748b 背景：#f8fafc 或 white 每个图表包含：标题行 + 图例（如有）+ 内容 + 底部说明 SVG 必须独立保存为文件，在 Markdown 中用 ![说明](filename.svg) 引用 Step 4：PRD Markdown 文件结构 文件命名： [product-name-en]-prd.md （英文小写，连字符分隔） 完整 PRD 模板 # [产品名称] PRD > [一句话定位：这个产品为谁解决了什么问题，通过什么方式，预期带来什么价值] **文档类型** ：PRD（产品需求文档） **文档状态** ：草稿 / 评审中 / 已批准 **版本** ：v1.0 **作者** ：[PM 姓名] **最后更新** ：[日期] **阅读时长** ：约 X 分钟 --- ## 一、执行摘要（Executive Summary） [3-5句话的高管版摘要，包含： - 我们在解决什么问题（问题规模） - 我们的解决方案是什么（一句话） - 成功后能带来什么商业价值（量化预期）] --- ## 二、问题定义 ### 2.1 背景与现状 [市场背景，数据支撑，不超过200字。来自 Step 2 搜索结果] ### 2.2 用户痛点（JTBD 框架） **当** [目标用户] **在** [使用场景] **时，** 他们需要 [完成某个任务/达到某个目标]， 但目前面临 [具体障碍]， 导致 [业务/用户体验影响，尽量量化]。 ### 2.3 目标用户 **主要用户群体** ：[描述] **用户画像** ： - 人口属性：[年龄 / 职业 / 地域 / 数字化程度] - 核心使用场景：[什么时候、在哪里、为什么用] - 当前替代方案：[他们现在怎么解决这个问题] - 最痛的三个点：[按严重程度排序] ### 2.4 市场机会 | 指标 | 数值 | 来源 | |------|------|------| | TAM（总可寻址市场） | | [来源] | | SAM（可服务市场） | | [来源] | | SOM（可获取份额） | | 推断 | | 市场增长率 | | [来源] | --- ## 三、解决方案 ### 3.1 产品定位 > 我们是 **[产品类型]** ，帮助 **[目标用户]** **[核心价值主张]** ，不像 **[竞品]** ，我们 **[差异化]** 。 ### 3.2 功能架构 ![ 功能架构图 ]( [product-name]-architecture.svg ) *[一句话说明图的阅读方式]* ### 3.3 核心功能（MoSCoW 优先级） > ⚠️ 注意：Must Have 应严格控制，"所有功能都是 Must"意味着 PRD 未完成取舍。 #### ✅ Must Have（MVP 必须包含，缺失则不可上线） | 功能 | 用户故事 | 验收标准 | 优先级 | |------|---------|---------|--------| | [功能1] | As a [用户类型], I want [行为], so that [目的] | Given [前置条件] When [用户操作] Then [系统响应+性能指标] | P0 | #### 🔶 Should Have（重要但 MVP 可简化版本交付） | 功能 | 用户故事 | 优先级 | |------|---------|--------| | [功能] | As a [用户], I want [行为], so that [目的] | P1 | #### 🔷 Could Have（有余力再做，不影响核心价值） - [功能列表，简述即可] #### ❌ Won't Have（本期明确不做——这行和上面同等重要） | 功能 | 排除原因 | |------|---------| | [功能] | [资源限制 / 复杂度过高 / 非核心路径] | ### 3.4 核心用户旅程 ![ 用户旅程图 ]( [product-name]-user-journey.svg ) *[说明图中的关键决策节点和异常路径处理]* ### 3.5 非功能需求 | 维度 | 要求 | 验证方式 | |------|------|---------| | 性能 | [页面加载 ≤ Xms / P95 响应时间 ≤ Xms] | 压测 / 监控 | | 安全 | [数据加密标准 / 合规要求] | 安全审计 | | 可用性 | [99.X% Uptime SLA] | 监控告警 | | 扩展性 | [支持 X 并发用户 / X QPS] | 架构评审 | | 兼容性 | [支持的平台/浏览器版本] | 兼容性测试 | --- ## 四、竞品分析 [竞品对比，说明差异化优势。如生成了竞品矩阵 SVG，在此引用] | 维度 | 我们 | 竞品A | 竞品B | |------|------|-------|-------| | 核心功能 | | | | | 目标用户 | | | | | 定价模式 | | | | | 差异化 | ✅ | | | --- ## 五、成功指标 ### 5.1 北极星指标（North Star Metric） > **[唯一最重要的指标名称]** ：[具体计算口径] > > 选择理由：[为什么这个指标能同时反映用户价值和商业价值] ### 5.2 分层指标体系 **输入指标** （你能直接影响的）： | 指标 | 基线 | 目标值（3个月） | 观测周期 | |------|------|--------------|---------| | [核心功能使用率] | | | 周 | | [核心流程完成率] | | | 周 | | [用户留存率] | | | 月 | **护栏指标** （不能因为优化北极星而损害的底线）： | 指标 | 红线 | |------|------| | 错误率 | ≤ X% | | 投诉率 | 不高于基线 | | 核心链路可用性 | ≥ 99.X% | ### 5.3 实验设计 - **A/B 测试方案** ：[实验组 vs. 对照组的划分逻辑] - **最小可检测效果（MDE）** ：[能检测到多大的指标变化] - **实验周期** ：[X 周，需避开节假日和大促干扰] - **灰度策略** ：5% → 20% → 50% → 100% - **回滚条件** ：[出现什么数据信号（具体数字）立即停止并回滚] --- ## 六、执行计划 ### 6.1 范围边界 **In Scope（本期包含）** ： - [功能/能力列表] **Out of Scope（本期不做——和功能清单同等重要）** ： - [明确排除的功能，及原因：资源/复杂度/战略优先级] ### 6.2 里程碑 > 里程碑 = 可验证的交付物，不是时间点 | 阶段 | 可验证交付物 | 时间节点 | 负责人 | |------|------------|---------|--------| | Discovery 完成 | 用研报告通过 + 竞品分析输出 | [日期] | PM | | 设计评审通过 | 高保真原型 + 核心流程走通 | [日期] | Design | | 技术方案确认 | 架构评审 + 技术风险识别 | [日期] | Tech Lead | | MVP 开发完成 | 核心 P0 功能通过 UAT | [日期] | 全团队 | | 灰度上线 | 5% 用户 + 监控正常 | [日期] | PM + Dev | | 全量上线 | 指标验证通过 | [日期] | PM | ### 6.3 资源需求 | 角色 | 工作量（人天） | 主要职责 | |------|-------------|---------| | 产品经理 | | 需求管理、跨团队协调、指标追踪 | | 设计师 | | 原型设计、交互规范 | | 前端工程师 | | | | 后端工程师 | | | | 测试工程师 | | 测试方案、UAT | --- ## 七、风险评估 | 风险类型 | 具体风险描述 | 可能性 | 影响程度 | 应对方案 | |---------|------------|--------|---------|---------| | 技术风险 | [如：第三方 API 稳定性] | 中 | 高 | [降级方案 + SLA 协议] | | 市场风险 | [如：竞品抢先上线] | 低 | 高 | [差异化策略] | | 资源风险 | [如：关键工程师离职] | 低 | 中 | [文档化 + 知识转移] | | 合规风险 | [如：数据隐私合规] | 低 | 极高 | [法务提前介入] | | 假设失效风险 | [如：用户访谈结论有偏差] | 中 | 高 | [MVP 快速验证 + 预设回滚] | --- ## 八、干系人与审批 ### 8.1 RACI 矩阵 | 事项 | PM | 工程 | 设计 | 运营 | 法务 | 管理层 | |------|----|----|------|------|------|------| | 需求确认 | R | C | C | C | I | A | | 技术方案 | C | R | I | | | I | | 设计评审 | A | C | R | C | | I | | 上线决策 | R | C | C | C | C | A | | 数据验收 | R | C | | C | | I | *R=负责执行 A=最终拍板 C=需要咨询 I=需要知会* ### 8.2 审批记录 | 干系人 | 角色 | 意见摘要 | 签字日期 | |--------|------|---------|---------| | | | | | --- ## 九、附录 ### 9.1 关键假设清单 > [待确认] 标记的字段，上线前需确认 | 编号 | 假设内容 | 验证方式 | 状态 | |------|---------|---------|------| | A1 | [如：用户愿意为此付费] | 用户访谈 / MVP 验证 | 待确认 | ### 9.2 术语表 | 术语 | 定义 | |------|------| | [专有名词] | [定义] | ### 9.3 参考文档 - [ ] 用户研究报告：[链接] - [ ] 竞品分析报告：[链接] - [ ] 技术可行性评估：[链接] - [ ] 数据分析报告：[链接] - [ ] 法务合规意见：[链接]