3.8 KiB
3.8 KiB
现象学还原（悬置假设）用于 vibe coding
核心目的 把“我以为需求是这样”从对话里剥离出去，只留下可观察、可复现、可检验的事实与体验结构，从而让模型在更少臆测的前提下产出可用代码。
1) 方法要点（在工程语境下怎么理解）
-
悬置（epoché）：暂时不采纳任何“原因解释/业务推断/最佳实践偏好”。 只记录：发生了什么、期望是什么、约束是什么。
-
还原（reduction）：把问题还原到“给定输入→经过过程→得到输出”的最小结构。 先不谈架构、模式、技术栈优雅与否。
-
意向性（intentionality）：明确“这个功能是为谁、在什么情境下、要达成什么体验”。 不是“做个登录”，而是“用户在弱网下也能在 2 秒内完成登录并得到明确反馈”。
2) 适用场景
- 需求描述充满抽象词：快、稳定、像某某一样、智能、顺滑。
- 模型开始“自带设定”：自己补产品逻辑、乱选框架、擅自加复杂度。
- Bug 复现困难：偶发、环境相关、输入边界不清。
3) 操作流程（可直接照做）
A. 先“清空解释”，只保留现象
用四件套描述：
- 现象：实际发生的结果（含报错/截图/日志片段）。
- 意图：我想要的结果（可观察标准）。
- 情境：环境与前置条件（版本、平台、网络、权限、数据规模）。
- 边界：哪些不需要做/不要假设（不改接口、不引入新依赖、不改数据库结构等）。
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) 一句话口诀（便于放进工具箱卡片）
先悬置解释，再固定现象；先写验收标准，再让模型写实现。