PM AI编程实战③·造你的第一个AI工具

产品经理 AI 编程实战 · 第 3 篇（共 8 篇）

PRD 写完了，发出去之前谁帮你查漏洞？

评审会上被问”边界情况考虑了吗””技术上有坑吗”——每次靠临场反应，不如造一个工具，让 AI 每次按固定标准帮你扫一遍。

这个工具叫 Skill。

这篇用需求评审做例子，但教你的是构建任何 Skill 的通用方法。后续的竞品分析、数据看板、用研整理，都会用同一套方法变成你的 AI 能力模块。

读完你能带走：

Skill 构建三要素（通用方法，适用所有场景）

完整的 SKILL.md 代码（直接复制）

自查清单 + 常见问题速查

从单个工具到 PM Copilot 系统的路线图

Skill 是什么

一句话：Skill 就是把你的最佳实践固化成一个文件，让 AI 每次按同样标准执行。

普通 Prompt 每次重新写，质量不稳定，用完就没了。Skill 写一次永远可用，持续迭代，团队共享。

技术上就是一个 SKILL.md文件，放在项目的 .cursor/skills/skill名/ 文件夹里。

存放位置两种选择：

使用方式：AI 自动识别场景触发，或者你输入 /skill名 手动调用。

最好的skill是你自己构建的？

 Marketplace 上有成千上万现成 Skill，但别人的不懂你的行业、产品阶段、团队规范。只有你构建的 Skill，才能嵌入你真正的工作上下文。

如果你对 Skill概念还比较陌生，推荐先看这篇 👉Skills系列①·它不是工作流，是AI的专家大脑

构建三要素

不管做什么 Skill，设计时回答三个问题就够了。

三要素就是你给 AI 写的工作手册。清楚了这三个问题，什么场景的 Skill 都能做。

下面用需求评审走一遍完整流程。

实战：构建需求评审 Skill

设计评审维度

好的评审不是”凭感觉看看”，是多视角的结构化检查。

创建 SKILL.md

在项目目录下创建文件：.cursor/skills/prd-review/SKILL.md

整个文件分三段。先看结构：

第一段：身份声明 —— 告诉 AI 这个 Skill 叫什么、什么时候用。

---name: prd-reviewdescription: 从技术、产品、业务三个视角评审PRD。用户提交PRD或说"帮我评审需求"时使用。---# PRD 需求评审## 何时使用- 用户提交PRD或需求文档- 用户说"帮我评审一下"- 评审会之前自查

第二段：执行流程—— 这是核心，你的评审标准全在这里。

## 评审流程### 第一步：确认输入阅读完整PRD。确认理解背景、目标、用户、功能、约束。信息不完整？先提问补充。不在缺失信息时强行评审。### 第二步：三视角检查**技术可行性（1-5分）**- [ ] 方案是否可行，有无实现障碍- [ ] 性能瓶颈或安全风险- [ ] 依赖的系统和接口是否明确- [ ] 数据模型字段和关系是否清晰**产品完整性（1-5分）**- [ ] 主路径和异常路径是否覆盖- [ ] 边界情况：空数据/权限不足/并发/极端值- [ ] 验收标准是否具体且可测试- [ ] 是否遗漏关键功能或交互**业务价值（1-5分）**- [ ] 是否解决核心用户痛点- [ ] 投入产出比是否合理- [ ] 优先级与产品方向是否一致- [ ] 有无更简单的替代方案

第三段：输出格式 + 注意事项 —— 决定 AI 给你的报告长什么样。

### 第三步：输出报告## 需求评审报告### 总体评分- 技术可行性：X/5- 产品完整性：X/5- 业务价值：X/5### 必须修改1. [问题] → [修改方向]### 建议优化1. [问题] → [修改方向]### 做得好的地方1. ...## 注意事项- 不确定的判断标注 [需技术团队确认]- 不编造不存在的问题- 每条建议具体，不说"建议完善"- 每个问题给修改方向- 信息不足时先列需要补充的内容

加你的行业上下文

这段可能只有 100 字，但它是你的 Skill 跟通用 Skill 拉开差距的关键。在 SKILL.md 末尾补一段：

## 行业背景本产品属于 [行业]，技术栈 [技术]，当前 [产品阶段]。评审时特别关注：- [行业特有约束，如数据合规、支付安全]- [团队反复出现的问题，如接口文档缺失]- [当前阶段关注点，如MVP不要过度设计]

测试一遍

Agent 模式输入 /prd-review，粘贴一份真实 PRD。看结果，调 2-3 轮基本稳定。

到这里，你的第一个 Skill 就做好了。

你的 Skill 做好了吗

跑完第一轮后，对照这个清单确认：

自查清单

用真实 PRD 跑过至少 1 次

 三个维度都有具体检查项（不是泛泛的”是否完整”）

 补充了行业背景段落

 AI 不会在信息不足时强行给出”没问题”的结论

/prd-review 手动调用能正常触发

不好使的时候

AI 输出太泛 → 检查项不够细。”是否考虑了边界情况”改成”空数据时展示什么、权限不足怎么提示、网络中断数据是否丢失”。

某维度完全不准 → 行业背景段落没写或太简略。补充技术栈、产品阶段、团队常踩的坑。

总说”很好没问题” → 加一条：信息不完整时先列出需要补充的内容，不要直接给出”没有问题”的结论。

自动触发不生效 → 目前已知的稳定性问题。用 /prd-review 手动调用更可靠。

结果前后矛盾 → 上下文太长导致 AI 漂移。新开一个对话重新跑。

同样的方法，做任何 Skill

回头看你刚做的评审 Skill 的构造：触发 → 确认输入 → 分维度检查 → 固定格式输出。

换掉中间的检查维度，骨架完全一样。

竞品分析 Skill → 触发：分析竞品时 / 流程：按维度（定位、功能、定价、优劣势）结构化对比 / 输出：表格 + 行动建议。你会发现，把”评审三维度”替换成”竞品四维度”，Skill 的骨架没变。

用研整理 Skill → 触发：提交访谈记录 / 流程：聚类 → 提取痛点 → 标优先级 → 附原文引用 / 输出：摘要版（给老板）+ 完整版（给团队）。检查项变了，但”确认输入 → 分步处理 → 固定格式输出”没变。

数据分析 Skill → 触发：分析数据时 / 流程：确认指标 → 趋势判断 → 异常识别 → 归因假设 / 输出：看板 + 洞察。还是同一个骨架。

方法通用，上下文专属。 这是这篇最核心的一句话。

让 Skill 越用越准

做出来只是起点。

研发提了 Skill 没发现的风险？补进去。

把 SKILL.md 放到代码仓库，团队共享，评审标准统一。

三个月后这个 Skill 积累了团队踩过的所有坑——从个人工具变成团队知识资产。

一个实际的进化案例：开源的”AI 产品设计 12 原则”Skill，初始版本 58% 原则达标，经过持续迭代达到 100%，文档增加了 2570 行。

源码参考：github.com/wanghui2323/ai-product-12

这不是一个工具，是一个系统的起点

你今天做的评审 Skill，是更大系统的第一块拼图。

横向，同样的方法可以扩展成多个模块——评审、竞品、数据、用研，每一个场景一个 Skill，最终组装成一套完整的 PM 工作系统。

纵向，你今天做的属于 L2（给输入，AI 结构化检查）。同样的框架可以往上做到 L3（AI 直接产出 PRD、System Prompt），甚至 L4（说一句话，AI 自主完成从需求到交付的全流程）。

这是一个开源的 PM Copilot 系统，4 个模块、58 个能力，从 L1 到 L4 全覆盖：

PM Copilot 系统源码：github.com/wanghui2323/pm-copilot

今天你在 L2、第一个模块。方法掌握了，后面每篇文章带你往横向和纵向各走一步。

最后的话

Marketplace 上有成千上万的 Skill。

但最有价值的那个，永远是你自己构建的。里面装的是你的判断标准、你的行业知识、你的团队经验。

它不会是你的最后一个——评审、竞品、数据、用研，每一个场景都会变成你的 Skill 模块。模块攒够了，就是你的 AI 工作系统。

第一块拼图，从今天开始。

这篇你学会了什么：

一个需求评审 Skill（.cursor/skills/prd-review/SKILL.md）

一套构建任何 Skill 的通用方法（三要素）

Design Copilot 的第一个能力模块

下一篇：自己做产品原型——不是①那个快速 Demo，而是能持续迭代、用在日常工作中的高保真原型。Design Copilot 的第二个能力模块上线。