用途
第一性原理思维是一种系统化方法，用于将复杂问题分解为基本事实，再从这些事实向上推理，避免陷入“类比推理”的陷阱。该技能适用于需要从根本重新检查一个设计、需求或做法是否成立的场景。
何时使用
- 评估某个架构或设计是否真正最优
- 质疑可能不适用于当前情境的“最佳实践”
- 当传统方案感觉不够用时打破僵局
- 做出具有长期影响的基础性决策
- 挑战遗留系统中继承下来的假设
- 设计新系统时避免照搬既有模式
- 质疑某个需求或步骤是否根本不该存在
核心流程
阶段0：质疑需求本身（删除优先）
在分析如何解决问题之前，先问这个问题是否应该被解决。
- 尝试彻底删除该需求——系统能否在没有这个步骤/功能/约束的情况下工作？
- 如果能删除，就删除——不要优化本应移除的东西。
- 如果删除失败，再加回来——只有这时才进入分析。
- 挑战需求的归属者——来自聪明人的需求最危险，因为你不太会质疑它们。始终问：“提出这个需求的人能否放弃它？”
关键问题：这个需求需要存在吗？如果直接移除这一步会怎样？这是真实约束还是历史遗留？如果它消失了用户会注意到吗？
危险信号（需求可能不需要存在）：“我们一直有这个步骤”“法律/合规要求它”（需核实，往往已过时）“用户期望它”（你最近问过他们吗？）“规格书里就是这么写的”（谁写的规格书，为什么？）
阶段1：识别问题的本质
剥离实现细节，找到核心问题：清晰陈述问题、区分症状与原因、定义成功标准。
关键问题：这里要完成的根本任务是什么？如果这个系统不存在，用户实际需要什么？什么结果重要，与如何达成无关？
阶段2：挑战所有假设
识别并质疑每一个假设：列出显性假设、揭示隐性假设、检验每个假设。
假设类别与对应问题：技术类——“我们必须使用这种技术/模式吗？”；业务类——“这个需求真的是固定的吗？”；资源类——“这些约束是真实的还是感知的？”；历史类——“这个决定最初为什么做出？”
危险信号（很可能是错误假设）：“我们一直这么做”“行业标准说……”“大家都用X来做这个”“那太简单了，不会有用”。
阶段3：确立基本事实
识别不可再分解的事实：物理/数学约束（什么不能被违反）、业务不变量（什么必须保持为真）、用户需求（用户根本需要什么）。
基本事实检验：这还能进一步分解吗？这是可证明为真，还是只是普遍相信？违反它一定会导致失败吗？
阶段4：向上推理
从基本事实构建方案：从最小开始（满足基本事实的最简单方案是什么）、只添加必要部分（每个添加都必须自我证明）、挑战每一层（这一层配得上它的复杂度吗？）。
构建路径：基本事实 → 最小方案 → 有理由的添加 → 最终设计。
阶段5：验证推理
确保方案可靠：回溯到基本事实（每个设计决策都能追溯到根本需求吗？）、识别薄弱环节（推理在哪里依赖假设？）、压力测试（什么会破坏这个方案？）。
输出格式
应用第一性原理思维时，按以下结构组织分析：
## 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]
常见模式
复杂度陷阱：症状是方案比问题本身更复杂。检查方法：移除一个组件，系统还能解决核心问题吗？如果能，该组件就不是必需的；重复直到移除会破坏核心功能。
类比陷阱：症状是“X公司这么做，所以我们也该这么做”。检查方法：X公司实际在解决什么问题？我们的问题在所有相关维度上完全相同吗？他们有哪些我们没有的约束（反之亦然）？
遗留陷阱：症状是维护不再服务于我们的旧决策的兼容性。检查方法：这个决定最初的原因是什么？那些条件还存在吗？改变的真实成本与维护成本相比如何？
与其他思维工具的配合
- 权衡分析：在识别基本事实之后，用根本原则评估选项
- 5个为什么：当假设浮现时，深入挖掘根本原因
- 事前验尸：在最终确定方案前，对推理链做压力测试
- 假设检验：当基本事实不确定时，用实证验证假设
边界
会做：系统化挑战假设、从第一性原理识别基本事实、从根本构建推理链、揭示传统智慧不适用之处、质疑需求是否应该存在。
不会做：全盘否定所有现有方案、对每个决策都无限投入时间（应保留给重要选择）、为追求理论纯粹而忽略实际约束、保证给出“最佳”方案（它揭示更好的推理，而非完美答案）。
快速参考
第一性原理检查清单：
- 需求已测试删除——能完全移除吗？
- 问题以结果而非方案陈述
- 所有假设已明确列出
- 每个假设已挑战并证明
- 基本事实已识别并验证
- 方案仅从基本事实构建
- 每个设计决策可追溯到基本事实
- 推理链已记录
附加资源
参考文件：
- references/elon-musk-examples.md——来自SpaceX和Tesla的真实案例
- references/software-examples.md——软件工程应用
示例文件：
- examples/architecture-review.md——对微服务决策的第一性原理分析