Agent Skills 实战：把产品经理（PDM）常用产出写成 Skill（上）

Agent Skills 实战系列。本篇以 产品经理（PDM）常用产出为例：技能覆盖产品路线图、需求优先级/Backlog 排序、版本规划、竞品分析、产品汇报等文档类型，按团队模板生成或补全对应草稿，或对已有文档做符合性评审；与 PRD Skill 互补——PRD 定「单次需求做什么」，本篇侧重「排期、优先级、规划与汇报」。

本文里的 PDM （Product Manager）是为了给这类技能起一个便于区分的名字（为了跟后面要介绍的 PJM - Project Manager / Management 区分），指向的是产品经理相关的规划、优先级、汇报类文档, 还可以缩写成 PM；重点不在缩写本身，而在这组产出类型的统一模板化。

产品经理的日常产出很多：路线图、优先级说明、版本计划、竞品分析、周报……如果每个人的写法都不一样、关键项还经常缺失，团队在对齐、评审和复盘时就会很吃力。把这些常用模板收进一条 Agent Skill，价值就在于：当你说“写路线图”、“写版本规划”、“排一下需求优先级”、“写竞品分析”、“写产品周报”时，助手会尽量按同一套结构来组织内容，减少遗漏，降低沟通成本。

这一篇先把基础打牢，集中解决三个问题：

• PDM Skill 到底该覆盖哪些文档类型。
• SKILL.md 应该怎么写。
• reference.md 和可选 scripts 分别承担什么角色。

下一篇再继续看：这条 Skill 为什么适合先合并实现、如何从一句用户输入落到具体输出、以及上线后该如何验收和团队化使用。

一、从团队 PDM 文档规范到技能范围

先明确一件事：这条 Skill 到底负责“哪几类文档”，每一类又至少要写到什么程度。产品经理常用产出大致可以归纳为以下几类，每类都有相对稳定的必填项：

• 产品路线图（Roadmap）：时间轴（季度/半年）、主题或目标、关键里程碑、依赖与风险、与战略对齐说明。
• 需求优先级 / Backlog 排序：优先级框架（如 RICE、MoSCoW）、排序结果列表（需求/ epic + 优先级 + 理由）、与目标对齐说明。
• 版本规划 / 发布计划：版本号与时间、版本目标、范围（需求/ epic 列表）、依赖与风险、发布节奏（如灰度）。
• 竞品分析：竞品列表、对比维度（功能/体验/定价等）、结论与产品行动建议。
• 产品汇报 / 周报：周期、核心指标与进展、阻塞与风险、下周重点、需决策项。

示例（可据团队裁剪）：

这条 Skill 的目标很明确：当用户已经指明文档类型，并给出一组简要输入（例如“Q2 三个主题”“这批需求列表”“下个版本要上的功能”）时，助手应按对应模板生成一份可直接编辑的 Markdown 草稿；如果用户给的是已有路线图、版本规划或优先级说明，则输出符合性检查结果，给出必改项与建议项。

如果团队成员经常分不清“这件事到底该写成哪类文档”，可以先补一张选择表，把入口先统一起来：

适用边界与常见混淆

• 路线图 vs 版本规划：路线图回答“未来一段时间做什么方向”，强调阶段目标、主题和里程碑；版本规划回答“下个版本具体上什么”，强调版本目标、范围、时间和发布节奏。
• 需求优先级 vs 版本规划：需求优先级用于给候选需求排序，核心是“先做谁、为什么”；版本规划用于在某个发布窗口内确定范围，核心是“这次实际上哪些会上线”。
• 产品汇报 vs 项目周报：产品汇报强调业务目标、指标进展、风险和决策请求；项目周报更偏执行状态、任务推进与协作事项。若用户要的是研发执行视角，可能更适合项目周报类 Skill 或模板。
• 竞品分析 vs 市场调研：竞品分析更聚焦对手方案比较与我方动作建议；若目标是了解用户画像、市场规模、行业趋势，则应使用更偏研究类模板，而不是套用竞品分析结构。

如果仍然拿不准，可以先问用户一句：你要的是方向规划、版本落地、需求排序、竞品比较，还是对上汇报？ 先把文档类型分清，再生成正文，通常比直接开写更稳。

如果你想先用一张图抓住这条 Skill 的范围与结构，可以先看下面这个简图：

二、SKILL.md 结构示例

在 .cursor/skills/pdm/ 下建 SKILL.md。推荐目录结构：

pdm/
├── SKILL.md
├── reference.md   # 可选，各类型完整模板、优先级框架说明、示例
└── scripts/       # 可选，检查文档是否含必选节
    └── check-pdm-sections.sh

下面这段可以直接作为第一版骨架：先把结构搭起来，再按你们团队的实际模板做删改。第一次看时不必逐字细抠，先重点抓三件事：description 如何覆盖常见表达、各文档类型的必填节如何定义、通用规范如何兜底。

示例 SKILL.md 如下：

---
name: pdm
description: 按团队模板生成或评审产品经理（PDM）常用文档，含产品路线图、需求优先级、版本规划、竞品分析、产品汇报等；适用于用户说“写路线图”、“写版本规划”、“排一下需求优先级”、“写竞品分析”、“写产品周报”、“写月报”、“做个竞品对比”、“帮我排一下这季度需求”、“给老板写个版本计划”、“看看这个 roadmap 缺什么”等表达，或提及产品经理、路线图、版本计划、优先级排序、产品汇报时。
---

# 产品经理（PDM）文档技能

当用户要求撰写或评审产品经理常用文档时，先确认**文档类型**（路线图 / 需求优先级 / 版本规划 / 竞品分析 / 产品汇报），再按该类型的模板与规范生成一篇完整文档，或输出符合性检查结果。

## 工作模式

- **生成模式**：输入为文档类型 + 零散素材，输出为按模板整理好的完整 Markdown 草稿。
- **补全模式**：输入为半成品草稿，输出为补全后的版本，并保留仍待确认的占位项。
- **评审模式**：输入为已有文档，输出为符合项、缺项、必改项、建议项。
- **重写模式**：输入为口语描述、会议纪要或旧文档，输出为按团队模板重组后的版本。

## 执行前

- **文档类型**：根据用户表述判断——“路线图”、“roadmap”、“今年做什么”、“Q2 做哪些方向”→ 路线图；“优先级”、“排需求”、“backlog”、“这批需求怎么排”、“先做哪个”→ 需求优先级；“版本规划”、“发布计划”、“release plan”、“下个版本上什么”、“发版怎么排”→ 版本规划；“竞品分析”、“竞品对比”→ 竞品分析；“周报”、“月报”、“季度汇报”、“汇报”、“产品更新”、“给领导同步一下进展”→ 产品汇报。若无法判断，先询问用户要写哪一类。
- **最小输入要求**：路线图至少要有周期 + 产品/方向 + 至少一个主题；需求优先级至少要有需求列表 + 目标；版本规划至少要有版本周期 + 候选范围；竞品分析至少要有竞品名单 + 对比主题；产品汇报至少要有汇报周期 + 本期事项或指标。
- **输入不足时的处理**：若只缺少少量字段，则先生成结构化草稿并用 “[请补充：xxx]” 占位；若核心输入缺失过多，则先列出需要补充的信息清单；若连文档类型都无法判断，则先提问，不直接生成正文。
- 确认**文档类型 + 至少一项关键输入**后，按该类型下方模板输出；缺项用 “[请补充：xxx]” 占位。

## 文档类型一：产品路线图

**必填节**：时间轴（如 Q1～Q4）、各阶段主题或目标、关键里程碑、依赖与风险（若适用）。
**输出**：Markdown，一级标题“产品路线图：[产品/年度]”，二级标题为时间或主题，下为里程碑与依赖列表。
**若缺信息优先追问**：周期、目标、关键主题、关键依赖、成功标准。

## 文档类型二：需求优先级 / Backlog 排序

**必填节**：采用的优先级框架（如 RICE、MoSCoW）、排序结果（需求/ epic + 优先级 + 简要理由）、与目标对齐说明。
**输出**：Markdown，表格列：需求 ID/描述、优先级、理由、对应目标。
**若缺信息优先追问**：需求列表、业务目标、目标用户、成本/工时、依赖与约束。

## 文档类型三：版本规划 / 发布计划

**必填节**：版本号与目标发布时间、版本目标、范围（需求/ epic 列表）、依赖与风险、发布节奏（如全量/灰度）。
**输出**：Markdown，一级标题“版本规划：[版本号]”，含范围表、时间线、风险与依赖。
**若缺信息优先追问**：版本时间、必须上线项、可延后项、依赖团队、灰度或全量策略。

## 文档类型四：竞品分析

**必填节**：竞品列表、对比维度（功能/体验/定价等）、结论与产品行动建议。
**输出**：Markdown，一级标题“竞品分析：[主题/产品]”，对比表 + 结论 + 行动项。
**若缺信息优先追问**：竞品名单、分析维度、目标市场、信息来源、输出用途。

## 文档类型五：产品汇报 / 周报

**必填节**：汇报周期、本周/本期进展、核心指标（若适用）、阻塞与风险、下周/下期重点、需决策项（若有）。
**输出**：Markdown，一级标题“产品汇报：[周期]”，分节：进展、指标、阻塞与风险、下周重点、需决策项。
**若缺信息优先追问**：汇报对象、周期、核心指标、阻塞项、需决策事项。
**受众区分**：若面向管理层，优先突出目标进展、关键指标、风险与决策请求；若面向项目组，优先突出事项状态、阻塞、协作需求与下步安排。

## 通用规范

- 每类文档的占位符统一为 “[请补充：xxx]” 或 “[待确认]”。
- 未由用户提供或上下文明确给出的信息，不要写成确定事实；如发布时间、指标、竞品事实、依赖承诺、资源安排、RICE 分数等，若未知则标为 “[待确认]” 或单列“假设前提”。
- 输出尽量结论优先、结构可扫描；优先用表格、列表与短段落表达，不堆砌空话。
- 规划类文档需显式写出依赖、风险、待确认项；竞品分析与产品汇报需落到明确行动项或决策请求。
- 若用户提供的是**已有文档**并要求“检查是否符合模板”，则按该类型必填节逐项检查，输出符合项 ✓、缺项列表、必改/建议清单。
- 评审已有文档时，只检查结构完整性、逻辑一致性、信息缺口与表达清晰度，不擅自改写业务事实。

示例输出（路线图节选）

# 产品路线图：[产品名] 2026

## Q1：主题/目标
- 目标：[请补充]
- 关键里程碑：[请补充]
- 依赖与风险：[请补充]

这份骨架不是要你原样照抄，而是给出一个足够稳的起点。你可以根据团队实际情况增删“文档类型”与每类的必填节；完整模板、优先级框架（RICE/MoSCoW）说明更适合放到 reference.md。如果要配合 scripts/ 使用，也可以在“执行前”约定：评审已有 .md 时先执行 scripts/check-pdm-sections.sh <路径> <类型>，再把输出并入检查结果。若团队标题命名不统一，还可以为“目标 / 版本目标”“阻塞 / 风险与问题”“需决策项 / 需要支持”等补充别名匹配。

这里还要提醒读者一点：description 写得更全，确实能提升命中概率，但不会保证百分百稳定触发。Skill 更像一份“高概率会被参考的工作说明书”，不是确定性的路由器；它是否会被选中，仍然取决于用户表达、上下文和模型判断。对容易混淆的场景，最好在正文里明确“无法判断时先追问”，或者让用户显式说“用 pdm 技能”。至于这条 Skill 在真实输入下如何落到输出、以及该怎么验收，放到下一篇再展开。

可选 scripts 示例

scripts/check-pdm-sections.sh（根据文档类型检查 .md 是否含该类型必选节，输出缺失节）：

#!/usr/bin/env bash
# 用法: ./scripts/check-pdm-sections.sh <文档.md 路径> <类型：roadmap|priority|release|competitor|report>
# 输出缺失的必选节，供 pdm 技能并入符合性检查。

FILE="${1:-}"
TYPE="${2:-}"
if [ -z "$FILE" ] || [ ! -f "$FILE" ]; then
echo"Usage: $0 <path-to-doc.md> <roadmap|priority|release|competitor|report>"
exit 1
fi

case"$TYPE"in
  roadmap)   SECTIONS="时间轴 主题 目标 里程碑 依赖" ;;
  priority)  SECTIONS="优先级框架 排序 理由 目标对齐" ;;
  release)   SECTIONS="版本号 版本目标 范围 时间 依赖 发布" ;;
  competitor) SECTIONS="竞品 对比 结论 行动" ;;
  report)    SECTIONS="周期 进展 重点 决策" ;;
  *)         echo"Unknown type: $TYPE"; exit 1 ;;
esac

echo"=== PDM 文档必选节检查（$TYPE）==="
for section in$SECTIONS; do
if grep -qE "^## *.*$section|^# *.*$section""$FILE" 2>/dev/null; then
    echo"✓ 含相关节: $section"
else
    echo"✗ 建议补充: $section"
fi
done

在 SKILL 里，可以写成：“若用户提供 .md 路径并要求评审，执行前可先运行 scripts/check-pdm-sections.sh <路径> <类型>，将输出并入符合性检查结果。”

脚本的定位应明确为粗检查：它只能帮助发现常见标题缺失，不判断内容质量，也可能因标题命名差异而误报或漏报；适合做快速提醒，不适合当成强校验，最终仍以 Skill 的语义评审为准。

另外，这里的脚本示例采用 bash + grep，更适合类 Unix 环境；若团队成员大量使用 Windows，可提供 PowerShell 或 Node.js 版本。即使换成别的实现，定位也不变：它只是辅助检查标题或节名是否出现，不负责判断内容是否充分、逻辑是否成立。

三、可选 reference.md

如果团队已经有固定的路线图、版本规划、优先级框架或汇报模板，可以在同目录下增加 reference.md，例如放入以下内容：

• 各类型完整模板：路线图、需求优先级、版本规划、竞品分析、产品汇报的 Markdown 模板（可直接复制）。
• 优先级框架：RICE（Reach, Impact, Confidence, Effort）、MoSCoW（Must/Should/Could/Won't）的简要说明与使用场景。
• 路线图/版本规划：时间轴命名（季度/半年）、里程碑与依赖的书写示例。
• 竞品分析：常用对比维度（功能、体验、定价、生态）、结论与行动项的格式。
• 汇报模板：面向管理层与面向项目组两类汇报模板的侧重点。
• 链接到内部产品规范、汇报节奏或模板库。

SKILL.md 里可以写一句：“各类型完整模板与优先级框架见 reference.md。”这样助手在需要时就会去读取。

下面给一个 reference.md 的节选示例，方便你理解它应该承载什么内容。这里只展示其中几段，完整版本可以按团队实际情况补齐五类模板：

# PDM 文档模板与参考

本文件供 pdm 技能在需要时查阅，与 SKILL.md 中各类型必填节一致并展开细节。

---

## 一、产品路线图模板（复制用）

```markdown
# 产品路线图：[产品] [年度/周期]

## [Q1/阶段一]
- 主题/目标：
- 关键里程碑：
- 依赖与风险：
```

---

## 二、需求优先级框架（示例）

- **RICE**：Reach（影响用户量）× Impact（影响程度）× Confidence（把握度）/ Effort（成本）；适合功能排序。
- **MoSCoW**：Must have / Should have / Could have / Won't have；适合版本范围划定。
- **选择建议**：候选需求较多、希望半量化排序时优先用 RICE；做版本范围划定或跨团队沟通时优先用 MoSCoW；若信息不完整，也可先用价值 vs 成本矩阵做粗排。
- 团队可在此写自用框架（如价值 vs 成本矩阵）。

---

## 三、版本规划模板（复制用）

```markdown
# 版本规划：[版本号]

## 版本目标
## 范围（需求/ epic 列表）
## 时间与发布节奏
## 依赖与风险
```

---

## 四、内部链接（示例占位）

- 产品路线图规范：[团队内部链接]
- 汇报节奏与模板：[团队内部链接]

小结：到这里，PDM Skill 的范围、模板结构、参考材料和辅助检查方式就算搭起来了。上篇先解决“写什么、放哪里、怎么组织”；下一篇再继续看：为什么这条 Skill 适合先合并实现、如何从一句口语输入落到最终文档，以及上线后该如何验收、如何在团队里落地。