把模糊功能想法或用户请求转成结构化…

当需要将模糊想法、问题陈述或用户需求整理为可评审、可执行的 PRD 或功能规格时使用。

适用场景

解决思路

1. 如果看到不熟悉的占位符或需要检查哪些工具已连接，查看 CONNECTORS.md。
2. 使用命令 /write-spec $ARGUMENTS。
3. 向用户确认要规格化的功能，接受任意输入：功能名称，例如 “SSO support”。
4. 接受任意输入：问题陈述，例如 “Enterprise customers keep asking for centralized auth”。
5. 接受任意输入：用户请求，例如 “Users want to export their data as CSV”。
6. 接受任意输入：模糊想法，例如 “We should do something about onboarding drop-off”。
7. 以对话方式收集上下文，不要一次性倾倒所有问题；先问最重要的问题，再逐步补齐。
8. 询问用户问题：这个功能解决什么问题？谁会遇到？
9. 询问目标用户：服务哪个用户群体？
10. 询问成功指标：如何知道它奏效？
11. 询问约束：技术约束、时间线、监管要求、依赖项。
12. 询问先例：以前是否尝试过？是否有现有解决方案？
13. 若 project tracker 已连接：搜索相关 tickets、epics 或 features。
14. 若 project tracker 已连接：拉取已有需求或验收标准。
15. 若 project tracker 已连接：识别对其他工作项的依赖。
16. 若 knowledge base 已连接：搜索相关研究文档、先前规格或设计文档。
17. 若 knowledge base 已连接：拉取相关用户研究发现。
18. 若 knowledge base 已连接：查找相关会议记录或决策记录。
19. 若 design 已连接：拉取相关 mockups、wireframes 或设计探索。
20. 若 design 已连接：搜索与该功能相关的设计系统组件。
21. 若这些工具未连接：完全基于用户提供的信息工作；不要要求用户连接工具，直接用现有信息继续。
22. 生成结构化 PRD，包含：Problem Statement、Goals、Non-Goals、User Stories、Requirements、Success Metrics、Open Questions、Timeline Considerations。
23. 撰写 Problem Statement：用 2-3 句话描述用户问题。
24. Problem Statement：说明谁经历该问题以及频率。
25. Problem Statement：说明不解决它的成本，包括用户痛点、业务影响、竞争风险。
26. Problem Statement：用证据支撑，包括用户研究、支持数据、指标或客户反馈。
27. 撰写 Goals：列出 3-5 个具体、可衡量的结果。
28. Goals：每个目标回答“我们如何知道它成功了？”。
29. Goals：区分用户目标（用户得到什么）和业务目标（公司得到什么）。
30. Goals：目标应是结果而非产出，例如 “reduce time to first value by 50%” 而不是 “build onboarding wizard”。
31. 撰写 Non-Goals：列出 3-5 件该功能明确不会做的事。
32. Non-Goals：列出本版本范围外的相邻能力。
33. Non-Goals：为每个非目标简要解释为何超出范围，例如影响不足、太复杂、独立计划、为时过早。
34. 撰写 User Stories：使用标准格式 “As a [user type], I want [capability] so that [benefit]”，按 persona 分组。
35. User Story：用户类型要具体到有意义，例如 “enterprise admin” 而不是 “user”。
36. User Story：能力描述用户想达成什么，而不是如何实现。
37. User Story：收益解释“为什么”，说明交付什么价值。
38. User Story：包含边缘情况：错误状态、空状态、边界条件。
39. User Story：若服务多个 persona，包含不同用户类型。
40. User Story：按优先级排序，最重要的故事放前面。
41. 撰写 Requirements：分为 Must-Have (P0)、Nice-to-Have (P1)、Future Considerations (P2)，每个都带验收标准。
42. Must-Have (P0)：没有它功能不能发布；代表最小可行版本；问“如果砍掉它，功能仍能解决核心问题吗？”若不能，就是 P0。
43. Nice-to-Have (P1)：显著改善体验，但核心用例没有它也能工作；通常是发布后的快速跟进。
44. Future Considerations (P2)：明确不在 v1 范围，但设计时要支持以后加入；记录它们可防止意外架构决策导致以后难以实现。
45. 对每条需求：写清楚、无歧义的预期行为描述。
46. 对每条需求：包含验收标准。
47. 对每条需求：注明技术考虑或约束。
48. 对每条需求：标记对其他团队或系统的依赖。
49. 撰写 Success Metrics：包含 leading indicators（快速变化）和 lagging indicators（随时间变化），并给出具体目标。
50. Leading Indicators：采用率，即 % eligible users who try feature。
51. Leading Indicators：激活率，即 % users who complete core action。
52. Leading Indicators：任务完成率，即 % users who successfully accomplish goal。
53. Leading Indicators：完成时间，即核心工作流需要多久。
54. Leading Indicators：错误率，即用户遇到错误或死胡同的频率。
55. Leading Indicators：功能使用频率，即用户多常回来使用。
56. Lagging Indicators：留存影响，是否改善用户留存。
57. Lagging Indicators：收入影响，是否推动升级、扩展或新收入。
58. Lagging Indicators：NPS/满意度变化，是否改善用户对产品的感受。
59. Lagging Indicators：支持工单减少，是否降低支持负担。
60. Lagging Indicators：竞争胜率，是否帮助赢得更多交易。
61. 设定目标：目标要具体，例如 “50% adoption within 30 days” 而不是 “high adoption”。
62. 设定目标：基于类似功能、行业基准或明确假设来定目标。
63. 设定目标：设置 success 阈值和 stretch 目标。
64. 设定目标：定义测量方法：什么工具、什么查询、什么时间窗口。
65. 设定目标：指定评估时间：发布后 1 周、1 个月、1 个季度。
66. 撰写 Open Questions：列出实现前或实现中需要回答的问题。
67. Open Questions：给每个问题标记应由谁回答，包括 engineering、design、legal、data、stakeholder。
68. Open Questions：区分阻塞性问题（开始前必须回答）和非阻塞性问题（实现中解决）。
69. 撰写 Timeline Considerations：列出硬性截止日期，包括合同承诺、活动、合规日期。
70. Timeline Considerations：列出对其他团队工作或发布的依赖。
71. Timeline Considerations：若功能对一个版本太大，建议分阶段。
72. 写用户故事时确保 Independent：可独立开发和交付。
73. 写用户故事时确保 Negotiable：细节可讨论，故事不是合同。
74. 写用户故事时确保 Valuable：对用户有价值，而不只是对团队。
75. 写用户故事时确保 Estimable：团队能粗略估算工作量。
76. 写用户故事时确保 Small：可在一个 sprint/iteration 完成。
77. 写用户故事时确保 Testable：有明确方式验证有效。
78. 避免常见用户故事错误：太模糊，如 “As a user, I want the product to be faster”，要明确什么更快。
79. 避免常见用户故事错误：方案规定式，如 “As a user, I want a dropdown menu”，描述需求而非 UI 控件。
80. 避免常见用户故事错误：没有收益，如 “As a user, I want to click a button”，要说明为什么、达成什么。
81. 避免常见用户故事错误：太大，如 “As a user, I want to manage my team”，拆成具体能力。
82. 避免常见用户故事错误：内部视角，如 “As the engineering team, we want to refactor the database”，这是任务，不是用户故事。
83. 需求分类使用 MoSCoW：Must have，没有它功能不可行，不可谈判。
84. MoSCoW：Should have，重要但发布非关键，高优先级快速跟进。
85. MoSCoW：Could have，有时间就做，砍掉不会延迟交付。
86. MoSCoW：Won't have (this time)，明确范围外，未来版本可能重访。
87. 分类技巧：对 P0 要狠；must-have 列表越紧，发布和学习越快。
88. 分类技巧：如果什么都是 P0，就什么都不是 P0；挑战每个 must-have：“没有它我们真的不发布吗？”。
89. 分类技巧：P1 应是你确信很快会构建的东西，而不是愿望清单。
90. 分类技巧：P2 是架构保险，即使现在不构建，也指导设计决策。
91. 验收标准用 Given/When/Then 格式或清单格式。
92. Given/When/Then：写 Given [precondition or context]。
93. Given/When/Then：写 When [action the user takes]。
94. Given/When/Then：写 Then [expected outcome]。
95. 清单格式验收标准示例：Admin can enter SSO provider URL in organization settings。
96. 清单格式验收标准示例：Team members see “Log in with SSO” button on login page。
97. 清单格式验收标准示例：SSO login creates a new account if one does not exist。
98. 清单格式验收标准示例：SSO login links to existing account if email matches。
99. 清单格式验收标准示例：Failed SSO attempts show a clear error message。
100. 验收标准技巧：覆盖 happy path、错误情况和边缘情况。
101. 验收标准技巧：具体说明预期行为，而不是实现。
102. 验收标准技巧：包含不应发生什么，即负面测试用例。
103. 验收标准技巧：每条标准应可独立测试。
104. 验收标准技巧：避免模糊词 “fast”、“user-friendly”、“intuitive”，具体定义它们。
105. 识别范围蔓延：需求在规格批准后不断添加。
106. 识别范围蔓延：“小”新增累积成显著更大的项目。
107. 识别范围蔓延：团队构建没有用户要求的功能，即 “while we're at it...”。
108. 识别范围蔓延：发布日期不断移动却没有明确重新规划范围。
109. 识别范围蔓延：stakeholders 添加需求却不移除任何东西。
110. 防止范围蔓延：在每个规格中写明确的 non-goals。
111. 防止范围蔓延：要求任何范围新增都必须伴随范围移除或时间线延长。
112. 防止范围蔓延：在规格中清楚分开 “v1” 和 “v2”。
113. 防止范围蔓延：对照原始问题陈述审查规格，确认所有内容都服务于它。
114. 防止范围蔓延：给调查设置时间盒，例如 “If we cannot figure out X in 2 days, we cut it”。
115. 防止范围蔓延：为不在范围内的好想法创建 “parking lot”。
116. 输出格式：使用 markdown 和清晰标题；保持文档可扫描，忙碌的 stakeholder 只读标题和粗体即可了解大意。
117. 对范围有主见；紧凑、定义良好的规格优于宽泛模糊的规格。
118. 如果用户想法对一个规格太大，建议拆成阶段，并先为第一阶段写规格。
119. 成功指标应具体可衡量，不要模糊，例如 “improve user experience”。
120. Non-goals 与 goals 同等重要；它们防止实现期间范围蔓延。
121. Open questions 应真正开放，不要包含能从上下文回答的问题。
122. 生成 PRD 后，询问用户是否有章节需要调整。
123. 生成 PRD 后，主动提出可扩展特定章节。
124. 生成 PRD 后，主动提出可创建后续产物，包括 design brief、engineering ticket breakdown、stakeholder pitch。

适用边界 · 注意事项

• 不适用于只需要代码实现、调试、部署操作，不需要产品需求或范围对齐的场景。
• 不适用于已有明确详细需求且无需生成 PRD、用户故事、成功指标和验收标准的场景。
• 不适用于替代法律、合规、安全审查或最终设计稿的场景。