Product Plan Guide

产品经理产品方案产出指南

Overview

本技能将一份结构化的产品经理方法论转化为可执行的工作流。当用户提出任何产品需求或方案产出任务时，先识别该需求属于 5 类场景中的哪一类，再按对应场景的产出清单和通用模板生成完整、可执行的产品文档。

详细的方法论、各场景产出清单、文档核心要点、通用模板、提示词模板、质量检查清单均存放在 references/产品方案产出指南.md，在执行前必须读取对应章节。

触发条件

当出现以下任一情况时触发本技能：

• 用户提出一个产品需求或想法，需要产出方案文档
• 用户提到"写PRD""产品方案""需求规划""功能设计""需求文档"等关键词
• 用户描述一个业务场景，需要判断该做什么程度的产品工作
• 用户要求做市场调研、竞品分析、可行性分析、埋点方案、上线方案
• 用户说"这个需求怎么做""帮我规划一下""出个方案"

记忆系统

本技能的完整记忆管理规则（写日志/轮转归档/自清理）定义在 references/记忆规则.md，执行前必须读取。

• 执行前（必须）：读取 references/记忆规则.md 中的 Step 0 加载规范 + .skills-memory/MEMORY.md 本技能对应分段 + .skills-memory/YYYY-MM-DD.md（今日日志，如存在）
• 执行后（硬性要求，不可跳过）：追加 [product-plan-guide] 场景描述 → 关键决策 到 .skills-memory/YYYY-MM-DD.md；如有可复用决策，去重后追加到 MEMORY.md 对应分段。记忆写入是交付物的一部分——如果因环境限制无法写入，必须在最终回复中明确告知用户「记忆未写入」及原因，不得静默跳过
• 轮转检查：
  • 独立使用：按 references/记忆规则.md 中的触发条件和完整轮转算法执行归档
  • 被 team-orchestrator 调度时：跳过全部记忆操作（写入 + 轮转），由调度官 Step 6（写日志）/ Step 7（轮转归档）统一处理

执行流程

按以下 5 步顺序执行，不可跳步。

Step 1: 需求理解

• 解析用户输入的需求描述
• 提取关键信息：业务背景、目标用户、功能范围、预期周期、是否全新产品
• 识别缺失的关键信息，主动向用户提问补全（一次最多问 2-3 个最关键的问题，避免轰炸式提问）

Step 2: 场景识别

读取 references/产品方案产出指南.md 的"一、场景识别"章节，用下表判断需求属于哪类场景：

识别流程：是否全新产品？→ 场景一；是否大版本升级？→ 场景四；是否方向探索？→ 场景五；是否多页面多角色？→ 场景二；否则 → 场景三。

Step 3: 与用户确认场景

输出场景判断结果，包含：

1. 场景判断：场景X（场景名称）
2. 判断依据：逐条对照说明
3. 建议产出清单：列出将生成的必备文档
4. 预估周期：X 天/周/月

向用户确认："判断为场景X，将产出以下文档：...，是否确认？如有补充信息请告知。" 等用户确认后再进入产出阶段。用户可能补充信息导致场景变更，需重新判断。

Step 4: 按清单产出文档

读取 references/产品方案产出指南.md 中对应场景的章节，获取：

• 该场景的必备产出清单（文档名称、阶段、优先级）
• 每个文档的核心要点
• references/产品方案产出指南.md 的"七、通用文档模板"章节提供的模板格式

专家蒸馏增量（2026-09-06 并入·闪造造）：方案文档产出后如需快速验证假设（把想法/PRD 变成可运行 demo 给用户试、用数据验证而不只是文档自嗨），读取 references/expert-distill/rapid-prototyping-蒸馏.md（快速原型验证方法论：5 场景 / 3 天交付节奏 / Next.js 快速栈 / 埋点+反馈+A/B 三件套 / 转生产判断）。原型验证属产品经理"验证闭环"的一部分，正式工程开发交给 frontend/backend-dev-guide。功能优先级与 MVP 范围决策时，另读取 references/expert-distill/mvp-pm-蒸馏.md（许清楚：RICE 量化排序 / MVP 只保留 1-3 个功能纪律 / 必埋事件五类表 / 竞品分析看差评）。

产出要求：

• 按阶段顺序生成：调研 → 规划 → 设计 → 落地 → 验证
• 使用通用模板的格式（PRD/BRD/MRD/埋点方案/上线方案模板）
• 每个文档内容完整、逻辑清晰、可执行
• 每段不少于 3-5 句，每节不少于 150-200 字，避免空洞
• 文档间逻辑一致，无矛盾
• 必须读取并应用"十、超越AI味：产品经理的真实判断力"：产出方案时逐条对照反AI产品决策五条，量化产品直觉，使用「人说人话」规则写需求描述
• 设计友好型 PRD（硬性要求·五维交付）：§5.4 页面层级图（按产品架构分组+编号）→ §5.6.1 代表作 1 页完整五维（信息结构表六列+树形设计指导像素级+交互状态表≥4态+异常≥3种+视觉约束）→ §5.6.2 简化表其余全页（📋/📐/🖱️/⚠️ 4行）→ §5.6.3 视觉总纲 → §5.6.4 异常速查 → §5.7 强制核对。四维验收标准：一数页面（5.4 页面层级图，设计师知道画多少页）、二明内容（5.6.1①信息结构表+5.6.2📋行，每页展示什么信息由哪些模块组成）、三懂交互（5.6.1③交互状态表+5.6.2🖱️行，用户如何操作系统如何反馈）、四合约束（5.6.3视觉总纲+5.6.4异常速查，品牌和体验规范）——达到此标准即使没有线框图和原型，设计师也能高效准确地开展设计工作，减少返工和沟通成本。§5.6.5 HTML 呈现（可选增强·设计转代码 PM 版）：将树形像素级描述渲染为可运行页面（线框级/高保真级）+ iframe 切片 + focus 专注模式 + 像素对齐校验，浏览器直接打开预览，无需 Figma/Ardot。页面≤5页单文件三端并排，>5页用 iframe 切片+focus 逐页聚焦。⚠️ 两条硬规则：①必须单文件自包含——子页面用 <template> + iframe.srcdoc 内联，禁用 iframe src= 外部引用（单文件预览环境会全部空白）；②Web 端切片必须设 min-width≥820px，否则 flex 布局下 iframe 塌缩到 300px 导致 Web 后台显示成移动端尺寸（App/小程序切片固定 375px）。生成后强制执行像素对齐校验 5 项（颜色/尺寸/圆角间距/字号/三端），附对齐报告。
• 开发可执行型 PRD（硬性要求）：§5.2 功能详述每功能点附验收标准 AC（Given/When/Then ≥2条）→ §6.4 状态机定义（状态清单+合法流转+触发条件+终态，凡有状态流转的实体必填）→ §7.1 字段定义（类型具体到 varchar/int/decimal/enum/boolean/datetime，禁止"文本""数字"笼统写法）→ §8.5 权限矩阵（多角色产品必填，角色×功能增删改查）。达到此标准研发不追问即可开工——字段有类型、状态有流转、做完有验收、权限有边界。
• 产出后保存为 Markdown 文件，命名规范：{项目名}_{场景编号}_{文档类型}_{版本号}.md

Step 5: 质量检查

读取 references/产品方案产出指南.md 的"九、产出质量检查清单"章节，对照检查：

• 场景判断是否正确并已与用户确认
• 产出清单是否完整（必备文档全部生成）
• 文档格式是否规范（Markdown、层级清晰）
• 内容深度是否达标（每段3-5句、每节150-200字）
• 逻辑是否连贯（文档间无矛盾）
• 是否可执行（能直接用于开发/测试/上线）
• PRD 专项：功能架构图完整（模块→子模块→功能点）、五维交付达标（5.4页面层级图三端三层分组、5.6.1代表作1页五件套齐全、5.6.2简化表其余全页覆盖、5.6.3视觉总纲14项参数齐全、5.6.4异常速查每页≥3种、5.6.5 HTML线框可选增强）、5.7强制核对通过（五行核对结果，含可选项）、流程图含主流程/异常/分支、开发可执行四件套（5.2验收标准AC每功能点≥2条、6.4状态机含流转表、7.1字段类型具体、8.5权限矩阵多角色必填）、埋点用表格
• 上线方案专项：灰度策略明确、回滚方案可执行、监控告警已定义、应急预案含分级
• 数据方案专项：北极星指标单一、KPI已拆解、埋点覆盖关键路径、A/B测试方案完整
• 去AI味：至少2处「不做」决策、优先级有倾斜、竞品分析有立场、无万能废话、需求说人话

记忆已写入（.skills-memory/YYYY-MM-DD.md 有本次会话条目，无则立即补写）

识别遗漏内容并补充，最后输出交付清单（列出所有生成的文档及路径）。

资源说明

references/产品方案产出指南.md

完整的方法论文档，包含：

• 场景识别决策表与流程图
• 5个场景的详细产出清单与各文档核心要点
• 通用文档模板（PRD/BRD/MRD/埋点方案/上线方案）
• AI 工具使用建议（提示词模板、工作流）
• 产出质量检查清单（含去AI味检查）
• 超越AI味：产品经理的真实判断力（反AI决策五条/产品直觉量化/人话规则）
• HTML 线框呈现 + iframe 切片（§5.6.5，可选增强：树形描述→HTML 线框可视化+iframe 切片+focus 专注模式）

在 Step 2（场景识别）、Step 4（产出文档）、Step 5（质量检查）时必须读取对应章节。文档较大（约 1100 行），按需读取对应章节而非全量加载：

• 场景识别：读取"一、场景识别"
• 产出文档：读取对应场景章节（二至六）+ "七、通用文档模板" + "十、超越AI味：产品经理的真实判断力"
• 质量检查：读取"九、产出质量检查清单"

注意事项

• 不要跳过 Step 3 的用户确认环节，直接产出可能方向错误导致返工
• 用户信息不足时主动提问，但控制提问数量（单次不超过 3 个）
• 场景三（小优化）不要过度产出，2-3 类文档足够，避免形式主义
• 场景一（0到1）和场景四（大版本）产出量大，建议分轮次生成，每轮确认后再继续
• 模板是骨架不是枷锁，结合具体业务灵活填充，避免填空式空洞内容

岗位职责与产出标准（业界锚点 · 2026-08 学习）

现实岗位职责：①需求管理——市场调研/用户访谈/竞品分析收集需求，辨别真伪并排优先级；②产品规划——路线图、立项、版本迭代计划；③跨部门协调——研发/设计/测试/市场信息通路建设，作为唯一 owner 推进落地；④项目管理——排期、跟进答疑、异常处理、UAT 验收；⑤运营复盘——上线后数据监控（留存/转化）、反馈驱动迭代。

业界产出标准：BRD（商业模式与资源需求）→ MRD（市场需求+用户画像）→ 需求池（带 KANO/ICE 优先级标注）→ 原型（Axure/Figma）→ 结构化 PRD（含验收标准+异常处理）→ 需求评审纪要 → 上线计划 → UAT 测试报告 → 数据复盘报告。质量要求：PRD 可执行性（研发不追问即可开工）、需求可追溯、异常场景不遗漏。

交付衔接：PRD交付给UX设计师（用§5.4~5.7五维交付即可开工，§5.6.5 HTML线框可选增强提供可视化预览）+ 前端/后端开发（用§5.1功能清单+§5.2验收标准AC+§6.4状态机+§7数据规则(字段类型)+§8.5权限矩阵编码，研发不追问即可开工）