problem-space

/problem-space

绘制解决方案所在的地形：目标、约束、系统、假设，以及哪些证据能证明这张地图有误。

问题空间先于解决方案空间。过早跳到代码会让你很快做出错误的东西。

何时使用

• 开始新工作、尚未进入实现阶段时
• 反复出现阻碍或补丁时
• 估算严重偏差时
• 约束被轻描淡写地带过时

**以下情况请跳过：**问题已充分理解，且你正在执行阶段。

问题空间流程

步骤 1：陈述目标

“我们要优化的是［结果］。”

明确指出能够体现成功的行为变化、指标或问题消失。功能不是目标。

步骤 2：梳理约束

列出视为固定不变的事项：

Constraint: [boundary]
Type: [hard | soft | assumed]
Reason: [why it exists]
Questioning: [could this be false?]

硬性约束不可变通。软性约束和假设约束可以质疑。不要因为实现起来容易，就说服自己忽略真实约束。

步骤 3：识别地形

仅记录会影响决策的地形信息：

• 涉及的系统；
• 受影响的用户／运营人员／下游系统；
• 出错时的影响范围；
• 先例或本地实践知识。

如果有 RNA/OH 上下文工具可用，可将防护措施和本地实践知识作为候选项，并注明来源；由人来选择哪些内容需要沿用。

步骤 4：建立情境模型

关联目标、地形、约束、假设、证据质量和未解问题。不会影响决策的事实只是噪声。

步骤 5：检验地图

揭示隐藏假设。检查 X-Y 是否不匹配。指出框架压力信号：表明约束、地形、假设或先例有误的证据。

如果约束、假设或未解问题仍未明确，就还没准备好进入 /solution-space。

输出格式

## Problem Space

**Scope:** [what area this covers]

### Objective
[Outcome, not feature]

### Constraints
| Constraint | Type | Reason | Question? |
|------------|------|--------|-----------|
| [boundary] | hard/soft/assumed | [why] | [could this be false?] |

### Terrain
- **Systems:** [what's involved]
- **Stakeholders:** [who's affected]
- **Blast radius:** [what breaks if wrong]
- **Precedents/metis:** [existing local knowledge]

### Situation Model
- **Explains:** [why these elements matter]
- **May hide:** [blind spots]
- **Evidence quality:** [observed / inferred / assumed]

### Assumptions and Open Questions
- [assumption or unknown] — [risk if false / when to answer]

### Frame-Stress Signals
- [evidence that should trigger problem-space revision]

### Ready for Solution Space?
[yes/no] - [why or what's missing]

会话交接

如果正在使用会话文件，请先阅读此前的 Aim，然后替换或追加 ## Problem Space。后续阶段会沿用明确的约束、假设、证据质量、框架压力信号和未解问题。