团团队写 PRD 时，如果每人结构不统一，有的缺成功指标，有的需求不可验收，有的用户故事含糊不清，评审时很难聚焦，开发团队也难以对齐。把 PRD 模板与需求书写规范写进一条 Agent Skill，助手在你说「写 PRD」「按模板写需求文档」「生成产品需求」「审一下这份 PRD」时，就能按同一套结构输出，必填节不遗漏，需求可追溯、可验收。本文从团队 PRD 规范到 SKILL.md 结构、可选 reference.md、可选 scripts、触发与输出以及团队协作，走完一整套实战流程。

一、从团队 PRD 规范到技能范围

先明确「写什么、怎么写」。PRD / 需求文档常见要素可包括：

• 背景与问题：要解决什么问题、为谁解决、当前痛点或机会。

• 目标与成功指标：业务/产品目标、可衡量的成功指标（如转化率、留存、NPS）。

• 用户与场景：目标用户、典型使用场景、用户旅程摘要。

• 功能需求：用户故事（As a… I want… So that…）或需求列表，可带优先级（P0/P1/P2）。

• 范围与边界：本期做什么、明确不做什么（Out of scope）。

• 非目标：明确不解决的次要问题，避免范围蔓延。

• 验收标准：每条需求对应可验证的验收条件（Given-When-Then 或检查清单）。

• 依赖与约束：技术/业务依赖、合规或性能约束、时间窗口。

示例表格（可根据团队裁剪）：

技能的目标：助手在用户给出「产品背景与目标」或「已有 PRD 草稿」时，按上述模板生成可直接编辑、评审的 PRD 文档（Markdown），缺项用占位提示补全；或对已有 PRD 做符合性检查（缺节、需求不可验收、成功指标缺失等），并输出必改/建议清单。

二、SKILL.md 结构示例

在 .cursor/skills/prd-requirement/ 下创建 SKILL.md。推荐目录结构：

prd-requirement/
├── SKILL.md
├── reference.md   # 可选，完整 PRD 模板、需求书写规范、示例
└── scripts/       # 可选，检查 PRD 是否包含必选节
    └── check-prd-sections.sh

示例 SKILL.md 如下：

---
name: prd-requirement
description: 按团队模板生成或评审 PRD（产品需求文档）；适用于用户说「写 PRD」「写需求文档」「生成产品需求」「按模板写 PRD」「审一下这份 PRD」或提及 PRD、需求文档时。
---

# PRD / 需求文档技能

当用户要求撰写或评审 PRD 时，按以下模板与规范生成一篇完整文档，或输出符合性检查结果。

## 执行前

- **输入范围**：用户提供的产品背景、目标、用户与场景、已有 PRD 草稿或片段。若用户只说「写一份 PRD」「写需求文档」等未提供任何要点，先询问：产品/功能名称、要解决的问题、目标用户、核心目标或成功指标，再生成。
- 确认至少有**产品/功能主题与目标（或问题陈述）**后，再按下方模板输出；缺项用 `[请补充：xxx]` 占位。

## 文档结构（必填节）

按以下顺序输出，每节必须有内容或占位说明：

1. **背景与问题**：要解决什么问题、为谁、当前痛点或机会；可 1～3 段。
2. **目标与成功指标**：业务/产品目标、可衡量的成功指标（如转化率、留存、DAU）；若无数据可写 `[请补充指标与基线]`。
3. **用户与场景**：目标用户、1～3 个核心使用场景；可列表或简短段落。
4. **功能需求**：用户故事（As a… I want… So that…）或需求列表，每条带 **ID**（如 R1、R2）与 **优先级**（P0/P1/P2）；无则用 `[请补充需求列表]`。
5. **范围与边界**：本期做什么（In scope）、明确不做什么（Out of scope）；列表形式。
6. **验收标准**：每条需求对应可验证的验收条件；可与需求一一对应或单独成表，格式如「R1：当…时，应…」。
7. **依赖与约束**（若适用）：关键依赖、上线时间、合规或性能约束；无则写「无」或 `[请补充]`。

## 文档结构（可选节）

- **非目标**：本期明确不解决的问题，避免范围蔓延。
- **附录**：术语表、参考链接、变更记录。

## 需求书写规范

- **用户故事**：角色 + 能力 + 价值，如「作为注册用户，我希望能通过邮箱找回密码，以便在忘记密码时自助恢复」。
- **需求列表**：每条可验收、无歧义；避免「优化体验」「提升性能」等不可验证表述，改为可观测结果（如「列表首屏加载 < 2s」）。
- **优先级**：P0 必须本期交付，P1 重要可下期，P2 可选；与团队约定一致。

## 输出格式

- 输出为完整 **Markdown** 文档，可直接复制到 Confluence/Notion/仓库。
- 标题层级：一级标题为文档标题，二级标题为上述各节；需求与验收标准用列表或表格。
- 占位符统一为 `[请补充：xxx]` 或 `[待确认]`。

## 示例输出（节选）

```markdown
# PRD：[产品/功能名称]

## 背景与问题
[当前痛点或机会，为谁解决问题]

## 目标与成功指标
- **目标**：[请补充]
- **成功指标**：如转化率提升 x%、留存 D7 达 y%；[请补充指标与基线]

## 用户与场景
- **目标用户**：[请补充]
- **核心场景**：1）… 2）… 3）…

## 功能需求
| ID  | 描述 | 优先级 |
|-----|------|--------|
| R1  | 作为用户，我希望能通过邮箱找回密码，以便自助恢复 | P0 |
| R2  | [请补充] | P1 |

## 范围与边界
- **In scope**：…
- **Out of scope**：…

## 验收标准
- R1：当用户提交已验证邮箱时，系统在 5 分钟内发送重置链接；链接 24h 有效。
- R2：[请补充]

## 依赖与约束
[请补充或写「无」]

若用户提供的是已有 PRD并要求「检查是否符合模板」或「评审这份 PRD」，则输出：符合项 ✓、缺节或缺项列表、需求是否可验收、成功指标是否可衡量；按必改 / 建议 / 可选分级，并给出修改建议。

可根据团队实际增删「文档结构」与「需求书写规范」；完整模板、用户故事与验收标准示例可放到 reference.md，主文件只写「见 reference.md」。若使用 scripts/，可在 SKILL 的「执行前」中约定：评审已有 .md 时先执行 `scripts/check-prd-sections.sh <路径>`，将脚本输出的缺节列表并入检查结果。

可选 scripts 示例

若希望助手在评审 PRD 时先检查文档是否包含必选节，可在同目录下创建 `scripts/`，例如：

scripts/check-prd-sections.sh（检查 .md 是否含必选二级标题，输出缺失节供技能合并到评审结果）：

#!/usr/bin/env bash
# 用法: ./scripts/check-prd-sections.sh <prd.md 路径>
# 输出缺失的必选节，供 prd-requirement 技能并入符合性检查。

FILE="${1:-}"
if [ -z "$FILE" ] || [ ! -f "$FILE" ]; then
    echo "Usage: $0 <path-to-prd.md>"
    exit 1
fi

echo "=== PRD 必选节检查 ==="
for section in 背景与问题 目标与成功指标 用户与场景 功能需求 范围与边界 验收标准; do
    if grep -qE "^## *$section" "$FILE" 2>/dev/null; then
        echo "✓ $section"
    else
        echo "✗ 缺失: $section"
    fi
done

SKILL 中可写：「若用户提供的是 .md 文件路径并要求评审 PRD，执行前可先运行 scripts/check-prd-sections.sh <路径>，将脚本输出的缺节按「必改」并入符合性检查结果。」

三、可选 reference.md

若团队有固定 PRD 模板、用户故事规范或历史示例，可在同目录下增加 reference.md（与 SKILL.md 同级），例如：

• 完整 PRD 文档模板（可直接复制首段）。

• 用户故事与验收标准书写规范（As a… I want… So that…；Given-When-Then）。

• 优先级定义（P0/P1/P2）与需求 ID 约定。

• 链接到内部产品规范或 PRD 归档。

SKILL.md 里写一句：「完整模板与需求书写规范见 reference.md。」助手会在需要时读取。

以下为 reference.md 示例，可按团队实际裁剪：

# PRD 模板与需求书写参考

本文件供 prd-requirement 技能在需要时查阅，与 SKILL.md 中的文档结构一致并展开细节。

---

## 一、完整 PRD 模板（复制用）

```markdown
# PRD：[产品/功能名称]

## 背景与问题
[要解决什么问题、为谁、当前痛点或机会]

## 目标与成功指标
- 目标：
- 成功指标：（可衡量，如转化率、留存、NPS）

## 用户与场景
- 目标用户：
- 核心场景：

## 功能需求
| ID | 描述（用户故事或需求） | 优先级 |
|----|------------------------|--------|
|    |                        | P0/P1/P2 |

## 范围与边界
- In scope：
- Out of scope：

## 验收标准
- 每条需求对应可验证条件

## 依赖与约束
- 依赖 / 时间 / 合规等

## 非目标（可选）
- 本期明确不解决的事项
```

---

## 二、用户故事与验收标准规范

### 用户故事
- 格式：**作为** [角色]，**我希望** [能力/行为]，**以便** [价值/目标]。
- 一条故事只描述一个可交付能力，避免「和」「以及」拆成多条。

### 验收标准
- 格式：**Given** 前置条件 **When** 操作 **Then** 预期结果；或「当…时，应…」。
- 每条需求至少一条可验证的验收条件；避免主观表述（如「体验更好」）。

### 禁止表述（示例）
- 「优化体验」「提升性能」→ 改为可观测指标（如「首屏 < 2s」「错误率 < 0.1%」）。
- 「尽量」「可能」「视情况」→ 改为明确规则或列出例外。

---

## 三、优先级定义（占位）

- **P0**：\[团队定义，如必须本期上线、阻塞发布]
- **P1**：\[团队定义，如重要但可下期]
- **P2**：\[团队定义，如可选、锦上添花]

将上述定义替换为团队实际约定即可。

---

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

- 产品规范与 PRD 归档：\[团队内部链接]
- 需求与工单关联说明：\[团队内部链接]

四、在 Cursor 里的触发与输出

• 隐式：用户说「写 PRD」「写需求文档」「按模板写产品需求」「生成 PRD」「审一下这份 PRD」「评审这份需求文档」，助手根据 description 匹配到 prd-requirement 技能，按上述模板输出一篇 PRD 文档或符合性检查结果。
• 显式：用户说「用 prd-requirement 技能写一份 PRD」或输入 /prd（若产品支持）。

输出应为可直接复制到文档系统或仓库的完整 Markdown PRD；若用户已提供背景与目标，相应节应已填充，缺项用 [请补充：xxx] 标出。若为评审模式，输出为必改/建议/可选清单，每条带位置（章节）与修改建议。

五、团队协作：统一技能与 Review 他人写的 Skill

• 统一技能目录：建议把 prd-requirement 等团队技能放在项目内 .cursor/skills/，随仓库提交，产品与研发拉代码即有一致模板。
• Review 他人写的 Skill：新技能或改动可走 PR，重点看：description 是否覆盖常见说法（PRD、需求文档、产品需求）、文档结构是否与团队共识一致、需求书写规范是否清晰；必要时在对话里实际触发一次做验收。

小结：从团队 PRD 规范到 SKILL.md（执行前 + 文档结构 + 需求书写规范 + 输出格式 + 示例）、可选 reference（完整模板、用户故事与验收标准规范、优先级定义）、可选 scripts（检查必选节）、触发方式与团队协作，就完成了一条可复用的 PRD 需求文档技能。与前面几篇属同一套实战套路：把团队规范清单化 → SKILL → reference（+ scripts）→ 触发与协作；本篇区别在于产出是结构化产品需求文档，兼具「生成草稿」与「符合性评审」两种用法。

本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！

链接: https://fly63.com/article/detial/13616