first-principles-thinking

第一性原理思维

一种系统化方法，将复杂问题拆解为不可再约简的真理，并以此为基础层层推理——避免陷入依赖类比、惯例或“最佳实践”进行推理的陷阱。

何时使用

• 评估某种架构、设计或策略是否真正最优
• 质疑可能不适用于当前情境的“最佳实践”
• 常规方案感觉不够理想时，寻找突破口
• 做出影响深远的基础性决策
• 挑战遗留系统或传统思维中沿袭下来的假设
• 任何以“我们一直都是这么做的”作为主要依据的时刻

何时不使用

• 琐碎的决策（改用奥卡姆剃刀——直接选择最简单的方案）
• 时间紧迫的紧急情况（先行动，后分析）
• 已充分验证且有成熟方案的问题（不必重复造轮子）
• 缺乏领域专业知识且无法获取时（缺乏知识的第一性原理思维只会导向幼稚的方案）

---

核心方法：6 个阶段

阶段 0：界定问题——确立公理

开始分析之前，先定义约束该领域的不可再约简真理。

公理 = 可独立验证、无法进一步拆解，且违背后必定导致失败的事实。

如何识别公理：

• 问：“还能进一步拆解吗？”——如果能，它还不是公理。
• 问：“这是可以证明的事实，还是只是普遍认同的看法？”——如果不确定，那就是假设。
• 问：“违背这一点是否一定会导致失败？”——如果不一定，那它只是偏好。

门槛：继续之前必须提出 ≥3 条公理。每条公理都要用一句话陈述，并说明其“不可再约简”的理由。

### Axioms
1. [Axiom] — [Why this cannot be further decomposed]
2. [Axiom] — [Why this is provably true]
3. [Axiom] — [Why violating this causes failure]

深入方法：references/axiom-based-reasoning.md

阶段 1：找出问题的本质

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

1. 清楚陈述问题——究竟需要解决什么？
2. 区分症状与原因——这是实际问题，还是某种表现？
3. 定义成功标准——完美的解决方案应实现什么？（可衡量。）

关键问题：

• 这里要完成的根本任务是什么？
• 如果这个系统／流程不存在，我们实际上需要什么？
• 不考虑如何实现，什么结果才是重要的？

门槛：必须用一句话陈述问题，并提供可衡量的成功标准。

阶段 2：揭示并质疑所有假设

这是最具杠杆效应的阶段。大多数“最佳实践”都是伪装成事实的假设。

1. 列出明确假设——我们把什么视为既定条件？
2. 揭示隐含假设——我们在不加质疑地遵循哪些惯例？
3. 逐一对照公理检验——这真的是一项约束（可追溯至公理），还是只是一贯以来的做法？

最低要求：提供一张至少有 5 行的假设表。

假设	质疑理由	使用的公理	判断
“我们需要 X”	[质疑]	A1, A2	保留 / 舍弃 / 修改

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

• “我们一直都是这么做的”
• “行业标准就是……”
• “大家都用 X 来做这个”
• “这么简单的方案不可能奏效”

深度标准：每一行都必须说明为什么要质疑，以及哪些公理支持这一判断。只说“可能不需要”而不提供理由 = 深度不足。

门槛：至少质疑 5 条假设并给出判断。每个判断都必须引用至少一条公理。

深入方法：references/axiom-based-reasoning.md §“识别并质疑假设”

阶段 3：确立基本事实

从受到质疑的假设残骸中，找出针对这一具体问题不可再分的真实情况。

基本事实检验：

• 是否还能进一步分解？→ 如果可以，就继续分解。
• 这是否是可证明的事实，而不只是普遍认同的观点？→ 如果不确定，它仍然是假设。
• 违反这一点是否必然导致失败？→ 如果不会，那它只是偏好。

关卡：必须提出 ≥3 条基本事实。每条都必须具体且可证伪，不能是泛泛而谈的常识。

❌ "Users need fast response times" (too vague)
✅ "P99 latency must be < 200ms per SLA contract §3.2" (specific, verifiable)

❌ "The team is small" (relative)
✅ "Team is 3 engineers, no new hires possible before Q3" (concrete constraint)

阶段 4：由下而上推理

仅基于基本事实构建解决方案。每一层都必须说明其存在的理由。

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

1. 从最小方案开始 — 满足所有基本事实的最简单方案是什么？
2. 只添加必要内容 — 每项新增内容都必须引用一条基本事实或公理。
3. 质疑每一层 — 这一层的复杂度是否合理？

关卡：必须得出推理链，其中每一步都能追溯到一条基本事实。

### Reasoning Chain
GT#1 (latency < 200ms) + GT#3 (3-person team) → Eliminate distributed architecture
GT#2 (read-heavy 95%) + GT#1 → Add read cache with 30s TTL
→ Conclusion: Monolith + in-memory cache

阶段 5：验证并进行压力测试

在采取行动前，确保推理可靠。

三个验证问题（完成关卡）：

#	问题	失败意味着什么
1	每个结论都能追溯到一条基本事实吗？（可追溯性）	你在阶段 4 引入了缺乏依据的假设
2	每条基本事实都至少由一个结论覆盖吗？（完整性）	你的解决方案忽略了一项约束，必将在此处失败
3	是否跳过了某些阶段，或对其分析不够深入？（诚实性）	返回并完成这些阶段

使用互补模型进行压力测试：

模型	要问的问题	适用场景
事前验尸	“12 个月后，这件事失败了。原因是什么？”	当你对解决方案充满热情时
二阶思维	“如果这行得通，接下来会发生什么？再之后呢？”	当解决方案会产生系统性影响时
反向思考	“什么会确保失败？我们是否正在做其中任何一件事？”	当你需要发现盲点时
OODA 行动	“现在能做的最小测试是什么？”	当分析陷入瘫痪时

完整模型工具集：references/thinking-models-toolkit.md

关卡：3 个验证问题的答案必须全部为“是”。至少应用一种压力测试模型。

---

推理规范协议

问题：AI 往往会跳过步骤、在分析过程中分心，或对每一步都浅尝辄止。

阶段关卡（必备产物）

阶段	必须产出	最低深度
0：框定问题	≥3 条公理及其依据	每条公理：1 句话 + 说明其为何不可再简化
1：本质	问题陈述 + 成功标准	具体且可衡量
2：假设	假设表 ≥5 行	每行：质疑 + 公理引用 + 判定
3：基本事实	≥3 条基本事实	每条都必须具体、可证伪，且不是泛泛之谈
4：向上推理	包含基本事实引用的推理链	每一步都能追溯到一条基本事实
5：验证	3 个验证问题的答案 + 1 次压力测试	所有答案均为“是”

没有产物，就不能进入下一阶段。 如果未通过关卡，请暂停并完成当前阶段。

进度跟踪器（防止偏离）

在整个分析过程中维护一份持续更新的检查清单。每完成一个阶段后，输出：

## 🧭 FP Progress
- [x] Phase 0: Frame — ✅ 3 axioms
- [x] Phase 1: Essence — ✅ "..."
- [→] Phase 2: Assumptions — 3/6 checked
- [ ] Phase 3: Ground Truths
- [ ] Phase 4: Reason Upward
- [ ] Phase 5: Validate

如果对话偏离主题（用户提出旁支问题，或讨论扩展到次要话题），在回应后立即输出：

📍 返回 FP 分析：阶段 N 还剩 M 项。继续。

深度标准（防止浅尝辄止）

阶段	浅层（不合格）	深入（合格）
假设	“也许我们不需要这个”	表格中的一行，包含质疑理由 + 公理引用 + 判定
基本事实	“用户希望更快”	“根据 SLA §3.2，P99 < 200ms”
推理	“所以我们应该使用 X”	“基本事实 #2 + 基本事实 #3 → 排除 Y → X 是最小解决方案”

---

Trellis 集成

在由 Trellis 管理的项目中使用时，分析产物会与任务系统集成。

文件放置

.trellis/tasks/{MM-DD-slug}/
├── task.json              # Existing
├── prd.md                 # Existing — FP feeds into this
├── fp-analysis.md         # ← FP analysis output (Phases 0-5)
├── fp-progress.md         # ← Phase progress tracker (anti-drift)
├── implement.jsonl        # Existing — fp-analysis.md auto-added
├── check.jsonl            # Existing — fp-analysis.md auto-added
└── ...

集思广益集成

在 /trellis:brainstorm 期间，当任务被归类为“复杂”时：

1. 触发条件：用户说“从第一性原理分析”，或 AI 检测到问题存在 ≥3 个未经验证的假设
2. 执行：运行阶段 0-3，将输出保存到任务目录中的 fp-analysis.md
3. 输入 PRD：
   • 基本事实 → PRD 需求和约束
   • 假设表 → design.md 中的权衡
   • 推理链 → design.md
4. 继续：阶段 4-5 为实施决策提供参考

上下文注入

FP 分析完成后，添加到上下文文件中：

python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" implement "fp-analysis.md" "Ground truths and reasoning chain"
python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" check "fp-analysis.md" "Verify implementation traces to ground truths"

完成记录

阶段 5 之后，更新 task.json：

{
  "fp_analysis": {
    "completed": true,
    "axioms_count": 3,
    "assumptions_challenged": 6,
    "ground_truths_count": 5,
    "validation_passed": true
  }
}

---

输出格式

应用第一性原理思维时，最终输出应采用以下结构：

## First Principles Analysis: [Topic]

### Axioms
1. [Axiom 1] — [Why irreducible]
2. [Axiom 2] — [Why irreducible]
3. [Axiom 3] — [Why irreducible]

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

### Assumptions Challenged
| Assumption | Challenge | Axiom(s) | Verdict |
|------------|-----------|----------|---------|
| ... | ... | A1, A2 | Keep/Discard/Modify |

### Ground Truths
1. [Specific, falsifiable fact]
2. [Specific, falsifiable fact]
3. [Specific, falsifiable fact]

### Reasoning Chain
GT#1 + GT#3 → [Inference] → [Step] → [Conclusion]

### Conclusion
**Recommended approach:** [Description]
**Key insight:** [What FP analysis revealed that convention missed]
**Trade-offs acknowledged:** [What we accept and why]

### Validation
- [x] Every conclusion traces to a ground truth
- [x] Every ground truth is covered
- [x] No phases skipped
- [x] Stress-tested with: [model name]

---

常见陷阱

复杂性陷阱

症状：解决方案比问题本身所需的复杂得多。 FP 检查：移除一个组件——它还能解决核心问题吗？如果可以，这个组件就不是必需的。重复此过程。

类比陷阱

症状：“X 公司是这么做的，所以我们也应该这么做。” FP 检查：X 公司在解决什么问题？在所有相关维度上，我们的问题都完全相同吗？有哪些约束不同？

遗留陷阱

症状：为了兼容不再适用的决策而继续维护。 FP 检查：最初的原因是什么？那些条件现在还存在吗？改变的真实成本与维护的成本相比如何？

更多模式和案例研究：references/case-studies.md

---

互补工具速查

工具	关键问题	最适合搭配的阶段
反转思考	“什么能保证失败？”	阶段 2（找出隐藏假设）
二阶思维	“然后呢？再然后呢？”	阶段 5（压力测试结论）
5 Whys	“为什么？为什么？为什么？为什么？为什么？”	阶段 1（找出真正的问题）
事前验尸	“它失败了。为什么？”	阶段 5（压力测试）
OODA 循环	“最小化的测试是什么？”	阶段 5（采取行动）
经由否定法	“我们应该移除什么？”	阶段 4（简化解决方案）
贝叶斯更新	“什么新证据会改变这一判断？”	阶段 3（验证基本事实）
可逆性筛选	“这是单向门还是双向门？”	阶段 4（校准决策深度）

包含示例的完整工具集：references/thinking-models-toolkit.md

---

偏差意识

第一性原理分析中最危险的 5 种偏差：

偏差	对 FP 的影响	快速去偏
确认偏差	你会“发现”支持自己偏好方案的基本事实	优先寻找反驳证据
锚定效应	即使试图“从头思考”，传统做法仍会成为思维锚点	评估前先提出 3 个备选方案
沉没成本	遗留决策会被当作基本事实	“如果今天从零开始，我们还会选择这个吗？”
现状偏差	“现在的运作方式”会被当作约束，尽管它其实是一种选择	区分真正的约束与当前的选择
过度自信	未经检验就把假设当作基本事实	为每项假设标注置信度百分比

包含去偏方法的完整 12 种偏差目录：references/bias-and-debiasing.md

---

问题分解

对复杂问题应用 FP 之前，可能需要先将其分解。快速选择：

问题类型	最佳框架
诊断型（为什么会发生 X？）	问题树或鱼骨图
财务型（收入／成本）	盈利能力树
战略型（我们应该怎么做？）	假设树
运营型（哪里出了问题？）	流程图 + 5 Whys
复杂适应系统	系统图

完整的 15 种框架目录：references/decomposition-frameworks.md

---

参考文件

文件	内容	阅读时机
references/axiom-based-reasoning.md	建立公理、质疑假设和推导结论的深入方法论	需要严谨推导，而不只是分析时
references/thinking-models-toolkit.md	四象限框架 + 12 种思维模型 + 模型选择指南 + 5 Whys 深入解析	需要互补的思维工具时
references/case-studies.md	5 个软件工程案例 + 2 个 SpaceX/Tesla 案例 + 模板	想了解第一性原理实际应用的具体示例时
references/bias-and-debiasing.md	12 种会扭曲第一性原理思维的认知偏差 + 消除偏差的策略	检查分析是否存在盲点时
references/decomposition-frameworks.md	15 种问题分解方法（MECE、问题树等）	问题过于庞大，无法直接分析时