problem-statement

/problem-statement

定义问题框架。改变问题陈述，就会改变解决方案空间。

问题陈述是一种观察视角，而非现实本身。目标是构建一个合理、连贯且能促成行动的故事，并指出哪些情况会证明它有误，而不是面面俱到地描述一切。

适用时机

• 开始新工作、尚未选择解决方案时
• 解决方案显得牵强，或像是在绕过问题时
• 方法反复摇摆时
• 需求不断扩张时
• 怀疑这是一个 X-Y 问题时

跳过此步骤的情况： 你已经有了清晰的问题陈述。请转到 /solution-space。

按需加载的参考资料

只有当请求可能是 X-Y 问题、示例会有所帮助，或问题框架变得过于详细时，才加载 references/framing.md。

框定问题的流程

第 1 步：说明当前的问题框架

“目前的问题框架是：[问题的描述方式]。”

只记录会影响下一步行动的内容：所述问题、其中隐含的假设、固定与灵活的约束，以及能够让行动显得合理的最简单故事。

第 2 步：区分“是什么”和“怎么做”

好的问题陈述会说明必须改变什么，而不是如何改变。

检查：

• 描述的是症状或结果，而不是提议的解决方案吗？
• 不熟悉代码库的人能理解问题所在吗？
• 是否为多种解决方案留有空间？

第 3 步：识别约束

说明硬性约束、软性约束和假设。质疑软性约束和假设；不要试图协商取消硬性约束。

第 4 步：重新构建问题框架

采用以下格式：

[谁] 需要 [什么结果]，因为 [为何重要]，但目前 [什么因素在阻碍]。

好的问题陈述应简洁、聚焦结果、可测试、不限定解决方案，并且足够合理，能够指导下一步行动。

第 5 步：进行轻量压力测试

请思考：

1. 这个框架能促成行动吗？
2. 它揭示或掩盖了什么？
3. 什么合理的替代故事会改变解决方案空间？
4. 谁会持不同意见？他们会讲述什么替代故事？
5. 有什么证据能表明这只是一个症状？

输出格式

## Problem Statement

**Current framing:** [How the problem is currently being described]
**Reframed as:** [Your crisp problem statement]
**The shift:** [What changed in how we see it]

### Working Story
[The plausible story that makes this problem worth acting on now — concise, not exhaustive]

### Constraints
- **Hard:** [Actually immovable constraints]
- **Soft/assumed:** [Constraints that may be flexible]

### Assumptions Being Tested
- [assumption embedded in this framing]

### Frame Pressure Test
- Reveals/enables: [what this framing makes visible or easier]
- Hides/risks: [what this framing may obscure]
- Plausible alternate: [one alternate story that would change the solution space]
- Who disagrees: [stakeholder/role and the alternate story they would tell]

### Signal This Framing Is Wrong
[What evidence would show this frame is misleading or only a symptom]

会话交接

如果正在使用会话文件，请先读取之前的 Aim / Problem Space 和可选的 Problem Weave 候选框架，然后替换或追加 ## Problem Statement。将编织结果视为证据和备选方案，而非共识。后续阶段应沿用当前采用的故事、约束、假设、压力测试结果和失效信号。