vibe-coding-cn/assets/documents/principles/philosophy/现象学还原.md

108 lines
3.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

### 现象学还原(悬置假设)用于 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) 一句话口诀(便于放进工具箱卡片)
**先悬置解释,再固定现象;先写验收标准,再让模型写实现。**