在需求模糊或方案先行时，用状态诊断法澄清真实问题…

适用于软件项目早期或需求返工阶段，帮助独立开发者从模糊意图、方案执念、模糊需求、隐藏约束和范围蔓延中，诊断并收敛出可验证的 V1 需求。

适用场景

解决思路

1. 将每个需求当作「解决某个问题的假设」；不要只记录需求，要验证它是否解决真实问题。
2. 诊断时先听状态症状：判断当前情况描述的是 RA0、RA1、RA2、RA3、RA4 还是 RA5。
3. 从最早的问题状态开始：如果存在 RA0 症状，不要跳到 RA2。
4. 针对当前状态提出关键问题来收集信息。
5. 对当前状态应用相应干预练习和模板。
6. 进入下一状态前先验证：检查该状态指标是否满足。
7. 用模板产出工件以记录决策。
8. 检查 RA0 症状：从「我想构建 X」开始（解决方案而非问题）；无法说清谁有什么问题；用「每个人都需要这个」推理；功能列表没有问题依据；复制现有解决方案却不理解其存在原因。
9. RA0 关键问题：如果它不存在会怎样？谁会受影响？
10. RA0 关键问题：人们（或你自己）今天用什么替代方案？
11. RA0 关键问题：是什么触发你现在思考这件事？
12. RA0 关键问题：如果你是用户，是哪一个具体挫败导致你走到这里？
13. RA0 干预：做 Jobs-to-be-Done 自我访谈：『当我 [情境]，我想要 [动机]，以便我能 [结果]』。
14. RA0 干预：做问题考古：把想法的起源追溯到某个具体挫败。
15. RA0 干预：做「五个用户」测试：说出 5 个会受益的具体的人（即使其中一个是你自己）。
16. RA0 干预：使用 Problem Statement Brief（问题陈述简报）模板。
17. 检查 RA1 症状：需求描述实现（「需要一个数据库」「应该用 React」）；不提技术就无法解释需求；用「怎么做」回答「做什么」；功能嫉妒（复制现有解决方案）；在问题清晰前先选技术。
18. RA1 关键问题：如果那种技术不存在，你需要什么？
19. RA1 关键问题：这个功能产生什么结果？
20. RA1 关键问题：你是在解决自己的问题，还是在复制别人的解决方案？
21. RA1 关键问题：这个功能背后的需求是什么？
22. RA1 干预：做功能提取：把每条需求改写成「The system must [动词]...」，且不含技术词。
23. RA1 干预：做「移除解决方案」练习：用完全不涉及实现的方式描述需求。
24. RA1 干预：区分约束与偏好：这项技术是必需，还是只是熟悉？
25. RA1 干预：检查你是在构建你需要的，还是构建你知道怎么做的。
26. 检查 RA2 症状：「用户应该能够...」但没有具体内容；需求无法测试；形容词需求（「快」「简单」「直观」「现代」）；想象不出验收标准；无法描述「完成」是什么样。
27. RA2 关键问题：你怎么知道这条需求被满足了？
28. RA2 关键问题：满足这个需求的最小版本是什么？
29. RA2 关键问题：令人失望的实现与出色的实现分别是什么样？
30. RA2 关键问题：你能给出一个具体示例场景吗？
31. RA2 干预：做具体化阶梯：具体是谁？具体做什么？具体在什么时候？
32. RA2 干预：写验收场景：『给定 X，当 Y，则 Z』。
33. RA2 干预：做「完成看起来像...」练习：描述能满足需求的最小事物。
34. RA2 干预：做可测试性检查：如果无法测试，说明你还没理解它。
35. RA2 干预：使用 Need Hierarchy（需求层级）模板。
36. 检查 RA3 症状：实现中途才发现阻塞；说「哦，我忘了提...」；把假设当成事实；没有明确约束清单；意外依赖很晚才出现。
37. RA3 关键问题：这个上下文中什么是确定真实的？（真实约束）
38. RA3 关键问题：你假设什么是真的？（待验证假设）
39. RA3 关键问题：如果哪个假设为真会杀死这个项目？
40. RA3 关键问题：你实际拥有什么资源/技能/时间？
41. RA3 关键问题：存在哪些外部依赖？
42. RA3 干预：做约束清单：列出预算、时间、技能、依赖、集成。
43. RA3 干预：做假设映射：已验证假设 vs. 未验证假设。
44. RA3 干预：做风险预尸检：『6 个月后这个项目失败了。为什么？』
45. RA3 干预：做依赖发现：在这个能工作之前，必须先有什么存在？
46. RA3 干预：使用 Constraint Inventory（约束清单）模板。
47. 检查 RA4 症状：需求扩展速度快于被满足速度；出现「既然都做了，顺便...」的追加；无法区分核心与锦上添花；V1 与未来之间没有清晰边界；每个功能都感觉同等重要。
48. RA4 关键问题：最小有用的事物是什么？
49. RA4 关键问题：可以砍掉什么，同时仍解决核心问题？
50. RA4 关键问题：如果只能交付 3 个东西，是哪 3 个？
51. RA4 关键问题：什么触发重新考虑被推迟的事项？
52. RA4 干预：做 MoSCoW 优先级：必须/应该/可以/不会（Must/Should/Could/Won't）。
53. RA4 干预：识别「行走骨架」：最薄的有用版本。
54. RA4 干预：建立推迟功能清单，并写明重新考虑的明确触发条件。
55. RA4 干预：做强制定序练习：严格排序，不允许并列。
56. RA4 干预：采用先砍后加法：从全部拿掉开始，只加回必要项。
57. 检查 RA5 症状：能清楚说明问题、谁有问题、为什么当前方案失败；需求可测试且具体；约束明确（真实 vs. 假设）；范围有边界且有清晰 V1 定义；能向外行解释并让其理解。
58. RA5 指标：问题陈述不提及解决方案。
59. RA5 指标：每条需求都有验收标准。
60. RA5 指标：约束清单区分事实与假设。
61. RA5 指标：V1 边界明确，并列出推迟项。
62. RA5 指标：你知道什么会让这些需求变成错的。
63. RA5 下一步：把 Validated Requirements Document（已验证需求文档）交接给 system-design 技能。
64. 问题发现阶段提问：你在解决什么问题？
65. 问题发现阶段提问：谁有这个问题的？（要具体）
66. 问题发现阶段提问：没有这个解决方案时，他们今天怎么做？
67. 问题发现阶段提问：为什么以前没人解决？
68. 问题发现阶段提问：是什么触发了这个想法？
69. 需求澄清阶段提问：解决方案必须完成什么？
70. 需求澄清阶段提问：你怎么知道它在工作？
71. 需求澄清阶段提问：最小可行版本是什么？
72. 需求澄清阶段提问：什么会让你对结果失望？
73. 约束发现阶段提问：你实际的时间预算是什么？
74. 约束发现阶段提问：你有哪些技能/需要获取哪些技能？
75. 约束发现阶段提问：这必须与什么集成？
76. 约束发现阶段提问：你还有哪些假设未验证？
77. 约束发现阶段提问：什么会杀死这个项目？
78. 范围定义阶段提问：V1 里有什么，后续有什么？
79. 范围定义阶段提问：如果被迫砍，你会砍什么？
80. 范围定义阶段提问：什么触发重新考虑推迟项？
81. 范围定义阶段提问：明确不在范围内的是什么？
82. 避免 Solution Specification：不要写描述实现而非需求的内容；例如「系统应使用 PostgreSQL」不是需求，「数据必须在服务器重启后存活」才是需求。修复：对每条需求问「它能否用另一种方式满足？」，如果是，你可能抓的是实现而不是需求。
83. 避免 Stakeholder Fiction：不要由独立开发者想象需求（「用户会想要...」）而没有证据。修复：如果你就是用户，诚实写出你自己的需求；如果是为别人构建，去和他们交谈或使用类比证据；不要虚构用户。
84. 避免 Infinite Backlog：不要让需求在没有优先级的情况下增长，导致一切同等重要。修复：强制定序；如果只能交付一个东西，是什么？然后两个？这会揭示真实优先级。
85. 避免 Premature Precision：不要指定尚不重要的细节，例如在验证是否有人想要通知前就设计通知偏好界面。修复：识别哪些需求现在需要精确，哪些可以推迟；用「TBD after X validated」标记不确定区域。
86. 避免 Constraint Blindness：不要不盘点真实约束就开工，否则中途会撞上它们，例如「哦，我每周只有 10 小时」。修复：在需求之前显式做约束清单；这个上下文中什么是确定真实的？
87. 避免 Feature Transplant：不要从现有产品复制功能，却不理解它们为何存在或是否解决你的问题。修复：对每个「借来」的功能，说明它在你的上下文中解决什么问题；如果说不出来，就砍掉。
88. 健康检查：我是在描述问题还是解决方案？
89. 健康检查：我能把它解释给不熟悉的人，并让他们理解需求吗？
90. 健康检查：我会如何测试这条需求是否被满足？
91. 健康检查：我做了哪些尚未验证的假设？
92. 健康检查：这个范围在我实际约束下可达成吗？
93. 健康检查：什么明确不在范围内？
94. 健康检查：我是在构建我需要的，还是构建我知道怎么做的？
95. 健康检查：如果失败了，最可能的原因是什么？
96. 示例做法：面对「我想构建一个静态站点生成器」，先识别为 RA0；问「你在解决什么问题？现有静态站点生成器哪里让你挫败？」；开发者暴露「我厌倦复杂性，只想写 markdown 并得到 HTML，不要插件、主题、配置文件」；由此得到问题「现有工具对简单用例要求太多配置」；继续问「还有谁有这个问题？你今天用什么替代？」；按状态推进直到需求被验证。
97. 输出发现：在做任何其他工作前，检查项目中的 `context/output-config.md`。
98. 如果找到 `context/output-config.md`，查找本技能的条目。
99. 如果没找到或没有本技能条目，先问用户：『Where should I save requirements analysis output?』
100. 建议保存位置：`docs/requirements/` 或简单项目的项目根目录。
101. 存储用户偏好。
102. 持久化输出：Problem Statement Brief（问题陈述简报）。
103. 持久化输出：Need Hierarchy（需求层级）。
104. 持久化输出：Constraint Inventory with Assumption Map（约束清单与假设地图）。
105. 持久化输出：Scope Definition（V1 boundary、deferred items）。
106. 持久化输出：Validated Requirements Document（交接给 system-design）。
107. 写入文件：问题陈述。
108. 写入文件：需求层级。
109. 写入文件：约束清单。
110. 写入文件：范围定义。
111. 写入文件：已验证需求。
112. 留在对话中：Five Whys 探索。
113. 留在对话中：优先级讨论。
114. 留在对话中：假设发现对话。
115. 留在对话中：砍/留协商。
116. 留在对话中：澄清问题。
117. 文件命名模式：`requirements-{project-name}.md`，或在 `docs/requirements/` 中放多个文件。
118. 文件命名示例：`requirements-static-site-generator.md`。
119. 当多个解决方案看起来都可能时，使用 brainstorming 技能先探索，再决定一个。
120. 当领域知识缺口阻塞需求时，使用 research 技能填补知识缺口。
121. 交接就绪检查：问题被表述且不含解决方案。
122. 交接就绪检查：需求可测试且具体。
123. 交接就绪检查：约束已盘点（真实 vs. 假设）。
124. 交接就绪检查：范围有边界，且有明确 V1 定义。
125. 交接映射：Validated Requirements Document -> Design Context Brief。
126. 交接映射：Constraint Inventory -> Architecture constraints。
127. 交接映射：Need Hierarchy -> Quality attribute priorities。

适用边界 · 注意事项

• 需要直接编写代码、选择技术栈或设计架构时，不用本技能；应交给 system-design。
• 已经有经验证的需求文档，当前只需实现、技术选型或架构设计时，不用本技能。
• 问题尚未澄清时，不要继续讨论需求细节、优先级或技术方案；先回到更早的问题状态。