When to Use
User faces complex problem where conventional solutions fail. Existing approaches seem inadequate. Need to challenge assumptions or innovate fundamentally. Stuck in "that's how it's always done" thinking.
Quick Reference
| Topic | File |
|---|
| Decomposition techniques | INLINECODE0 |
| Common assumption traps |
assumptions.md |
Core Rules
1. The Three-Step Protocol
Step 1 — Decompose: Break the problem into fundamental components.
- - What are the absolute physical/logical constraints?
- What is actually true vs what we assume is true?
- Strip away all conventions, traditions, analogies.
Step 2 — Verify: Challenge each component.
- - "Why do we believe this?" — trace to origin
- "Is this a law of nature or a human convention?"
- "What evidence supports this being fundamental?"
Step 3 — Rebuild: Construct solution from verified fundamentals only.
- - Build up from proven truths
- Ignore "how others do it" unless proven optimal
- Each layer must connect to fundamentals
2. Identify Hidden Assumptions
Before solving, expose what's assumed:
| Assumption Type | Example | Question to Ask |
|---|
| Historical | "We've always done it this way" | "Why did it start? Does that reason still apply?" |
| Authority |
"Experts say X" | "What's the underlying evidence?" |
|
Analogical | "It's like Y, so..." | "Are the underlying mechanics actually similar?" |
|
Social | "Everyone does it" | "Does popularity equal optimality?" |
|
Resource | "We can't afford to..." | "What if resources weren't the constraint?" |
3. The Constraint Test
For each constraint ask:
- 1. Is this a law of physics? → Respect it
- Is this a logical necessity? → Respect it
- Is this a regulation/rule? → Can be changed (with effort)
- Is this a convention? → Can be ignored
- Is this an assumption? → Must be verified
4. When NOT to Use First Principles
First principles is expensive. Use analogical reasoning when:
- - Problem is well-understood with proven solutions
- Time pressure doesn't allow deep analysis
- Marginal improvement is sufficient
- Domain is stable with little innovation potential
Rule: First principles for novel problems or when conventional fails. Analogy for routine optimization.
5. Socratic Decomposition
Use recursive "why" questioning:
CODEBLOCK0
Continue until you hit physics, logic, or math — things that cannot be argued.
6. The Blank Slate Test
Imagine the problem exists but NO solutions have been tried:
- - "If we were starting from scratch today, with current knowledge and technology, how would we solve this?"
- This bypasses legacy thinking and sunk cost fallacy.
7. Output Format
When applying first principles, structure response as:
CODEBLOCK1
Common Traps
- - Stopping too early → "Materials are expensive" isn't fundamental; "atoms have mass" is. Keep going.
- Confusing difficulty with impossibility → "It's hard" ≠ "It's against physics"
- Rejecting all analogy → Analogies are useful heuristics; first principles is for when they fail
- Analysis paralysis → Set time limits; perfect decomposition isn't the goal, better thinking is
- Ignoring implementation → A fundamental solution that can't be built is useless; constraints matter
- Lone wolf thinking → First principles benefits from multiple perspectives challenging assumptions
Domain Applications
| Domain | First Principles Question |
|---|
| Business | What does the customer fundamentally need (not want)? |
| Engineering |
What do physics and materials actually allow? |
|
Product | What job is being done at the most basic level? |
|
Cost | What are the raw inputs and minimum required labor? |
|
Process | What steps are logically necessary vs historically accumulated? |
Security & Privacy
Data that stays local:
- - All reasoning happens in conversation context
- No data stored or transmitted
This skill does NOT:
- - Store any information between sessions
- Make network requests
- Access external files
Related Skills
Install with
clawhub install <slug> if user confirms:
- -
decide — auto-learn decision patterns - INLINECODE4 — validate and refine strategy
- INLINECODE5 — executive decision-making
- INLINECODE6 — build from zero to PMF
Feedback
- - If useful: INLINECODE7
- Stay updated: INLINECODE8
技能名称:第一性原理思维
使用时机
用户面临传统解决方案失效的复杂问题。现有方法似乎不够充分。需要挑战假设或进行根本性创新。陷入一直是这样做的思维定式。
快速参考
| 主题 | 文件 |
|---|
| 分解技巧 | decomposition.md |
| 常见假设陷阱 |
assumptions.md |
核心规则
1. 三步法
第一步 — 分解: 将问题分解为基本组成部分。
- - 绝对物理/逻辑约束是什么?
- 什么是真实情况,什么是我们假设为真的?
- 剥离所有惯例、传统和类比。
第二步 — 验证: 挑战每个组成部分。
- - 我们为什么相信这一点?——追溯其根源
- 这是自然法则还是人为惯例?
- 有什么证据支持这是基本要素?
第三步 — 重建: 仅从经过验证的基本要素构建解决方案。
- - 从经过验证的真理出发
- 忽略别人怎么做,除非被证明是最优的
- 每一层都必须与基本要素相连
2. 识别隐藏假设
在解决问题之前,揭示被假设的内容:
| 假设类型 | 示例 | 要问的问题 |
|---|
| 历史性 | 我们一直这样做 | 为什么开始这样做?那个原因现在还适用吗? |
| 权威性 |
专家说X | 背后的证据是什么? |
|
类比性 | 这就像Y,所以…… | 底层机制真的相似吗? |
|
社会性 | 每个人都这样做 | 流行等于最优吗? |
|
资源性 | 我们负担不起…… | 如果资源不是约束条件呢? |
3. 约束条件测试
对每个约束条件提问:
- 1. 这是物理定律吗?→ 尊重它
- 这是逻辑必然性吗?→ 尊重它
- 这是法规/规则吗?→ 可以改变(需要努力)
- 这是惯例吗?→ 可以忽略
- 这是假设吗?→ 必须验证
4. 何时不使用第一性原理
第一性原理成本高昂。在以下情况下使用类比推理:
- - 问题已被充分理解且有经过验证的解决方案
- 时间压力不允许深入分析
- 边际改进就足够了
- 领域稳定,创新潜力小
规则: 对于新颖问题或传统方法失效时使用第一性原理。对于常规优化使用类比。
5. 苏格拉底式分解
使用递归式为什么提问:
问题:电动汽车太贵
为什么贵?→ 电池成本高
为什么电池贵?→ 材料 + 制造
为什么材料贵?→ 钴、锂的价格
为什么需要这些材料?→ 当前化学体系要求它们
这是根本性的吗?→ 不,化学可以改变
根本:需要能量存储。而非:需要钴电池。
持续追问,直到触及物理、逻辑或数学——这些无法争辩的东西。
6. 空白画布测试
假设问题存在,但从未尝试过任何解决方案:
- - 如果今天我们从零开始,利用现有的知识和技术,我们会如何解决这个问题?
- 这能绕过传统思维和沉没成本谬误。
7. 输出格式
应用第一性原理时,按以下结构组织回应:
问题陈述
[清晰定义我们要解决的问题]
假设的约束条件(待验证)
- - 约束条件A — [来源:历史性/权威性等]
- 约束条件B — [来源]
基本真理
分解
[分解为各个组成部分]
重建的解决方案
[仅从基本要素构建的解决方案]
被挑战的假设
常见陷阱
- - 过早停止 → 材料很贵不是根本性的;原子有质量才是。继续深挖。
- 混淆困难与不可能 → 这很难≠这违反物理定律
- 拒绝所有类比 → 类比是有用的启发式方法;第一性原理在类比失效时使用
- 分析瘫痪 → 设定时间限制;完美的分解不是目标,更好的思考才是
- 忽视实施 → 无法构建的根本性解决方案毫无用处;约束条件很重要
- 孤狼思维 → 第一性原理需要多角度挑战假设才能获益
领域应用
| 领域 | 第一性原理问题 |
|---|
| 商业 | 客户根本需要(而非想要)什么? |
| 工程 |
物理和材料实际上允许什么? |
|
产品 | 在最基本的层面上,完成的是什么工作? |
|
成本 | 原始投入和最低必要劳动是什么? |
|
流程 | 哪些步骤是逻辑上必要的,哪些是历史积累的? |
安全与隐私
本地保留的数据:
- - 所有推理都在对话上下文中进行
- 不存储或传输任何数据
此技能不会:
- - 在会话之间存储任何信息
- 发起网络请求
- 访问外部文件
相关技能
如果用户确认,使用 clawhub install
安装:
- - decide — 自动学习决策模式
- business — 验证和优化策略
- ceo — 高管决策
- startup — 从零到产品市场匹配
反馈
- - 如果有用:clawhub star first-principles-thinking
- 保持更新:clawhub sync