### 现象学还原（悬置假设）用于 vibe coding

**核心目的**
把“我以为需求是这样”从对话里剥离出去，只留下可观察、可复现、可检验的事实与体验结构，从而让模型在更少臆测的前提下产出可用代码。

---

## 1) 方法要点（在工程语境下怎么理解）

* **悬置（epoché）**：暂时不采纳任何“原因解释/业务推断/最佳实践偏好”。
  只记录：发生了什么、期望是什么、约束是什么。

* **还原（reduction）**：把问题还原到“给定输入→经过过程→得到输出”的最小结构。
  先不谈架构、模式、技术栈优雅与否。

* **意向性（intentionality）**：明确“这个功能是为谁、在什么情境下、要达成什么体验”。
  不是“做个登录”，而是“用户在弱网下也能在 2 秒内完成登录并得到明确反馈”。

---

## 2) 适用场景

* 需求描述充满抽象词：快、稳定、像某某一样、智能、顺滑。
* 模型开始“自带设定”：自己补产品逻辑、乱选框架、擅自加复杂度。
* Bug 复现困难：偶发、环境相关、输入边界不清。

---

## 3) 操作流程（可直接照做）

### A. 先“清空解释”，只保留现象

用四件套描述：

1. **现象**：实际发生的结果（含报错/截图/日志片段）。
2. **意图**：我想要的结果（可观察标准）。
3. **情境**：环境与前置条件（版本、平台、网络、权限、数据规模）。
4. **边界**：哪些不需要做/不要假设（不改接口、不引入新依赖、不改数据库结构等）。

### B. 产出“最小可复现体”（MRE）

* 最小输入样例（最短 JSON/最小表/最小请求）
* 最小代码片段（去掉无关模块）
* 明确复现步骤（1、2、3）
* 预期 vs 实际（对照表）

### C. 把“抽象词”降维成可测指标

* “快”→ P95 延迟 < X、冷启动 < Y、吞吐 >= Z
* “稳定”→ 错误率 < 0.1%、重试策略、熔断条件
* “好用”→ 交互反馈、错误文案、可撤销/可恢复

---

## 4) 给模型的提示词模板（可直接复制）

**模板 1：还原问题（禁止脑补）**

```
请先做“现象学还原”：不要推测原因、不要引入额外功能。
只根据我给的信息，输出：
1) 现象（可观察事实）
2) 意图（我想要的可观察结果）
3) 情境（环境/约束）
4) 未确定项（必须问清或需要我补的最小信息）
5) 最小可复现步骤（MRE）
然后再给出最小修复方案与对应测试。
```

**模板 2：抽象需求变可测规格**

```
把下面需求做“悬置假设”处理：删掉所有抽象词，转成可验证规格：
- 明确输入/输出
- 明确成功/失败判定
- 明确性能/资源指标（如需要）
- 明确不做什么
最后给出验收用例列表。
需求：<粘贴>
```

---

## 5) 在 vibe coding 的具体落地方式（习惯化）

* **每次开工先写“现象卡片”**（2 分钟）：现象/意图/情境/边界。
* **先让模型复述**：要求它只复述事实与缺口，不许给方案。
* **再进入生成**：方案必须绑定到“可观察验收”与“可证伪测试”。

---

## 6) 常见陷阱与对策

* **陷阱：把解释当事实**（“可能是缓存导致”）
  对策：把“可能”移到“假设列表”，每条假设配验证步骤。

* **陷阱：需求用形容词堆叠**
  对策：强制转成指标与用例；不满足“可测”不让写代码。

* **陷阱：模型自选技术栈**
  对策：边界里写死：语言/框架/依赖/接口不可变。

---

## 7) 一句话口诀（便于放进工具箱卡片）

**先悬置解释，再固定现象；先写验收标准，再让模型写实现。**