问题定义公式
R — 原文 (Reading)
> 问题其实就是你期望的东西和你体验的东西之间的差别。
>
> — Gause & Weinberg,《你的灯亮着吗》第3章
I — 方法论骨架 (Interpretation)
大多数人在遇到问题时，直接跳到"怎么解决"，却没有先搞清楚"这到底是什么问题"。本方法论的核心是一个可操作的公式：
问题 = 期望 - 体验
当你感到不满意、不对劲时，不是因为事情"客观上"出了问题，而是因为你的期望和你的实际体验之间存在差距。
这个公式提供了两条解决问题的路径：
1. 改变体验——让事情变成你期望的样子（最自然的反应）
2. 改变期望——调整你对事情的期待（往往被忽视但更高效）
关键是：两条路都是有效的。雷龙塔的电梯问题，既可以用技术手段缩短等待（改变体验），也可以用装镜子让人在等待时分心（改变时间感知=改变体验），也可以让人接受"等电梯就是需要这么久"（改变期望）。
A1 — 书中的应用 (Past Application)
案例 1: 雷龙塔电梯
- 问题: 办公楼电梯太慢，员工抱怨等待时间太长。
- 方法论的使用: 套入公式——期望：很快等到电梯；体验：等了很久。
- 结论: 缩短实际等待（工程方案）或让等待感知变短（装镜子方案）。
- 结果: 装了镜子后抱怨显著减少——改变了体验（时间感知），比换电梯便宜得多。
案例 2: 屋里太冷
- 问题: 读者感觉屋里太冷。
- 方法论的使用: 看温度计显示25°C——期望：暖和；体验：冷。
- 结论: 不是"客观上"冷，而是主观感受的差距。可以通过穿毛衣（改变体验）或接受25°C足够暖和（改变期望）解决。
- 结果: "幻觉中的问题是真正的问题"——主观差距本身就是真实的问题。
A2 — 触发场景 (Future Trigger) ★
用户会在什么情境下需要这个 skill?
- 用户说"好烦""好乱""不对劲"但无法明确说出问题是什么
- 用户描述了一个困扰，但听起来像是在描述表面症状而非根因
- 用户已经提出了一个"解决方案"（如"我需要重新设计这个模块"）但没说明解决的是什么问题
语言信号
- "感觉哪里不对"
- "这个东西体验很差"
- "说不清楚，就是不舒服"
- "I can't put my finger on it"
- "something's off"
与相邻 skill 的区分
- 与
problem-analysis-3steps的区别: 本 skill 给问题一个操作化定义（公式），三步法则是在已有定义的基础上做多角色分析。 - 与
dont-mistake-solution-for-problem的区别: 本 skill 是"问题是什么"，那个 skill 是"你说的不是问题而是方案"。
E — 可执行步骤 (Execution)
-
引导用户拆解"期望"和"体验"
- 问: "你期望的是什么样子的？"
- 问: "你实际体验到的是什么样子的？"
- 完成标准: 得到两个可对比的具体描述。 -
写出公式
- 在回答中明确呈现: "问题 = [期望] - [体验]"
- 完成标准: 用户能点头说"对，就是这个差距"。 -
列出两条路径
- 路径A（改变体验）: 列举 2-3 个可以让体验接近期望的方法
- 路径B（改变期望）: 列举 1-2 个调整期望的现实理由
- 完成标准: 至少有一个方案属于"改变期望"类别，因为这条路径最容易被忽略。
B — 边界 (Boundary) ★
不要在以下情况使用此 skill
- 用户已经能清晰定义问题（不需要公式简化）
- 问题是纯技术性的（如"这个API返回了500错误"——体验和期望的差距显而易见）
- 用户处于紧急危机中，需要立即行动而非反思
作者在书中警告的失败模式
- 匆忙跳到解决方案: 还没写清楚期望和体验就去想"怎么办"
- 忽视"改变期望"路径: 人类本能地倾向于改变外部世界，而非调整自己
作者的盲点 / 时代局限
- 公式偏向个人/小团队问题，对大系统问题需要补充系统思维
审计信息
- 验证通过: V1 ✓ / V2 ✓ / V3 ✓
- 蒸馏时间: 2026-07-29
