AI 写 PRD 写得好看，但能用吗？GitHub 官方这个 Skill 给出了工程级答案

如果你这两年跟过 AI 产品开发的同学，最近应该都有同一个感受：产品经理越来越像”指挥 AI 写文档“的人了。一个想法丢给 AI，三分钟回你一份看起来还挺像样的 PRD——但真要用到团队里去评审，十份里有八份都是”漂亮但是没干货”。

这其实是 AI 圈 2026 上半年最值得盘点的一波小浪潮：LLM 写需求文档正在从”能写”走向”能写得像专业 PM 写的”。而 GitHub 官方在 awesome-copilot 仓库里塞进来的这个 prd Skill，就是这一波里非常典型、也非常克制的一个代表。

它到底解决了什么

prd 的全名是 Product Requirements Document Skill，目标很简单：让 AI 输出的 PRD 真的能拿去给工程团队评审。它跟一般”帮我写个 PRD”的 prompt 不一样的地方在于——它强制走一个三阶段访谈流，绝对不允许 AI 上来就开始编：

• Discovery（访谈）：必须先问清楚核心问题、衡量指标、约束条件（预算、技术栈、deadline），不准 AI 自作主张假设上下文。
• Analysis & Scoping（分析）：把零散输入合到一起，画用户流、明确 Non-Goals（明确不做什么）。
• Technical Drafting（落稿）：套用严格的 12 段 PRD Schema 输出，每段都有具体要求。

它写出来的 PRD 长什么样

跟一般 AI 输出的”看起来挺好但全是大词”的文档完全不同，prd 的输出约束里直接写明：禁用”fast、easy、intuitive”这种模糊词，必须用可测量的指标。比如同样是”搜索功能要快”，好的版本是：

搜索响应时间在 1 万条数据下 ≤ 200ms；Precision@10 ≥ 85%；UI 100% 通过 Lighthouse Accessibility 评分。

这种风格，是工程团队真能拿来验收的标准，不是给老板看的 PPT。

强制 12 段 PRD Schema

prd 把 PRD 的结构锁死成 12 个固定段落：Problem Statement、Proposed Solution、Success Criteria、User Personas、User Stories、Acceptance Criteria、Non-Goals、Tool Requirements、Evaluation Strategy、Architecture Overview、Integration Points、Security & Privacy、Phased Rollout、Technical Risks。

每一段都不是摆设——比如 Non-Goals 这一段的作用是”明确不做什么”，是保护 timeline 的关键；Evaluation Strategy 是 AI 功能 PRD 特有的，必须说清楚怎么测输出质量。

怎么用起来最有效

这个 Skill 的最佳实践不是”丢一个想法就出 PRD”，而是把它当成两轮对话的工作流：

1. 第一轮：你自己先想清楚”为什么要做、衡量成功的指标是什么”，然后让 AI 用 Discovery 阶段跟你访谈，把这些硬约束问出来。
2. 第二轮：再让 AI 落稿。落稿后不要直接发给团队，先逐段 review，特别是 Success Criteria 和 Non-Goals——这两段是 AI 最容易偷懒的地方。

给”AI 写文档”这类 Skill 的一个观察

盘点 2026 这半年所有做”AI 写 PRD/写文档”的工具，真正能用的只有两类：一类是把 prompt 工程做到极致（prd 就是这类，规则写得越死越好用），一类是接入了实时协作工具（Notion、Linear、Confluence）让 AI 边写边对齐团队上下文。

prd 属于前者。如果你只想要一个轻量、好 audit、不绑死某个平台的方案，GitHub 官方这个开源 Skill 是目前最干净的入口。

仓库地址在这里，全部开源、MIT 协议：github.com/github/awesome-copilot/tree/main/skills/prd

GitHub: https://github.com/github/awesome-copilot/tree/main/skills/prd