关于 prd-writing
用于编写简洁、以证据为先的产品需求文档（PRD）的技能，面向产品团队。它提供固定章节、优先级和指标规范，强调从客户证据出发并明确范围边界。
主要功能
- 01按固定结构组织 PRD
- 02以客户证据描述问题
- 03用可衡量结果设定目标
- 04按 P0、P1、P2 排定需求
- 05为指标配套反向指标
- 06明确范围外事项
适用场景
- 01整理有客户证据支撑的需求
- 02为功能定义可衡量目标
- 03区分必须项与后续需求
- 04在立项时约束功能范围
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/prd-writing确认已加载。
详细介绍
撰写以证据为先、简洁且便于浏览的 PRD。PRD 是一种思考工具——如果超过 1200 个词，说明作者还没想透。简短的规格文档更容易被阅读、更容易被遵循，也更有可能按时交付。
结构
遵循以下结构。除非标记为可选，否则每个部分都是必需的。
1. 问题
从客户证据切入：引述、数据、支持工单、观察到的行为。如果没有证据，请明确说明——这是一份由观点驱动的 PRD，应予以标注。
示例：
“5 位受访客户中有 3 位在团队邀请步骤放弃了引导流程。关闭标签页前平均停留时间：47 秒。”
不要写：“用户觉得引导流程令人困惑。”
2. 目标
写可衡量的结果，而非产出。每个目标都要有具体数字。
- “将引导流程的流失率从 60% 降至 30% 以下”
- 不要写：“改善引导体验”
3. 目标用户
明确指出谁会受益。范围要具体。“在首次招聘产品经理前负责产品管理工作的 A 轮初创公司创始人”——而不是“产品经理”。
4. 需求
使用 P0/P1/P2，并给出清晰定义：
- P0 — 缺少此项就无法发布。没有此项，功能就会出故障或毫无用处。
- P1 — 可以不包含此项发布，但体验会显著下降。如果可能，应在同一周期内完成。
- P2 — 有则更好。可作为快速后续迭代的候选项。
每条需求都用一句话表达。如果一条需求需要一段话才能解释清楚，那它就太大了——拆分它。
5. 成功指标
必须是数字。始终使用数字。“在 W 周内将 X 从 Y 降至 Z。”
每个指标都必须配一个反向指标，防止指标被钻空子：
- 指标：“将激活率提升至 70%”
- 反向指标：“同时确保 30 天留存率不低于 45%”
6. 不在范围内
说明你有意不构建什么，以及原因。本部分可以防止范围蔓延，并表明你认真考虑过边界。
7. 待解决问题（可选）
列出需要他人提供意见的未决事项。每个问题都要注明应由谁回答，以及截止时间。
指南
- **重要：**最多 800–1200 个词。PRD 越长，说明思考越不充分。
- 绝不要从解决方案入手。要从有证据支撑的问题开始。
- 绝不要包含实现细节——架构、API、数据库架构。这些属于规格文档，而非 PRD。
- **始终包含“不在范围内”部分。**没有边界的 PRD 会助长范围蔓延。
- **始终将需求追溯到客户证据。**没有证据 = 观点。
- 绝不要使用含糊的指标：“提升性能”“改善体验”“提高参与度”。要给出具体数字，否则就不要写。
- P0 需求应为 3–5 条。如果超过 5 条，说明你还没做好优先级排序。
示例：好与坏
不好的 P0 需求：
“系统应以安全且易用的方式处理身份验证，支持多种提供商及边缘情况。”
好的 P0 需求：
“P0：用户可以使用电子邮箱 + 密码注册和登录。Google OAuth 属于 P1。”
一句话。范围明确。优先级迫使你做出取舍。
基于 Linear 的“简短规格文档 > 穷尽式文档”理念。技能来自 productskills。