用 Agent Skill 固化 PRD 模板与需求规范，让需求文档更规范、可验收

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

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

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

背景与问题：要解决什么问题、为谁解决、当前痛点或机会。
目标与成功指标：业务/产品目标、可衡量的成功指标（如转化率、留存、NPS）。
用户与场景：目标用户、典型使用场景、用户旅程摘要。
功能需求：用户故事（As a… I want… So that…）或需求列表，可带优先级（P0/P1/P2）。
范围与边界：本期做什么、明确不做什么（Out of scope）。
非目标：明确不解决的次要问题，避免范围蔓延。
验收标准：每条需求对应可验证的验收条件（Given-When-Then 或检查清单）。
依赖与约束：技术/业务依赖、合规或性能约束、时间窗口。

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

要素必填建议可选背景与问题是问题陈述清晰、有数据或依据竞品/市场参考目标与成功指标是目标可衡量、指标可追踪基线数据用户与场景视团队目标用户、1～3 个核心场景用户旅程图功能需求是用户故事或需求列表、带优先级与设计/工单关联范围与边界是本期做/不做明确版本规划非目标视团队列出「本期不做」避免歧义 - 验收标准是每条需求有可验证条件测试用例链接依赖与约束视团队关键依赖、上线时间/合规风险列表

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

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

文档结构（可选节）

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

需求书写规范

用户故事：角色 + 能力 + 价值，如「作为注册用户，我希望能通过邮箱找回密码，以便在忘记密码时自助恢复」。
需求列表：每条可验收、无歧义；避免「优化体验」「提升性能」等不可验证表述，改为可观测结果（如「列表首屏加载 < 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 <路径>，将脚本输出的缺节列表并入检查结果。

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

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

#!/usr/bin/env bash 用法: ./scripts/check-prd-sections.sh 
      
 输出缺失的必选节，供 prd-requirement 技能并入符合性检查。
 FILE=”\({1:-}" if [ -z "\)FILE” ] || [ ! -f “$FILE” ]; then
 echo "Usage: $0 
     
       
       
         " 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 <路径> ，将脚本输出的缺节按「必改」并入符合性检查结果。」

若团队有固定 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 归档：[团队内部链接]
- 需求与工单关联说明：[团队内部链接]

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

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

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

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

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

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