1. 为什么 PRD 一到评审就吵起来产品经理和 AI 工程师协作时最耗时的往往不是写代码而是对齐需求。一份 PRD 需求文档如果结构不统一评审会上就会出现「成功指标在哪」「这条需求怎么验收」「范围边界没写清楚」这类反复拉扯。我见过不少团队PRD 写成了散文开发看完还得再问一遍Agent 读起来更是抓不住重点。Agent Skills 要解决的就是这个问题把团队的 PRD 模板和需求书写规范固化成一个可复用的 Skill让 Agent 在你说「写 PRD」「按模板写需求文档」「审一下这份 PRD」时按同一套结构输出。SKILL.md 是 Skill 的核心描述文件它告诉 Agent 这个技能叫什么、什么时候触发、按什么结构执行。配合 reference.md 放完整模板scripts 做自动检查就能把「写 PRD」这件事从个人习惯变成团队能力。这篇面向产品经理和 AI 工程师交付可复制的 SKILL.md 骨架、目录结构、字段说明以及用 Markdown 校验 Skill 是否被正确加载的验证动作。你不需要先懂 Agent 框架跟着步骤把文件建好就能在支持 Skills 的编辑器里触发它。2. 前置准备TaoToken 与 Skill 运行环境Skill 本身是纯文本规范但要让 Agent 真正跑起来需要一个能调用模型的入口。TaoToken 提供统一的 API 接入模型对话、Coding Plan、API Keys 都在一个控制台里管理。你可以先到官网了解整体能力再进控制台创建密钥。官网地址https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基址https://taotoken.net/api具体操作路径模型对话入口https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewriteCoding Plan 入口https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewriteClaudeCodeAnthropic 配置https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaude_codeutm_campaignrewrite拿到 Key 后把它写进环境变量后续验证 Skill 加载时会用到。建议用TAOTOKEN_API_KEY这个变量名避免和别的服务冲突。export TAOTOKEN_API_KEY你的密钥 echo $TAOTOKEN_API_KEY | head -c 8输出前 8 位说明变量已生效。这一步不做后面请求会直接 401。3. 可复制配置SKILL.md 骨架与目录结构Skill 的目录结构决定了 Agent 能不能找到它。推荐放在项目内的.cursor/skills/prd-requirement/下随仓库提交产品与研发拉代码就有一致模板。prd-requirement/ ├── SKILL.md ├── reference.md # 可选完整 PRD 模板与书写规范 └── scripts/ # 可选检查必选节 └── check-prd-sections.shSKILL.md 的头部是 YAML front mattername和description决定触发。description 要覆盖团队常用说法比如「写 PRD」「写需求文档」「生成产品需求」「审一下这份 PRD」。--- name: prd-requirement description: 按团队模板生成或评审 PRD产品需求文档适用于用户说「写 PRD」「写需求文档」「生成产品需求」「按模板写 PRD」「审一下这份 PRD」或提及 PRD、需求文档时。 --- # PRD / 需求文档技能 当用户要求撰写或评审 PRD 时按以下模板与规范生成一篇完整文档或输出符合性检查结果。 ## 执行前 - 输入范围用户提供的产品背景、目标、用户与场景、已有 PRD 草稿或片段。若用户只说「写一份 PRD」而未提供任何要点先询问产品/功能名称、要解决的问题、目标用户、核心目标或成功指标再生成。 - 确认有至少产品/功能主题与目标或问题陈述后再按下方模板输出缺项用 [请补充xxx] 占位。 ## 文档结构必填节 按以下顺序输出每节必须有内容或占位说明 1. 背景与问题要解决什么问题、为谁、当前痛点或机会可 13 段。 2. 目标与成功指标业务/产品目标、可衡量的成功指标如转化率、留存、DAU若无数据可写 [请补充指标与基线]。 3. 用户与场景目标用户、13 个核心使用场景可列表或简短段落。 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] 或 [待确认]。字段说明name是技能标识调用时用description是触发匹配的关键写得越贴近团队口语命中率越高正文里的「执行前」负责兜底追问「文档结构」负责输出骨架「需求书写规范」负责质量红线。reference.md 放完整模板和示例SKILL.md 里写一句「完整模板与需求书写规范见 reference.md」Agent 需要时会读取。# PRD 模板与需求书写参考 ## 一、完整 PRD 模板复制用 # PRD[产品/功能名称] ## 背景与问题 [要解决什么问题、为谁、当前痛点或机会] ## 目标与成功指标 - 目标 - 成功指标可衡量如转化率、留存、NPS ## 用户与场景 - 目标用户 - 核心场景 ## 功能需求 | ID | 描述用户故事或需求 | 优先级 | |----|------------------------|--------| | | | P0/P1/P2 | ## 范围与边界 - In scope - Out of scope ## 验收标准 - 每条需求对应可验证条件 ## 依赖与约束 - 依赖 / 时间 / 合规等scripts/check-prd-sections.sh 用来检查一份 .md 是否包含必选二级标题评审时先跑脚本把缺节并入检查结果。#!/usr/bin/env bash # 用法: ./scripts/check-prd-sections.sh prd.md 路径 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给脚本加执行权限chmod x scripts/check-prd-sections.sh4. 验证请求确认 Skill 被正确加载Skill 建好后怎么知道 Agent 真的读到了最直接的办法是发一条触发语看输出结构是否符合 SKILL.md 定义。用 TaoToken 的 API 发一次请求把 Skill 内容作为系统提示的一部分。curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-3-5-sonnet, messages: [ {role: system, content: 你已加载 prd-requirement 技能按 SKILL.md 结构输出。}, {role: user, content: 写一份 PRD用户希望能在 App 内一键导出账单为 CSV。} ] } | head -c 800成功结果应该包含「背景与问题」「目标与成功指标」「功能需求」等二级标题缺项用[请补充xxx]标出。如果输出是一段散文说明 Skill 没被正确加载检查 description 是否匹配、文件路径是否在.cursor/skills/下。另一种验证方式是直接跑脚本确认 Markdown 结构完整./scripts/check-prd-sections.sh ./examples/sample-prd.md输出类似 PRD 必选节检查 ✓ 背景与问题 ✓ 目标与成功指标 ✗ 缺失: 用户与场景 ✓ 功能需求 ✓ 范围与边界 ✓ 验收标准缺节列表可以直接并入评审结果按「必改」分级反馈给产品经理。5. 本篇常见错排查Skill 不触发最常见是 description 没覆盖用户说法。比如团队习惯说「需求文档」而不是「PRD」description 里就要补上。另外检查文件是否放在.cursor/skills/下路径错了 Agent 扫不到。输出结构缺节SKILL.md 里「文档结构」写了必填节但 Agent 仍漏掉通常是正文太长导致注意力分散。把必填节压缩成编号列表每节一句话说明reference.md 放展开细节。占位符不统一有的写[待补充]有的写TODO评审时不好 grep。在 SKILL.md 里明确「占位符统一为[请补充xxx]」脚本检查时也能按这个模式匹配。脚本权限报错Permission denied说明没加执行权限跑chmod x scripts/check-prd-sections.sh。如果是在 Windows 下用 Git Bash 或 WSL 执行。API 返回 401检查TAOTOKEN_API_KEY是否导出成功echo $TAOTOKEN_API_KEY有没有值。密钥泄露的话到控制台重新生成旧 Key 立即失效。评审模式输出混乱用户说「审一下这份 PRD」时Agent 应该输出符合项、缺节列表、必改/建议/可选分级而不是重新生成一份 PRD。在 SKILL.md 里把「生成」和「评审」两种模式分开写清楚。6. 把 Skill 变成团队资产单个 Skill 跑通后下一步是团队协作。建议把prd-requirement放在项目内.cursor/skills/随仓库提交产品与研发拉代码即有一致模板。新技能或改动走 PR重点看 description 是否覆盖常见说法、文档结构是否与团队共识一致、需求书写规范是否清晰。必要时在对话里实际触发一次做验收。长期做编码和 Agent 协作的团队可以了解 Coding Plan把模型调用和技能管理放在一起规划https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite接入过程中遇到报错先查接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite需要管理多个项目的密钥到 API Keys 页面按项目拆分https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite想先验证模型输出效果用模型对话快速试https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite把 PRD 规范清单化 → SKILL.md → reference.md scripts→ 触发与协作这条链路走完你就有了一个可复用的需求文档技能。产出是结构化 PRD兼具「生成草稿」与「符合性评审」两种用法评审会上少吵半小时开发对齐快一截。 Agent Skills 实战：用 SKILL.md 把 PRD 需求文档写成可复用 Skill
1. 为什么 PRD 一到评审就吵起来产品经理和 AI 工程师协作时最耗时的往往不是写代码而是对齐需求。一份 PRD 需求文档如果结构不统一评审会上就会出现「成功指标在哪」「这条需求怎么验收」「范围边界没写清楚」这类反复拉扯。我见过不少团队PRD 写成了散文开发看完还得再问一遍Agent 读起来更是抓不住重点。Agent Skills 要解决的就是这个问题把团队的 PRD 模板和需求书写规范固化成一个可复用的 Skill让 Agent 在你说「写 PRD」「按模板写需求文档」「审一下这份 PRD」时按同一套结构输出。SKILL.md 是 Skill 的核心描述文件它告诉 Agent 这个技能叫什么、什么时候触发、按什么结构执行。配合 reference.md 放完整模板scripts 做自动检查就能把「写 PRD」这件事从个人习惯变成团队能力。这篇面向产品经理和 AI 工程师交付可复制的 SKILL.md 骨架、目录结构、字段说明以及用 Markdown 校验 Skill 是否被正确加载的验证动作。你不需要先懂 Agent 框架跟着步骤把文件建好就能在支持 Skills 的编辑器里触发它。2. 前置准备TaoToken 与 Skill 运行环境Skill 本身是纯文本规范但要让 Agent 真正跑起来需要一个能调用模型的入口。TaoToken 提供统一的 API 接入模型对话、Coding Plan、API Keys 都在一个控制台里管理。你可以先到官网了解整体能力再进控制台创建密钥。官网地址https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基址https://taotoken.net/api具体操作路径模型对话入口https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewriteCoding Plan 入口https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewriteClaudeCodeAnthropic 配置https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaude_codeutm_campaignrewrite拿到 Key 后把它写进环境变量后续验证 Skill 加载时会用到。建议用TAOTOKEN_API_KEY这个变量名避免和别的服务冲突。export TAOTOKEN_API_KEY你的密钥 echo $TAOTOKEN_API_KEY | head -c 8输出前 8 位说明变量已生效。这一步不做后面请求会直接 401。3. 可复制配置SKILL.md 骨架与目录结构Skill 的目录结构决定了 Agent 能不能找到它。推荐放在项目内的.cursor/skills/prd-requirement/下随仓库提交产品与研发拉代码就有一致模板。prd-requirement/ ├── SKILL.md ├── reference.md # 可选完整 PRD 模板与书写规范 └── scripts/ # 可选检查必选节 └── check-prd-sections.shSKILL.md 的头部是 YAML front mattername和description决定触发。description 要覆盖团队常用说法比如「写 PRD」「写需求文档」「生成产品需求」「审一下这份 PRD」。--- name: prd-requirement description: 按团队模板生成或评审 PRD产品需求文档适用于用户说「写 PRD」「写需求文档」「生成产品需求」「按模板写 PRD」「审一下这份 PRD」或提及 PRD、需求文档时。 --- # PRD / 需求文档技能 当用户要求撰写或评审 PRD 时按以下模板与规范生成一篇完整文档或输出符合性检查结果。 ## 执行前 - 输入范围用户提供的产品背景、目标、用户与场景、已有 PRD 草稿或片段。若用户只说「写一份 PRD」而未提供任何要点先询问产品/功能名称、要解决的问题、目标用户、核心目标或成功指标再生成。 - 确认有至少产品/功能主题与目标或问题陈述后再按下方模板输出缺项用 [请补充xxx] 占位。 ## 文档结构必填节 按以下顺序输出每节必须有内容或占位说明 1. 背景与问题要解决什么问题、为谁、当前痛点或机会可 13 段。 2. 目标与成功指标业务/产品目标、可衡量的成功指标如转化率、留存、DAU若无数据可写 [请补充指标与基线]。 3. 用户与场景目标用户、13 个核心使用场景可列表或简短段落。 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] 或 [待确认]。字段说明name是技能标识调用时用description是触发匹配的关键写得越贴近团队口语命中率越高正文里的「执行前」负责兜底追问「文档结构」负责输出骨架「需求书写规范」负责质量红线。reference.md 放完整模板和示例SKILL.md 里写一句「完整模板与需求书写规范见 reference.md」Agent 需要时会读取。# PRD 模板与需求书写参考 ## 一、完整 PRD 模板复制用 # PRD[产品/功能名称] ## 背景与问题 [要解决什么问题、为谁、当前痛点或机会] ## 目标与成功指标 - 目标 - 成功指标可衡量如转化率、留存、NPS ## 用户与场景 - 目标用户 - 核心场景 ## 功能需求 | ID | 描述用户故事或需求 | 优先级 | |----|------------------------|--------| | | | P0/P1/P2 | ## 范围与边界 - In scope - Out of scope ## 验收标准 - 每条需求对应可验证条件 ## 依赖与约束 - 依赖 / 时间 / 合规等scripts/check-prd-sections.sh 用来检查一份 .md 是否包含必选二级标题评审时先跑脚本把缺节并入检查结果。#!/usr/bin/env bash # 用法: ./scripts/check-prd-sections.sh prd.md 路径 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给脚本加执行权限chmod x scripts/check-prd-sections.sh4. 验证请求确认 Skill 被正确加载Skill 建好后怎么知道 Agent 真的读到了最直接的办法是发一条触发语看输出结构是否符合 SKILL.md 定义。用 TaoToken 的 API 发一次请求把 Skill 内容作为系统提示的一部分。curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-3-5-sonnet, messages: [ {role: system, content: 你已加载 prd-requirement 技能按 SKILL.md 结构输出。}, {role: user, content: 写一份 PRD用户希望能在 App 内一键导出账单为 CSV。} ] } | head -c 800成功结果应该包含「背景与问题」「目标与成功指标」「功能需求」等二级标题缺项用[请补充xxx]标出。如果输出是一段散文说明 Skill 没被正确加载检查 description 是否匹配、文件路径是否在.cursor/skills/下。另一种验证方式是直接跑脚本确认 Markdown 结构完整./scripts/check-prd-sections.sh ./examples/sample-prd.md输出类似 PRD 必选节检查 ✓ 背景与问题 ✓ 目标与成功指标 ✗ 缺失: 用户与场景 ✓ 功能需求 ✓ 范围与边界 ✓ 验收标准缺节列表可以直接并入评审结果按「必改」分级反馈给产品经理。5. 本篇常见错排查Skill 不触发最常见是 description 没覆盖用户说法。比如团队习惯说「需求文档」而不是「PRD」description 里就要补上。另外检查文件是否放在.cursor/skills/下路径错了 Agent 扫不到。输出结构缺节SKILL.md 里「文档结构」写了必填节但 Agent 仍漏掉通常是正文太长导致注意力分散。把必填节压缩成编号列表每节一句话说明reference.md 放展开细节。占位符不统一有的写[待补充]有的写TODO评审时不好 grep。在 SKILL.md 里明确「占位符统一为[请补充xxx]」脚本检查时也能按这个模式匹配。脚本权限报错Permission denied说明没加执行权限跑chmod x scripts/check-prd-sections.sh。如果是在 Windows 下用 Git Bash 或 WSL 执行。API 返回 401检查TAOTOKEN_API_KEY是否导出成功echo $TAOTOKEN_API_KEY有没有值。密钥泄露的话到控制台重新生成旧 Key 立即失效。评审模式输出混乱用户说「审一下这份 PRD」时Agent 应该输出符合项、缺节列表、必改/建议/可选分级而不是重新生成一份 PRD。在 SKILL.md 里把「生成」和「评审」两种模式分开写清楚。6. 把 Skill 变成团队资产单个 Skill 跑通后下一步是团队协作。建议把prd-requirement放在项目内.cursor/skills/随仓库提交产品与研发拉代码即有一致模板。新技能或改动走 PR重点看 description 是否覆盖常见说法、文档结构是否与团队共识一致、需求书写规范是否清晰。必要时在对话里实际触发一次做验收。长期做编码和 Agent 协作的团队可以了解 Coding Plan把模型调用和技能管理放在一起规划https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite接入过程中遇到报错先查接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite需要管理多个项目的密钥到 API Keys 页面按项目拆分https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite想先验证模型输出效果用模型对话快速试https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite把 PRD 规范清单化 → SKILL.md → reference.md scripts→ 触发与协作这条链路走完你就有了一个可复用的需求文档技能。产出是结构化 PRD兼具「生成草稿」与「符合性评审」两种用法评审会上少吵半小时开发对齐快一截。