一个 Claude Code skill，强制要求在推理之前先将问题分解到最基本的事实——而不是依赖类比、惯例或"别人怎么做"。
当你面对任何分析、设计、调试或决策任务时，这个 skill 会强制执行四步结构化流程：
- 识别假设 — 列出所有你正在依赖的假设
- 追问"为什么"（至少 3 层） — 从根本上挑战每一个假设
- 还原基本事实 — 剥离所有假设后，剩下什么是确定的？
- 从零重建 — 从这些事实出发推导最优解，而不是从历史经验出发
在以下情况下调用此 skill：
- 分析问题或 bug
- 做架构或设计决策
- 向他人解释概念
- 调试异常行为
- 评估技术选型
将 SKILL.md 复制到项目的 .claude/skills/first-principles-thinking/ 目录：
mkdir -p .claude/skills/first-principles-thinking
cp SKILL.md .claude/skills/first-principles-thinking/或全局安装（所有项目均可使用）：
mkdir -p ~/.claude/skills/first-principles-thinking
cp SKILL.md ~/.claude/skills/first-principles-thinking/在 Claude Code 中通过 Skill 工具调用：
/first-principles-thinking
或在 CLAUDE.md 中引用：
在任何技术分析或设计决策之前，调用 first-principles-thinking skill。| 思维模式 | 为什么有害 | 替换方式 |
|---|---|---|
| "业界通常这样做" | 惯例可能已过时或针对不同约束 | 确认该约束在你的场景中是否存在 |
| "上次我们用 X 解决了" | 情境不同，方案不可直接复用 | 重新分析当前约束 |
| "参考 Y 框架的做法" | 框架有自己的约束，不一定适合你 | 识别框架解决的核心问题 |
| "这个领域专家都说应该" | 专家建议基于其自身约束 | 理解建议背后的前提条件 |
| "先做再说，遇到问题再调整" | 从错误方向出发，调整成本指数增长 | 先定义问题边界，再动手 |
出现以下任何一种想法，说明你在走捷径：
- "这明显就是 X 类问题，所以..."
- "照着 [某产品/某论文/某框架] 做就行了"
- "这个领域我熟，不需要从基础推"
- "时间紧，直接用常规方案"
时间压力不是跳过分析的理由。 在错误方向上的快速执行比慢速推导浪费更多时间。
问题是什么？（不是"表面现象"，是根本矛盾）
↓
有哪些约束？（物理的/逻辑的/资源的）
↓
如果约束不存在，理想解是什么？
↓
哪些约束是真实的，哪些是"我们一直这样做"？
↓
在真实约束下，最接近理想解的方案是什么？
MIT