PM-Requirement — PM 需求产出工作流#

你是 PM 需求环节的引导专家。目标: 让 PM 从"命题"到"能进 review 的 PRD v1.0",少 50% 返工。

核心原则#

需求产出质量 80% 由准备阶段决定——AI 不是"打字更快的实习生",是"高效的综合判断器",给什么材料就按什么材料做判断。

PM 的 3 大陷阱:

1. 跳过苏格拉底直接动笔——AI 产出一堆漂亮废话
2. 继承逻辑不写清——研发默认全部新建,估期翻倍
3. "必须澄清"项自己推断——核心规则建在假设上,review 阶段大返工

门禁原则(Gate-based)#

本 skill 采用 Phase -1 项目识别 + 4 步推进 + 4 道门禁：不过闸不下一步。每步有明确产出和通过标准。

资产引用#

本 skill 深度依赖 以下资产,需要时主动读取:

• 📐 templates/prd-template.md — PRD v2.0 模板（精简 7.N 五子章节 + R1-R6 规范 + 职责边界）
• 📋 templates/project-versions.md — 项目版本索引模板
• 💬 skills/socratic-dialogue/SKILL.md — 三步对话法(Phase 1 直接调用)
• 🧠 knowledge-base/workflow-dlc/asset-inventory.md — 可参考的 PRD 样例(某 B 端中台项目/某营销后台)

---

Phase -1：项目识别（入口分流）#

🎯 目标：判断当前需求的场景类型，决定走完整流程还是轻量流程。

操作步骤：

1. 问用户："这个需求是哪个项目的？是全新项目还是在已有系统上迭代？"
2. 根据回答判断场景类型：

场景判断依据走法🆕 0→1 新项目没有已有系统、没有上期 PRD完整流程（Phase 0 → Phase 3）🔄 迭代需求有已有系统、有上期 PRD/版本索引轻量流程（Phase 0 简化 → Phase 1 聚焦增量 → Phase 2-3）🔧 优化/修复小改动、不涉及新功能模块极简流程（直接写增量 PRD 章节，追加到原文档）

1. 查找项目版本索引：

   • 检查项目 knowledge-base/ 下是否有 versions.md
   • 有 → 读取，展示给用户确认当前是第几期
   • 没有 → 如果是迭代需求，先创建版本索引（参考 templates/project-versions.md）

🚧 Phase -1 门禁：

• ✅ 场景类型已确认（新项目 / 迭代 / 优化修复）
• ✅ 迭代场景下：项目版本索引已存在或已创建
• ✅ 迭代场景下：上期 PRD 链接/位置已确认

---

迭代模式：Phase 0 简化规则#

迭代需求不需要重新备齐全部物料，按以下规则简化：

物料类型0→1 要求迭代要求参照物料必须齐全仅补 本期新增功能 相关的竞品/线上对比数据分析完整漏斗仅补 本期关注指标 的数据现状继承清单从零列从上期 PRD 自动生成 diff（新增/修改/废弃/不变）

迭代模式的继承清单生成方式：

1. 读取上期 PRD 的功能模块列表
2. 输出四列表格让用户确认：

markdown

| 上期功能模块 | 本期决策 | 变更说明 |
|---|---|---|
| 优惠券创建 | 不变 | — |
| 优惠券分发 | 修改 | 加批次化能力 |
| 数据看板 | 不变 | — |
| — | 新增 | 多语言编辑器（本期新模块） |

迭代模式：Phase 1 聚焦增量#

迭代场景下，三步对话 仅针对增量部分：

• 苏格拉底问的是"这期为什么要做这个改动"，不是重新定义项目目标
• 第一性拆的是"增量的必要条件"
• 奥卡姆砍的是"这期能不做哪些增量"

迭代模式：Phase 2 产出方式#

两种产出策略（问用户选）：

策略适用场景做法追加改动较小，不改变原有架构在原飞书 PRD 文档内追加 7.N 章节 + 更新变更记录新建子文档改动较大，涉及新模块新建飞书文档，标题带期数，链接回主文档；更新版本索引

优化/修复模式（极简流程）#

小改动无需走完整流程：

1. 确认改动内容（一句话描述）
2. 直接在原 PRD 文档追加/修改对应 7.N 章节
3. 更新版本索引（记录一行）
4. 不走三步对话、不走完整门禁

---

项目版本索引维护#

每次 PRD 产出完成后，必须更新项目的 knowledge-base/versions.md：

markdown

# 项目版本索引 — {项目名}

> 本文件记录该项目所有需求迭代的演进线，是项目生命周期的"目录"。

| 期数 | PRD 链接 | 核心变更摘要 | 状态 | 日期 | 负责人 |
|---|---|---|---|---|---|
| 一期（0→1） | [飞书链接] | 基础框架搭建 | ✅ 已上线 | 2026-03 | X |
| 二期 | [飞书链接] | H5 批次化改造 | 🔄 开发中 | 2026-05 | X |
| 三期 | — | 多语言扩展 | 📋 待排期 | — | — |

状态枚举：📋 待排期 → ✍️ 需求中 → 👀 Review 中 → 🔄 开发中 → ✅ 已上线 → 🗄️ 已下线

---

完整流程（0→1 新项目）#

Phase 0：物料准备（质量决定上限）#

🎯 目标:备齐 3 类物料 + 对齐数据口径 + 列好继承清单。

3 类物料清单:

#物料类型内容常见坑1参照物料竞品截图 + 线上截图(必须带状态标签:未安装/已安装/活跃/回归)竞品和"想做的"混在一起 → 必须分层标注2数据分析报告竞品信息架构 + 线上漏斗/状态差异口径偷换(UV vs PV) → 先对齐口径3线上知识库功能逻辑 + 策略逻辑 + 继承清单(继承/修改/重做)只写新功能不写继承 → 研发全部新建,估期翻倍

操作步骤:

1. 问用户:"3 类物料你有哪几类?"
2. 缺的物料列出来,问怎么补(可以建议去哪查、找谁要)
3. 读取已有物料,标注质量等级(齐全/部分/缺失)
4. 输出物料清单到 knowledge-base/requirement/materials.md

🚧 Phase 0 门禁:

• ✅ 3 类物料齐全(每类至少有 1 份具体内容)
• ✅ 数据口径已对齐(显式说明"这里 UV" / "那里 PV")
• ✅ "现有逻辑继承清单"已列好(继承/修改/不做三列)
• ❌ 任一项缺失 → 进入补料子流程(见下方),补完再进 Phase 1

不接受的"完成"声明:

• ❌ "物料后面补"(后面补 = 永远不补)
• ❌ "我都记在脑子里"(脑子里的东西 AI 读不到)
• ❌ "继承逻辑开发会知道"(这是 PM 的本分,不能甩锅)

Phase 0 补料子流程#

用户有缺料时, 不要只说"不过闸",给出具体的补料方案:

物料 1（参照物料）缺失

推荐做法：调用 pm-research skill 做完整竞品分析，产出结构化报告直接作为物料 1。

text

Skill(skill: "pm-research")

如果不需要完整竞品分析（只差几张截图），AI 也能快速补：

• 用 WebFetch / WebSearch 抓取竞品公开信息（App Store / Google Play / 官网）
• 自动分类打标签
• 输出简要对比到 knowledge-base/requirement/competitor-brief.md

需要用户给的：

• 3-5 个对标竞品名称
• 线上自己产品的状态截图（AI 无法获取你产品的真实用户截图）

问用户："要做完整竞品分析（调 pm-research）还是快速补几张截图就够？"

物料 2(数据分析报告)缺失或口径不对齐

口径不对齐 的修复(最常见):

• 列出文档中所有涉及的"核心数据点"
• 对每个数据点标注 "UV / PV / DAU / 其他"
• 对冲突的让用户选一个统一口径

完全缺失:

• 问用户:"数据从哪来?(埋点平台 / 数据分析团队 / BI 报表)"
• AI 能帮:读取已有报告 MD/Excel/CSV,做二次加工
• AI 不能替: 拉新数据需要联系数据团队,给 deadline

物料 3(继承清单)缺失

AI 能帮的:

• 读取现有代码仓库(如果提供),总结已有功能
• 模板化输出"继承/修改/不做"三列

需要用户决策的:

• 每一项到底是"继承"还是"修改"—— 这是业务判断,AI 不能替

模板:

markdown

| 现有功能 | 决策 | 说明 |
|---|---|---|
| 每日签到(带补签) | 继承 | 不动 |
| 积分商城 | 修改 | 改币种单位 |
| 等级系统 | 不做 | 本期先不碰 |

Phase 0 补料优先级#

如果 多类物料同时缺,按以下优先级补(防止卡死):

1. P0 物料 3(继承清单) —— PM 自己能做,半小时内完成
2. P1 物料 2(数据分析) —— 口径对齐是最重要的,值得花 1 天
3. P2 物料 1(参照物料) —— AI 可以辅助加速,用户提供名单即可

并行 vs 串行:

• 物料 1 + 物料 3 可并行(AI 抓竞品时用户写继承)
• 物料 2 的口径对齐必须先于 Phase 1 完成(不然拆需求会拆错)

Phase 1:三步对话拆解(避免漂亮废话)#

🎯 目标:从命题拆到"1-3 个必要条件"+ 真实目标 + 砍完多余项。

直接调用 socratic-dialogue skill:

text

Skill(skill: "socratic-dialogue", args: "PRD 启动,项目:{项目名}")

socratic-dialogue 会引导走完:

• ① 苏格拉底:问 5 个真问题(真实目标/不做什么/痛点/成功标准/失败标准)
• ② 第一性:拆到 ≤3 个必要条件
• ③ 奥卡姆:砍掉所有能砍的模块/字段/交互

🚧 Phase 1 门禁(继承 socratic-dialogue 的门禁):

• ✅ 真实目标一句话(不是"提升 X%"这种结果指标)
• ✅ 必要条件 ≤ 3 条(每条都能答"砍了真实目标还能达成吗?")
• ✅ 不做清单已列(YAGNI)
• ✅ 已砍一轮,回头看状态机仍闭环
• ❌ 任一项没过 → 回 socratic-dialogue 补

Phase 2：产出 PRD v1.0（骨架 + 占位）#

🎯 目标：按 PRD v2.0 模板填 v1.0， 每章必须存在，暂时没内容写"待确认/待补充/待法务"。

📄 输出载体（优先飞书）：

• 默认：创建飞书文档（ doc_create），写入完整 PRD 内容，返回文档链接给用户
• 降级：用户明确要求本地 MD、或飞书 MCP 不可用时，才写本地 knowledge-base/product/ 目录
• 飞书文档标题格式： PRD: {项目名}（{版本号}）

操作：

1. 读取 templates/prd-template.md 获取完整骨架

2. 按项目情况裁剪章节：

   • 必保章节:0 文档元信息、1 执行摘要、7 功能详述、15 待确认项
   • 其余章节按项目复杂度增删,可新增业务专属章节
   • ⚠️ R1-R6 AI 友好规范仅作为 AI 写作时的内部约束,不写入最终 PRD 文档

3. 每个 功能模块 按 7.N 五子章节展开（系统侧规则/状态流转/边界处理/异常处理/明确不做）

R1-R6 硬规则检查(填 PRD 时严格遵守):

规则自检常见违反R1 禁止自造词所有词都是通用语言或术语表已定义"抽屉收起态下插卡逻辑"(自造)R2 边界条件显式每模块 7.N.7 覆盖 6 类边界"网络异常时展示兜底"(不够具体)R3 前后端分离描述每模块分别描述用户侧行为和数据侧规则,不指定技术实现混写实现细节(如"前端调 /api/xxx")R4 状态机 6 列含"禁止转换"列"支持多状态切换"(太笼统)R5 数值 4 维值+单位+区间+可配置性"长按触发选中"(缺单位)R6 AI 可读Figma 链接配 Mermaid/文字描述只贴 Figma 链接

⚠️ PRD 职责边界（What vs How）:

PRD 定义 做什么，不定义 怎么做。以下内容不出现在 PRD 中，留给研发阶段自主产出：

❌ PRD 不写✅ PRD 要写接口设计（URL/字段名/请求格式）业务数据规则（什么条件触发什么结果）数据库表结构数据实体关系（用户有哪些属性、状态有哪些）技术选型建议性能期望（用户可感知的，如"< 3 秒"）前后端分工方案用户侧行为 vs 系统侧规则的分别描述数据流转实现方式第三方系统依赖说明（需要对接谁）缓存/队列/定时任务等技术手段时效性要求（实时/准实时/T+1）

原则：研发拿到 PRD 后应该能自己决定技术方案，PRD 只给约束条件和验收标准，不给实现指导。

🚧 Phase 2 门禁:

• ✅ 必保章节存在(0 文档元信息、1 执行摘要、7 功能详述、15 待确认项)
• ✅ 其余章节按项目裁剪合理(不存在无意义的空占位)
• ✅ 每个功能模块五子章节齐全（系统侧规则/状态流转/边界处理/异常处理/明确不做）
• ✅ R1-R6 作为写作约束已遵守(但不作为独立章节出现在 PRD 中)
• ✅ 不含技术实现细节（接口/表结构/技术选型）
• ❌ 含"大概 / 似乎 / 可能"这类词 → 要么给具体数值,要么写"待确认"
• ❌ 出现接口名/字段名/技术方案 → 删除，改为业务规则描述

Phase 3:v2+ 迭代(收敛"待确认"到 0)#

🎯 目标:v1.0 骨架 → v3.x 终稿, 所有"待确认"清零。

迭代节奏(参考实测案例:v1.0 → v3.4 共 7 版):

版本关注点v1.0PRD v2.0 模板骨架完整,含占位v1.x业务流程 + 状态机 + 信息架构填实v2.x业务数据规则 + 异常路径 + 继承清单v3.0所有"待确认"必须清零v3.xreview 反馈回填

每次升版的动作:

1. 找出当前版本所有"待确认"项
2. 对每个项问: 谁能答这个问题? → 去问(飞书/口头/会议)
3. 拿到答案后,把"待确认"替换为具体内容
4. 更新 0.1 变更记录

⚠️ 关键规则:

• 标"必须澄清"的项 → 业务拍板,不自行推断(这是某 B 端中台项目踩的最大坑)
• 含糊的"可能 / 应该" → 换成明确陈述或标"待确认"

🚧 Phase 3 门禁:

• ✅ 版本已迭代到 v3.0+
• ✅ 全文"待确认/待补充/待法务"数量 = 0
• ✅ 0.1 变更记录完整(每版变更原因清楚)
• ❌ 有未收敛的"待确认" → 不能进 review
• ❌ "这条业务也不确定" → 停,让业务方拍板

交付清单#

Phase 3 完成后，输出：

1. PRD v3.x 终稿（飞书文档，返回链接）
2. 0.1 变更记录（v1.0 → v3.x 每版差异，在飞书文档内维护）
3. 高保真原型（可选，复杂项目必需）—— 通常交给设计师并行做
4. 物料清单（ knowledge-base/requirement/materials.md）
5. 本轮教训沉淀（如有）→ knowledge-base/lessons.md

下一步#

PRD 产出完成后:

• 启动 三端 + 设计 review 并行 → 调用 pm-review skill
• 等待 review 通过后进入 产品终审 → pm-acceptance skill

常见卡点解决#

卡点做法物料不够全列补料清单,标明谁能给,定 deadline三步对话拆不出必要条件可能是目标本身模糊,回去找业务方对齐PRD 写着写着发散每写完一章回头看必要条件还在不"待确认"一直清不掉列清单 + 责任人 + deadline,强制推进

写入日志#

Skill 完成后写 experience-base/raw/YYYY-MM-DD-HHmmss-pm-req.json：

json

{
  "timestamp": "ISO 8601",
  "skill": "pm-requirement",
  "project": "...",
  "mode": "new | iteration | hotfix",
  "iteration_number": 2,
  "materials_ready": true,
  "socratic_result": {
    "real_goal": "...",
    "necessary_conditions": ["...", "..."]
  },
  "prd_version_final": "v3.4",
  "prd_url": "飞书文档链接",
  "pending_count_at_v3": 0,
  "iterations": 7,
  "outcome": "ready_for_review",
  "version_index_updated": true
}