写PRD这件事，80%的人都在做无用功

写PRD这件事，80%的人都在做无用功

你有没有这种感觉：辛辛苦苦写了一份 PRD，开会的时候大家还是各执己见，开发说需求太模糊，产品说技术理解不了，最后返工三四次，文档越写越厚，效率越来越低。

问题根本不在「写」，而在于「怎么开始写」。

PRD 写作的核心误区

大多数人写 PRD 的方式是：拿到一个想法，直接打开文档开始敲键盘。

结果：写到一半发现逻辑不通，补充了 10 个细节才发现最核心的假设是错的；或者写出来的文档像需求清单，缺少背景、缺少上下文、缺少大家公认的「Done 的标准」。

PRD 不是需求清单，而是一座桥——一头连着业务愿景，一头连着技术实现。桥没搭好，两头的人就只能隔岸喊话。

这个 Skill 怎么解决这个问题

github/prd 是 GitHub 官方 awesome-copilot 技能库里的一员，专门用来生成高质量产品需求文档。它的方法论很清晰，分三个阶段：

第一阶段：Discovery（访谈）
在动笔之前，必须先搞清楚三个问题：我们要解决的核心痛点是什么？怎么衡量项目成功了？有什么约束条件（预算、技术栈、deadline）？这三个问题没答清楚，后续写的每一行字都是浪费时间。

第二阶段：分析与范围界定
把用户的输入综合起来，识别依赖关系和隐藏复杂度，梳理用户流程，明确「不做什么」来保护项目时间线。很多人忽略这一步，结果 PRD 越写越大，最后根本无法交付。

第三阶段：技术起草
严格按照 PRD Schema 输出文档，包含执行摘要、用户体验、AI 系统要求（如果适用）、技术规格、风险与路线图。没有多余废话，每个章节都有明确的输出标准。

为什么这对效率提升有意义

PRD 写作是产品工作中最耗时的环节之一。传统流程：写草稿 → 评审 → 打回 → 重写 → 再评审，往往要 3-4 个循环。

用这个 Skill 的价值不是让它帮你写，而是让你在动笔之前就把思路理清楚。它强迫你先回答最关键的问题，而不是先埋头写结论。把这个流程固化下来，后续的评审和开发周期会大幅缩短。

对于 AI 产品经理或独立开发者来说，这个 Skill 还能帮你快速建立完整的项目文档体系，让 AI Agent 在没有人工介入的情况下也能准确理解项目背景和目标。

怎么用

如果你在用 Claude Code、Cursor、Windsurf 等支持 Skills 的 AI 编码助手，可以直接安装这个 Skill。安装后，当你要写 PRD、文档需求或规划功能时，AI 会自动调用这个 Skill，引导你按照标准流程走完。

GitHub 官方出品，Star 数超过 20,000，安装量持续增长，是目前最被低估的效率工具之一。

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

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