AI写需求系列之PM Skills

一、项目概述

**PM Skills Marketplace** 是一个面向产品经理的 AI 技能市场，包含 **8 个插件、65 个技能、36 个链式工作流**，覆盖产品发现、策略、执行、上市等全流程。

它的核心理念：**不是让 AI 生成一堆文字，而是将成熟的 PM 框架（Teresa Torres、Marty Cagan、Alberto Savoia 等）编码为结构化的引导式工作流**，帮助产品经理做出更好的产品决策。

二、核心概念

| 概念 | 说明 |

|------|------|

| **Skill（技能）** | 最小构建块。每个技能赋予 AI 一个特定 PM 领域的知识或框架，会话相关时自动加载 |

| **Command（命令）** | 用户触发的工作流，用 `/命令名` 调用。将多个技能串联成端到端流程 |

| **Plugin（插件）** | 将相关技能和命令打包为可安装的模块，按 PM 领域分组 |

三、如何写 PRD（核心聚焦）

3.1 触发方式

```

/write-prd SSO support for enterprise customers

/write-prd Users are dropping off during onboarding --- we need to fix step 3

/write-prd [上传 brief、研究文档或策略 deck]

```

输入可以是任何形式：功能名称、问题陈述、用户诉求、模糊想法、上传文档均可。

3.2 四步工作流

Step 1: 理解需求

接受任何形式的输入：

功能名（如 "SSO 支持"）
问题描述（如 "企业客户一直要求集中认证"）
用户请求（如 "用户想导出 CSV"）
模糊想法（如 "注册流失率太高了，得想想办法"）
上传文档（brief、调研、Slack 讨论、邮件）

Step 2: 收集上下文（对话式提问）

按重要性排序，逐步补齐信息缺口：

**用户问题** --- 解决什么问题？谁遇到了这个问题？有多痛？
**目标用户** --- 哪些用户群体？数量？当前替代方案是什么？
**成功指标** --- 如何衡量成功？哪些指标会变化？
**约束条件** --- 技术限制、时间线、合规要求、跨团队依赖？
**已有尝试** --- 之前试过吗？市场上有类似方案吗？
**范围偏好** --- 一次性完整方案，还是分阶段交付？

> 如果用户提供了文档，则先从中提取已有信息，只问缺失部分。

Step 3: 生成 PRD（8 段式结构）

Step 4: 评审与迭代

生成后提供进一步选项：

收紧范围（挑战 P1 是否应降为 P2）
运行预验尸分析（Pre-mortem）
拆解为用户故事
创建干系人沟通方案

最终保存为 `PRD-[产品名].md`。

3.3 PRD 模板结构（8 个段落）

PRD 由两套互补的模板定义，综合如下：

1. Executive Summary / 摘要

2-3 句话说清：**做什么、给谁做、为什么现在做**

2. Contacts / 干系人

列出关键人：姓名、角色、备注

3. Background & Context / 背景

这个项目是什么？
为什么是现在？发生了什么变化？
是否有新的技术/市场条件使其变得可行？
已有的调研、市场背景、前序工作

4. Objectives & Success Metrics / 目标与指标

**目标（Goals）**：具体、可衡量的成功定义
**非目标（Non-Goals）**：明确不做什么、为什么不做（防止范围蔓延）
**关键结果（Key Results）**：用 SMART OKR 格式，要与公司战略对齐
**指标表**：

| 指标 | 当前值 | 目标值 | 衡量方式 |

|------|--------|--------|----------|

> 关键原则："提升 NPS" 是差的指标，"90天内将 NPS 从 32 提升到 45" 才是好的指标。

5. Target Users & Market Segments / 目标用户与市场分群

为谁构建？
存在哪些约束？
**市场由人的问题/待完成的工作定义，而非人口统计特征**

6. Value Proposition / 价值主张

解决用户什么工作/需求？
用户会得到什么？
帮用户避免什么痛苦？
相比竞品的优势在哪里？
可参考价值曲线（Value Curve）框架

7. Solution / 解决方案

**7.1 UX/原型**：线框图、用户流程
**7.2 核心功能**：详细功能描述
**7.3 技术方案**（可选）：仅在相关时提供
**7.4 假设**：我们相信但尚未验证的事情

8. User Stories & Requirements / 用户故事与需求（按优先级）

**P0 --- Must Have（必须有）**：

| # | 用户故事 | 验收标准 |

|---|---------|---------|

**P1 --- Should Have（应该有）**：

| # | 用户故事 | 验收标准 |

|---|---------|---------|

**P2 --- Nice to Have / Future（最好有/未来）**：

| # | 用户故事 | 验收标准 |

|---|---------|---------|

9. Open Questions / 待解决问题

| 问题 | 负责人 | 截止时间 |

|------|--------|----------|

> 只列真正未解决的问题，不要列能从上下文中回答的问题。

10. Timeline & Phasing / 时间线与阶段划分

里程碑、依赖关系
第一版 vs 后续版本各做什么
**避免精确日期，使用相对时间框架**

四、写 PRD 的关键原则

**对范围要有态度** --- 紧凑的 PRD 好过宽泛模糊的 PRD
**主动建议分阶段** --- 如果想法太大，主动建议分阶段，只详细定义 Phase 1
**非目标和目标同样重要** --- 它们是防止范围蔓延的利器
**指标必须具体** --- 包含当前值、目标值、衡量方式和时间框架
**用平实语言** --- 用小学生能理解的语言，避免行业术语
**数据驱动** --- 尽可能用数据支撑
**假设要标记清楚** --- 让团队知道哪些需要验证
**每个段落要能回溯到整体战略**

五、PRD 的上下游衔接

PRD 不是孤立文档，PM Skills 将其嵌入完整的产品工作流中：

```

/discover（产品发现）

↓ 想法 → 假设 → 优先级 → 实验

/strategy（产品策略）

↓ 愿景 → 商业模式 → 价值主张

/write-prd（撰写 PRD） ← 你在这里

↓

/pre-mortem（预验尸分析，评估 PRD 风险）

↓

/write-stories（拆解为用户故事）

↓

/sprint plan（冲刺规划）

↓

/plan-launch（上市策略）

```

每个命令完成后会推荐下一步可执行的命令，形成自然的工作流衔接。

六、PM Skills 全部插件使用指南

安装全部 8 个插件后，可直接在对话中输入**斜杠命令**触发工作流。以下是按场景分类的速查表：

7.1 产品发现（pm-product-discovery）

| 命令 | 用途 |

|---|---|

| `/discover` | 完整发现流程：创意 → 假设 → 优先级 → 实验设计 |

| `/brainstorm` | 多角度创意风暴（PM/设计/工程视角） |

| `/triage-requests` | 分析和分类客户功能请求 |

| `/interview` | 准备客户访谈脚本或总结访谈记录 |

| `/setup-metrics` | 设计产品指标看板（北极星指标等） |

7.2 产品战略（pm-product-strategy）

| 命令 | 用途 |

|---|---|

| `/strategy` | 9 部分产品战略画布 |

| `/business-model` | 商业模式画布（精益/完整/创业） |

| `/value-proposition` | 基于 JTBD 的价值主张设计 |

| `/market-scan` | 宏观环境分析（SWOT + PESTLE + 波特五力 + 安索夫矩阵） |

| `/pricing` | 定价策略设计 |

7.3 产品执行（pm-execution）

| 命令 | 用途 |

|---|---|

| `/write-prd` | 撰写完整 PRD 文档 |

| `/plan-okrs` | 制定团队 OKR |

| `/transform-roadmap` | 将功能路线图转为成果导向路线图 |

| `/sprint` | Sprint 计划 / 回顾 / 发版说明 |

| `/pre-mortem` | 预防性风险分析 |

| `/meeting-notes` | 会议纪要整理 |

| `/stakeholder-map` | 利益相关者分析 + 沟通计划 |

| `/write-stories` | 编写用户故事 / 工作故事 |

| `/test-scenarios` | 生成测试场景 |

| `/generate-data` | 生成模拟数据集 |

7.4 市场调研（pm-market-research）

| 命令 | 用途 |

|---|---|

| `/research-users` | 用户画像 + 细分 + 客户旅程地图 |

| `/competitive-analysis` | 竞品分析 |

| `/analyze-feedback` | 用户反馈情感分析 |

7.5 数据分析（pm-data-analytics）

| 命令 | 用途 |

|---|---|

| `/write-query` | 自然语言生成 SQL |

| `/analyze-cohorts` | 同期群留存分析 |

| `/analyze-test` | A/B 测试统计分析 |

7.6 上市策略（pm-go-to-market）

| 命令 | 用途 |

|---|---|

| `/plan-launch` | 完整 GTM 计划 |

| `/growth-strategy` | 增长飞轮 + GTM 渠道评估 |

| `/battlecard` | 销售竞争对战卡 |

7.7 营销增长（pm-marketing-growth）

| 命令 | 用途 |

|---|---|

| `/market-product` | 营销创意 + 定位 + 价值主张文案 + 产品命名 |

| `/north-star` | 定义北极星指标 |

7.8 PM 工具箱（pm-toolkit）

| 命令 | 用途 |

|---|---|

| `/review-resume` | PM 简历评审 |

| `/tailor-resume` | 简历针对 JD 定制 |

| `/draft-nda` | 起草保密协议 |

| `/privacy-policy` | 起草隐私政策 |

| `/proofread` | 语法和逻辑校对 |

工作流串联

命令之间是设计好的链式工作流。例如一个完整的产品从 0 到 1 流程：

```

/discover → /strategy → /write-prd → /plan-launch → /north-star

```

每个命令执行完毕后，会建议下一步可以使用的命令，形成连贯的产品管理流程。

使用技巧

**大多数命令支持参数**，比如 `/brainstorm ideas existing` 或 `/sprint retro`
**命令执行中会有检查点**，让你确认方向后再继续
**结果会保存为 Markdown 文件**到你的工作目录，方便后续引用

七、参考资源

本项目 PRD 框架融合了以下方法论：

Teresa Torres --- *Continuous Discovery Habits*
Marty Cagan --- *INSPIRED* / *TRANSFORMED*
Dan Olsen --- *The Lean Product Playbook*
Christina Wodtke --- *Radical Focus*（OKR）
Anthony W. Ulwick --- *Jobs to Be Done*
Strategyzer --- *Value Proposition Design*

进一步阅读：

$How to Write a Product Requirements Document? The Best PRD Template.\](https://www.productcompass.pm/p/prd-template)$

八、`/write-prd` 命令运行原理深度解析

`/write-prd` 是 `pm-execution` 插件中的核心命令，由**命令文件**（`write-prd.md`）和**技能文件**（`create-prd/SKILL.md`）两层协作完成。

8.1 架构：Command + Skill 分层设计

```

用户输入: /write-prd SSO support for enterprise customers

│

▼

┌─────────────────────────────────────────────┐

│ Command 层 (write-prd.md) │

│ 定义：触发方式、工作流步骤、交互逻辑、输出格式 │

│ 职责：编排流程、引导对话、管理迭代 │

└──────────────────┬──────────────────────────┘

│ Step 3 调用

▼

┌─────────────────────────────────────────────┐

│ Skill 层 (create-prd/SKILL.md) │

│ 定义：PRD 模板结构、写作规范、领域知识 │

│ 职责：提供 8 段式模板、写作原则、质量标准 │

└─────────────────────────────────────────────┘

```

**Command** 是动词（做什么），负责流程编排和用户交互
**Skill** 是名词（知识），负责提供领域框架和模板

8.2 触发机制

命令文件通过 YAML frontmatter 注册：

```yaml

description: Create a comprehensive Product Requirements Document from a feature idea or problem statement

argument-hint: "<feature or problem statement>"

```

`description`：让 Claude 知道何时该触发这个命令
`argument-hint`：提示用户可以传入的参数格式

用户可以用以下任何方式触发：

```

/write-prd SSO support for enterprise customers

/write-prd Users are dropping off during onboarding --- we need to fix step 3

/write-prd [上传 brief、研究文档或策略 deck]

```

8.3 四步工作流详解

Step 1: 理解输入（Understand the Feature）

接受**任意形式**的输入，不要求结构化：

| 输入类型 | 示例 |

|---------|------|

| 功能名称 | "SSO support" |

| 问题陈述 | "Enterprise customers keep asking for centralized auth" |

| 用户请求 | "Users want to export their data as CSV" |

| 模糊想法 | "We should do something about onboarding drop-off" |

| 上传文档 | brief、调研报告、Slack 讨论记录、邮件 |

设计理念：**降低使用门槛**------PM 不需要先整理好想法才能开始写 PRD。

Step 2: 收集上下文（Gather Context）

通过**对话式提问**逐步补齐信息缺口，按重要性排序：

**用户问题** --- 解决什么问题？谁遇到了？有多痛？
**目标用户** --- 哪些用户群体？数量？当前替代方案？
**成功指标** --- 如何衡量成功？哪些指标会变化？
**约束条件** --- 技术限制、时间线、合规、跨团队依赖？
**已有尝试** --- 之前试过吗？市场上有类似方案吗？
**范围偏好** --- 一次性完整方案，还是分阶段？

关键逻辑：**如果用户提供了文档，先从中提取已有信息，只问缺失部分**，避免重复提问。

Step 3: 生成 PRD（Generate the PRD）

调用 `create-prd` 技能，技能层提供两件事：

**a) 角色设定**

```

You are an experienced product manager responsible for creating

a comprehensive Product Requirements Document for $ARGUMENTS.

```

`$ARGUMENTS` 会被替换为用户传入的参数，让 AI 进入正确的角色上下文。

**b) 思考框架（Think Step by Step）**

技能要求 AI 在写之前先分析四个问题：

我们要解决什么问题？
我们为谁解决？
如何衡量成功？
约束和假设是什么？

**c) 8 段式 PRD 模板**

Command 层和 Skill 层各定义了一套模板，两者互补：

| 段落 | Command 层定义 | Skill 层补充 |

|------|---------------|-------------|

| 1. 摘要 | 2-3 句话：what, for whom, why now | 同 |

| 2. 干系人/背景 | Background & Context | Contacts（姓名、角色、备注）+ Background（为什么是现在？是否新近可行？） |

| 3. 目标与指标 | Goals + Non-Goals + Success Metrics 表 | Objective + SMART OKR Key Results + 战略对齐 |

| 4. 目标用户 | Who this serves, segment sizing | 市场由问题/JTBD 定义，非人口统计 |

| 5. 用户故事 | P0/P1/P2 三级优先级表 | --- |

| 6. 价值主张 | --- | 客户 JTBD、收益、痛点、竞争优势、价值曲线 |

| 7. 解决方案 | High-level approach, design decisions | UX/原型 + 核心功能 + 技术方案(可选) + 假设 |

| 8. 时间线 | Milestones, dependencies, phasing | 首版 vs 后续版本，用相对时间框架 |

| 附: 开放问题 | Question + Owner + Deadline 表 | --- |

Step 4: 评审与迭代（Review and Iterate）

生成后不是结束，而是提供四个后续选项：

```

"Want me to tighten the scope?" → 挑战 P1 是否应降为 P2
"Should I run a pre-mortem?" → 链接到 /pre-mortem 命令
"Want me to break this into stories?" → 链接到 /write-stories 命令
"Create a stakeholder update?" → 链接到 /stakeholder-map 命令

```

这就是**链式工作流**的实现方式：每个命令在完成后推荐下一个命令。

最终保存为 `PRD-[产品名].md`。

8.4 写作质量控制（Notes 层）

Command 和 Skill 两层都定义了质量规则，合并后形成完整的写作标准：

| 规则 | 来源 |

|------|------|

| 对范围要有态度------紧凑的 PRD 好过宽泛模糊的 PRD | Command |

| 如果想法太大，主动建议分阶段，只详细定义 Phase 1 | Command |

| 非目标和目标同样重要------防止范围蔓延 | Command |

| 指标必须具体："improve NPS" 是差的，"increase NPS from 32 to 45 within 90 days" 才是好的 | Command |

| 开放问题必须是真正未解决的，不要列能从上下文回答的问题 | Command |

| 如果用户提供了调研，将洞察织入 Background 段落并标注来源 | Command |

| 用平实语言，为小学生写作水平即可理解 | Skill |

| 尽可能数据驱动 | Skill |

| 每个段落要能回溯到整体战略 | Skill |

| 假设要标记清楚，让团队知道哪些需要验证 | Skill |

8.5 运行流程时序图

```

用户 Command 层 Skill 层

│ │ │

│── /write-prd "SSO" ───→│ │

│ │ │

│ [Step 1: 解析输入] │

│ │ │

│←── "SSO 是给谁用的？ │ │

│ 有什么约束？" ──────│ │

│ │ │

│── "企业客户，要支持 │ │

│ SAML 和 OIDC" ─────→│ │

│ [Step 2: 补齐上下文] │

│ │ │

│←── "成功指标是什么？" ──│ │

│ │ │

│── "SSO 采纳率 > 60%" ─→│ │

│ │ │

│ │── 调用 create-prd ───→│

│ │ │

│ │ [应用 8 段模板] │

│ │ [应用写作规范] │

│ │ [Think Step by Step]│

│ │ │

│ │←── 返回 PRD 文档 ─────│

│ [Step 3: 输出 PRD] │

│ │ │

│←── PRD-SSO.md ─────────│ │

│ │ │

│ [Step 4: 提供后续选项] │

│←── "要收紧范围吗？ │ │

│ 要跑预验尸吗？ │ │

│ 要拆用户故事吗？" ──│ │

│ │ │

```

8.6 设计亮点总结

**双层架构**：Command 管流程编排，Skill 管领域知识，职责分离、可独立复用
**渐进式信息收集**：不要求一次给全信息，通过对话逐步补齐
**智能跳过**：有文档输入时自动提取已有信息，只问缺失部分
**强制质量标准**：通过 Notes 层硬编码写作规则，防止 AI 生成模糊内容
**链式工作流**：Step 4 的后续选项自然链接到其他命令（`/pre-mortem`、`/write-stories`、`/stakeholder-map`）
**文件持久化**：输出保存为 `PRD-[产品名].md`，成为团队可共享的工件

AI写需求系列之PM Skills

一、项目概述

二、核心概念

三、如何写 PRD（核心聚焦）

3.1 触发方式

3.2 四步工作流

Step 1: 理解需求

Step 2: 收集上下文（对话式提问）

Step 3: 生成 PRD（8 段式结构）

Step 4: 评审与迭代

3.3 PRD 模板结构（8 个段落）

1. Executive Summary / 摘要

2. Contacts / 干系人

3. Background & Context / 背景

4. Objectives & Success Metrics / 目标与指标

5. Target Users & Market Segments / 目标用户与市场分群

6. Value Proposition / 价值主张

7. Solution / 解决方案

8. User Stories & Requirements / 用户故事与需求（按优先级）

9. Open Questions / 待解决问题

10. Timeline & Phasing / 时间线与阶段划分

四、写 PRD 的关键原则

五、PRD 的上下游衔接

六、PM Skills 全部插件使用指南

7.1 产品发现（pm-product-discovery）

7.2 产品战略（pm-product-strategy）

7.3 产品执行（pm-execution）

7.4 市场调研（pm-market-research）

7.5 数据分析（pm-data-analytics）

7.6 上市策略（pm-go-to-market）

7.7 营销增长（pm-marketing-growth）

7.8 PM 工具箱（pm-toolkit）

推荐的入门路径

工作流串联

使用技巧

七、参考资源

八、`/write-prd` 命令运行原理深度解析

8.1 架构：Command + Skill 分层设计

8.2 触发机制

8.3 四步工作流详解

Step 1: 理解输入（Understand the Feature）

Step 2: 收集上下文（Gather Context）

Step 3: 生成 PRD（Generate the PRD）

Step 4: 评审与迭代（Review and Iterate）

8.4 写作质量控制（Notes 层）

8.5 运行流程时序图

8.6 设计亮点总结