first-principles

第一性原理思维

一种系统化方法，将复杂问题拆解为基本事实，并从这些事实出发进行推理，避免陷入类比推理的误区。

基于 awesome-skills/first-principles-skill v0.2.0 定制——根据 Elon Musk 的要求质疑原则，新增了阶段 0（先删除）。

何时使用此技能

• 评估某种架构或设计是否真正最优
• 质疑可能不适用于当前情境的“最佳实践”
• 在常规解决方案显得不够理想时寻求突破
• 做出会产生长期影响的基础性决策
• 挑战遗留系统中继承下来的假设
• 设计新系统，避免盲目照搬现有模式
• 质疑某项需求或步骤是否真的有必要存在

核心流程

阶段 0：质疑需求本身（先删除）

在分析如何解决问题之前，先问问是否真的应该解决这个问题。

Elon Musk 的口头禅：“所有需求在某种程度上都很愚蠢。”最愚蠢的事，就是优化一个本不该存在的东西。

1. 尝试彻底删除这项需求——没有这一步／功能／约束，系统还能运行吗？
2. 如果可以删除，就删除——不要优化本该移除的东西。
3. 如果删除行不通，就把它加回来——只有这样才继续分析。
4. 质疑需求的提出者——聪明人提出的需求最危险，因为你不太可能质疑它们。始终要问：“提出这项需求的人能否豁免它？”

关键问题：

• 这项需求有必要存在吗？
• 如果我们直接移除这一步，会发生什么？
• 这是实际约束，还是历史遗留？
• 如果去掉这一项，用户真的会注意到吗？

警示信号（需求可能没有存在的必要）：

• “我们一直都有这一步”
• “法律／合规要求如此”（请核实——这通常已经过时）
• “用户会期待如此”（你最近问过他们吗？）
• “规范里就是这么写的”（谁写的规范？为什么这么写？）

阶段 1：找出问题的本质

剥离实现细节，找出核心问题：

1. 清楚地陈述问题——具体要解决什么？
2. 区分症状和原因——这是真正的问题，还是某种表现？
3. 定义成功标准——完美的解决方案应该实现什么？

关键问题：

• 这里要完成的根本任务是什么？
• 如果这个系统不存在，用户实际需要什么？
• 不论如何实现，什么结果才是重要的？

阶段 2：质疑所有假设

找出并质疑每一项假设：

1. 列出明确假设——我们把什么视为既定事实？
2. 揭示隐含假设——我们遵循了哪些未经质疑的惯例？
3. 检验每项假设——这真的是约束，还是只是一直以来的做法？

假设类别：

类别	要提出的问题
技术	“我们必须使用这种技术／模式吗？”
业务	“这项需求真的不可变吗？”
资源	“这些限制是真实存在的，还是我们认为存在的？”
历史	“当初为什么做出这个决定？”

警示信号（可能是错误的假设）：

• “我们一直都是这么做的”
• “行业标准是……”
• “大家都用 X 来做这个”
• “这么简单，肯定行不通”

阶段 3：确立基本事实

找出不可再约简的事实：

1. 物理／数学约束——哪些规律不可违背？
2. 业务不变量——业务必须保持哪些事实成立？
3. 用户需求——用户根本上需要什么？

基本事实检验：

• 还能进一步拆解吗？
• 这能证明为真，还是只是普遍认为如此？
• 如果违背这一点，是否一定会导致失败？

阶段 4：向上推理

从基本事实出发构建解决方案：

1. 从最简单的方案开始 - 满足基本事实的最简单方案是什么？
2. 只添加必要内容 - 每项新增内容都必须证明其必要性
3. 审视每一层 - 这一层的复杂性是否有其价值？

构件法：

Ground Truth → Minimal Solution → Justified Additions → Final Design
     ↑              ↑                    ↑
  (proven)     (sufficient)        (each defended)

阶段 5：验证推理

确保解决方案合理：

1. 追溯基本事实 - 每项设计决策是否都能追溯到基本需求？
2. 找出薄弱环节 - 推理在哪些地方依赖假设？
3. 压力测试 - 哪些因素可能导致此解决方案失效？

输出格式

运用第一性原理思维时，请按以下结构组织分析：

## First Principles Analysis: [Topic]

### 0. Requirement Check (Delete First)
**Tried deleting:** [What was attempted]
**Result:** [Deleted / Cannot delete because: ...]
**Verdict:** [Proceed / Requirement eliminated]

### 1. Problem Essence
**Core problem:** [One sentence]
**Success criteria:** [Measurable outcomes]

### 2. Assumptions Challenged
| Assumption | Challenge | Verdict |
|------------|-----------|---------|
| [Assumption] | [Why question it] | [Keep/Discard/Modify] |

### 3. Ground Truths
- [Irreducible fact 1]
- [Irreducible fact 2]
- [Irreducible fact 3]

### 4. Reasoning Chain
Ground Truth → [Step 1] → [Step 2] → Solution

### 5. Conclusion
**Recommended approach:** [Description]
**Key insight:** [What the first principles analysis revealed]
**Trade-offs acknowledged:** [What we're accepting]

常见模式

模式：复杂性陷阱

症状： 解决方案比问题本身所需的复杂得多

第一性原理检查：

1. 移除一个组件——系统是否仍能解决核心问题？
2. 如果可以，该组件就不是必需的
3. 重复此过程，直到移除某个组件会破坏核心功能

模式：类比陷阱

症状：“X 公司这样做，所以我们也应该这样做”

第一性原理检查：

1. X 公司实际要解决的是什么问题？
2. 我们的问题在所有相关方面都相同吗？
3. 他们有哪些约束是我们没有的（反之亦然）？

模式：遗留问题陷阱

症状： 为了兼容已不再有用的决策而维持现状

第一性原理检查：

1. 当初做出这一决策的原因是什么？
2. 当时的条件现在还存在吗？
3. 改变的实际成本与维护的成本分别是多少？

与其他思维工具结合

第一性原理思维与以下互补方法配合良好：

工具	适用场景	方法
权衡分析	找出基本事实之后	根据基本原理评估选项
5 个为什么	出现假设时	深入探究，找出根本原因
事前验尸	最终确定解决方案之前	对推理链进行压力测试
假设检验	基本事实尚不确定时	通过实证验证假设

适用边界

会做：

• 系统地质疑假设
• 从第一性原理出发找出基本事实
• 从基本原理构建推理链
• 揭示传统观念何时不适用
• 质疑需求本身是否有必要存在

不会做：

• 将所有现有解决方案都视为错误
• 在每项决策上花费无限时间（仅用于重要决策）
• 为追求理论纯粹性而忽视实际约束
• 保证给出“最佳”解决方案（揭示更好的推理方式，而非完美答案）

快速参考

第一性原理检查清单：

• 已测试是否可以删除该需求——能否将其彻底移除？
• 用结果而非解决方案来描述问题
• 明确列出所有假设
• 对每项假设提出质疑并说明理由
• 找出并验证基本事实
• 仅从基本事实出发逐步构建解决方案
• 每项设计决策都能追溯到某项基本事实
• 记录推理链

其他资源

参考文件

• references/elon-musk-examples.md - SpaceX 和 Tesla 的真实案例
• references/software-examples.md - 软件工程应用案例

示例文件

• examples/architecture-review.md - 对微服务决策进行第一性原理分析