需要把发现笔记整理成工程可执行的 PRD 时…

适用于为主要功能或产品倡议从零撰写、结构化 PRD 并完成工程交接和干系人对齐。

适用场景

解决思路

1. 开工前收集输入：PRD 覆盖的功能或倡议；发现笔记、问题陈述、用户研究、成功指标、约束；把调用时提供的文本、粘贴的上下文或 appended ARGUMENTS: 行视为已给答案并跳过对应问题；若空手而来就从问题定义开始。
2. 建立 PRD 标准模板，按 10 个部分输出：Executive Summary、Problem Statement、Target Users & Personas、Strategic Context、Solution Overview、Success Metrics、User Stories & Requirements、Out of Scope、Dependencies & Risks、Open Questions；确保 PRD 回答：解决什么问题、为谁、为何现在、构建什么、如何衡量成功、需求是什么、不构建什么。
3. 使用 template.md 作为填写文档：利用每节的 Instructions、Steps、Contributing Skills、Activities；用 🔶 Assumption 和 🔵 Open Question 在缺口出现处内联标记；每节完成后做 Before moving on 跨节一致性检查；Section 10 后做自评；用技能交叉引用表映射 15 个技能到对应章节。
4. 若作为引导式对话运行，以 skills/workshop-facilitation/SKILL.md 作为交互协议：session heads-up + entry mode（Guided、Context dump、Best guess）、单问题轮次、进度标签、打断与暂停恢复、决策点编号建议、常规问题快速选择编号选项（含 Other (specify)）。
5. Phase 1：用 30 分钟写 Executive Summary，格式为 We're building [solution] for [persona] to solve [problem], which will result in [impact].；PM 参与；输出一段话总结；先写它来强制清晰，最后再润色。
6. Phase 2：用 60 分钟写 Problem Statement：使用 skills/problem-statement/SKILL.md；输入来自 skills/discovery-process/SKILL.md 或 skills/problem-framing-canvas/SKILL.md 的发现洞察；PM 参与 30 分钟；输出结构化问题陈述；内容包含谁有该问题、问题是什么、为什么痛苦、证据（客户引言、数据、研究）。
7. Phase 2 可选：加支持性上下文；若问题跨多个触点，用 skills/customer-journey-mapping-workshop/SKILL.md 输出的客户旅程图；若动机关键，用 skills/jobs-to-be-done/SKILL.md 输出的 Jobs-to-be-done；输出问题陈述和支持性工件。
8. Phase 3：用 30 分钟记录 Personas：使用 skills/proto-persona/SKILL.md 输出；PM 参与；格式包含 persona 名称、角色、目标、痛点、行为；区分 primary persona 和 secondary persona。
9. Phase 4：用 45 分钟记录 Strategic Context：记录 Business Goals，来源为公司 OKR、战略备忘录、路线图，格式为把功能关联到业务结果。
10. Phase 4：可选估算市场机会，使用 skills/tam-sam-som-calculator/SKILL.md，适用于重大倡议、新产品、高管演示，输出 TAM/SAM/SOM。
11. Phase 4：可选记录 Competitive Landscape，来源为竞品研究、G2/Capterra 评论。
12. Phase 4：解释“Why Now?”，说明为何现在优先于以后；输出业务目标、市场机会、竞争背景、紧迫性理由。
13. Phase 5：用 60 分钟写 Solution Overview：写高层描述，2-3 段；包括高层描述、用户流程或 wireframes、关键功能；保持高层，不写像素级 UI。
14. Phase 5 可选：加 User Flows 或 Wireframes，用 Figma、Sketch 或手绘草图；适用于需要视觉解释的复杂功能；嵌入 PRD 或链接。
15. Phase 5 可选：引用 Story Map，使用 skills/user-story-mapping-workshop/SKILL.md 输出；适用于有多个发布切片的复杂功能；链接到 story map。
16. Phase 6：用 30 分钟定义 Success Metrics：定义 Primary Metric，问“这个功能必须推动的唯一指标是什么”，写明当前值和目标值。
17. Phase 6：定义 Secondary Metrics，问“还应监控但不优化的指标是什么”，列出附加成功指标。
18. Phase 6：定义 Guardrail Metrics，问“什么不应变差”，列出防止回退的指标。
19. Phase 7：用 90-120 分钟写 User Stories & Requirements：写 Epic Hypothesis，使用 skills/epic-hypothesis/SKILL.md；PM 参与 30 分钟；输出 epic hypothesis statement。
20. Phase 7：把 Epic 拆成 User Stories，使用 skills/epic-breakdown-advisor/SKILL.md（交互式，含 Richard Lawrence 的 9 patterns）；PM、设计、工程参与；90 分钟；按 patterns（workflow、CRUD、business rules 等）拆分。
21. Phase 7：写 User Stories，使用 skills/user-story/SKILL.md；PM 参与；每个故事 30 分钟；格式为 user story + acceptance criteria；输出 3-10 个故事。
22. Phase 7：记录 Constraints & Edge Cases：技术约束、平台限制、浏览器支持等；边界情况，如用户跳过步骤、乱序完成。
23. Phase 8：用 30 分钟定义 Out of Scope & Dependencies：记录 Out of Scope，列出明确排除的功能或请求和原因，以及未来考虑项。
24. Phase 8：记录 Dependencies：技术依赖、外部依赖（集成、合作）、团队依赖（设计交接、数据管道工作）。
25. Phase 8：记录 Open Questions：未解决决策、需要发现或讨论的领域。
26. 按端到端时间表执行：Day 1 完成 Phase 1、2、3、4；Day 2 完成 Phase 5、6、7；Day 3 完成 Phase 8 和 Review & Refine；Day 4 可选 Stakeholder Review & Approval。总时间：快速 1.5-2 天，典型 2-3 天，复杂 3-4 天。
27. 避免孤立撰写 PRD：与设计加工程协作完成 Phase 7 的 user stories，最终定稿前评审草稿 PRD。
28. 问题陈述必须有证据：使用 skills/discovery-process/SKILL.md 的发现洞察，包含客户引言、分析数据、支持工单，不要只说“我们相信用户有这个问题”。
29. 方案不要过度规定：保持 Phase 5 高层，让设计负责 UI 细节，不要指定像素尺寸、按钮颜色。
30. 必须定义成功指标：始终在 Phase 6 定义 primary metric。
31. 必须记录 Out of Scope：在 Phase 8 明确记录不构建的内容，防止范围蔓延。
32. 保持 PRD 为活文档：它只框定问题和方案，不逐像素指定 UI；随交付学习持续演进，不冻结为瀑布合同；补充而非替代团队协作。
33. 参考相关技能与外部框架：Phase 2 参考 problem-statement、problem-framing-canvas、customer-journey-mapping-workshop；Phase 3 参考 proto-persona、jobs-to-be-done；Phase 4 参考 tam-sam-som-calculator；Phase 5 参考 user-story-mapping-workshop；Phase 7 参考 epic-hypothesis、epic-breakdown-advisor、user-story。外部框架：Martin Eriksson 的 How to Write a Good PRD、Marty Cagan 的 Inspired、Amazon 的 Working Backwards（PR/FAQ format）。

适用边界 · 注意事项

• 小型 bug 修复或琐碎功能，使用完整 PRD 过重。
• 问题和方案已经清晰且对齐，只需写 user stories 即可。
• 做连续发现实验，改用 Lean UX Canvas 更合适。