关于 writing-prds
Writing Product Requirement Documents 是一项帮助产品团队编写和审阅 PRD 的技能，内容源自 14 位嘉宾及文章的见解。它强调简洁的问题陈述、可衡量的成功指标、明确的范围，以及为团队创意留出空间的文档。
主要功能
- 01撰写不预设方案的问题陈述
- 02定义可衡量的成功指标
- 03尽早界定项目范围
- 04审阅草稿的清晰度与简洁性
- 05使用 PRD 模板和审阅清单
适用场景
- 01将模糊需求转化为明确项目
- 02先统一团队对问题的理解
- 03检查 PRD 的范围和可读性
- 04用简洁的一页文档启动项目
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/writing-prds确认已加载。
附带文件references/artifacts.mdreferences/guest-insights.md
详细介绍
编写产品需求文档
明确问题并界定解决方案的范围，以最大限度地提升团队效率和创意产出。
借助 Lenny's Podcast 和 Newsletter 中 14 位嘉宾及文章的见解，帮助用户编写产品需求文档。
如何提供帮助
- 起草核心问题 - 协助阐述简洁的问题陈述，不受任何特定解决方案的限制。
- 确立成功指标 - 帮助定义具体且可衡量的结果，用作筛选未来功能请求的标准。
- 界定项目边界 - 指导用户运用塑形技巧，将模糊的请求收敛为范围明确的概念。
- 审查清晰度 - 检查现有草稿是否简洁、易读且具备技术意识，避免事无巨细地管理。
核心原则
面向功能原型进行设计
Jenny Wen：“我们过去常常规划两年、五年，甚至十年的愿景。现在，愿景变成了未来三到六个月的目标，而且不一定要制作精美的演示文稿，有时只需制作一个能为大家指明方向的原型。”
设计应注重短期功能原型，而不是静态的长期规划，以跟上 AI 驱动的工程开发速度。
尽早明确项目边界
Ryan Singer：“在塑形会议中，我们需要最终形成某种图表，让工程、产品和设计团队都能说：‘我们明白了。’所以，首先，如果我们无法从一开始就看清终点，就不会启动项目。”
通过设计与工程团队的高强度协作会议，在开发开始前就对项目边界达成共识。
让文档以问题为中心
摘自《1 页纸和 PRD 的示例与模板》：“以问题为导向：用几句有力的话阐明要解决的问题——最好放在文档靠前的位置——让每位队友的脑力都集中在同一个方向上。”
成功的 PRD 应从明确定义的问题和具体的成功指标开始，确保团队先就原因达成共识，再讨论具体内容。
以简洁促清晰
摘自《我最喜欢的产品管理模板》：“提醒大家，至少在一开始，将文档控制在一页以内有多重要。”
将初始项目文档限制在一页内，能迫使团队聚焦核心目标，并有助于避免过早增加复杂性。
通过记录将混乱转化为清晰
Melanie Perkins：“我们有一个从混乱走向清晰的概念：每个想法都从混乱的一端开始，然后你必须一路走到另一端，也就是清晰。混乱可以是一种想法、一个问题、一种理念或一种信念。”
将抽象想法记录下来，是把模糊概念转化为可执行项目的关键第一步。
避免过度干预创意
摘自《惹人厌的产品经理的五个习惯》：“项目规格中阐述重要细节，与花三页解释一个按钮之间只有一线之隔。这种恼人的习惯可能出现在项目开始时，比如告诉设计师和工程师功能必须如何运作；也可能出现在项目结束时，比如花好几天逐一详细说明每项功能。”
对功能规定过于详尽会扼杀工程师和设计师的创造力。文档应促进交流，而非取而代之。
利用 AI 自动化技术写作
摘自《AI 将如何影响产品管理》：“用自然语言描述你的需求，获得一份完成度达 80% 的草稿，再进行完善，然后发布。ChatPRD 等工具已经开始实现这一点。”
使用 AI 工具生成大部分技术文档，让产品经理专注于最终完善和战略层面的细微之处。
模板与框架
- Lenny 的 1 页纸模板（1 页纸和 PRD 的示例与模板）——Lenny 开始任何新项目时都会使用的个人模板
- 优秀 1 页纸/PRD 的 5 个要素（1 页纸和 PRD 的示例与模板）——用于评估产品规格是否有效的评分标准，可用于撰写和审阅 PRD
- AI 提示词：撰写 PRD（产品经理是个不公平的职位。所以就不公平地工作吧。）——ChatGPT 提示词模板（GPT-4o 及更高版本），可通过语音转文字口述背景信息来起草 PRD。
- 面包板设计与粗记号笔草图（Ryan Singer）——两种用于塑造方案的协作技巧，比线框图更细致、比 Figma 成品更粗略，旨在清晰传达想法
- PRD 和功能开发的技术类 PM 问题（成为更懂技术的产品经理）——PM 撰写 PRD 或开发功能时应提出的问题，有助于展现技术意识并改善协作
- 优秀问题陈述的五个特征（解决问题的三步框架 👌）——用于评估问题陈述是否完善的标准，撰写 1 页纸的问题部分时可参考。
- PRD 审阅清单（源自 Lenny 的评审意见）（1 页纸和 PRD 的示例与模板）——根据 Lenny 对四个真实案例的评估整理而成的清单，列出了需要检查的常见问题
- Duolingo 单页模板（Duolingo 如何打造产品）——Duolingo 在早期产品评审中使用的单页模板，用于征求对功能创意的反馈
完整列表及详情请参见 references/artifacts.md。
帮助用户思考的问题
- “这个项目要为用户解决的最重要问题是什么？”
- “我们会使用哪些具体指标来判断这个项目是否成功？”
- “这个版本明确不包含哪些功能或任务？”
- “我们是否已经收集了工程团队对技术限制的反馈？”
- “我们愿意在这个问题上投入多少时间，然后再转向其他事情？”
- “这份文档是否足够简洁，能让整个团队都愿意阅读？”
需要指出的常见错误
- 使用“只是”一词——这会贬低工程师的专业能力，还可能因不切实际的快速修复承诺而让他们筋疲力尽。
- 过早制作高保真原型——在团队充分探索问题范围或技术限制之前，就将团队锚定在某个具体方案上。
- 忽略非目标——未能明确哪些内容不会构建，会导致范围蔓延，并使团队偏离核心问题。
- 瀑布式交接——让设计师和工程师无法参与早期规划，会造成效率低下，并错失创新机会。
深入了解
14 位嘉宾分享的 24 条精选见解详见 references/guest-insights.md
相关技能
- 交付速度
- AI 辅助原型设计
- 使用 AI Agent 构建
- 产品工具栈