First principles thinking

何时使用

• 现有方案沿用类比、惯例或「业界都这么做」，但需要质疑其是否成立时。
• 面对复杂或陌生问题，缺乏现成模板，需自行拆解并重建推导链时。
• 多个方案陷入路径依赖或局部最优，需要回到约束本身重新设计时。
• 触发词：第一性原理、从头推导、本质、拆解假设。

不该用：

• 问题已有可靠成熟解、只需直接执行时（直接做，不要过度拆解）。
• 时间/信息严重不足、需快速决策时（用类比或经验更划算）。
• 争议焦点是「事实是否为真」而非「推导是否成立」时（改用 fact-checking 核验事实）。

步骤 / 指令

1. 明确目标
   - 用一句话写出要解决的问题和成功判据（可度量）。

2. 列出当前方案的所有假设
   - 逐条写下「之所以这样做，是因为我假设 ___」。
   - 标注每条假设的来源类型：[事实] / [惯例] / [类比] / [推测]。

3. 拆到基本事实（地基）
   - 对每条假设追问「这一定为真吗？凭什么？」直到只剩：
     a) 物理/数学/逻辑约束（不可违反）；
     b) 已验证的硬事实（数据、规格、合同条款）。
   - [惯例][类比][推测] 类假设一律标记为「可挑战」，不得作为地基。
   - 关键硬事实存疑时，调用 fact-checking 核实后再纳入地基。

4. 从地基重新推导
   - 只用第 3 步的基本事实，重建解决方案，不引用任何原方案的结构。
   - 推导每一步注明依赖了哪条地基事实。

5. 对照与取舍
   - 将新推导方案与原方案并列，标出差异点及各自被放宽的假设。
   - 给出推荐方案 + 触发回退的条件。

6. 验证地基有效性
   - 若任一地基事实被推翻，回到第 3 步重做。

执行约束：

• 区分「不可违反约束」与「当前选择」——前者是地基，后者可挑战。
• 禁止在推导中偷偷引入原方案的隐含结构（如沿用其数据模型、流程顺序）。
• 每条结论必须可追溯到某条基本事实，否则标记为「未证成」。

示例

最小提示词模板：

对【目标：X】做第一性原理分析：
1) 列出现方案的全部假设，逐条标注 [事实/惯例/类比/推测]；
2) 把每条追问到不可再分的物理/逻辑约束或硬事实，得到「地基清单」；
3) 仅用地基清单重新推导方案，每步注明依赖的地基项；
4) 与原方案对比差异，给推荐方案和回退条件。
对存疑的硬事实，先核实再使用。

拆解示例（目标：降低服务响应延迟）：

假设清单：
- [惯例] 必须用现有的三层架构        → 可挑战
- [类比] 别家加缓存就快了，我们也加  → 可挑战
- [事实] 单次 DB 查询 P99 = 80ms     → 地基
- [事实] SLA 要求 P99 < 120ms        → 地基
- [推测] 瓶颈在数据库                → 需先用埋点核实，否则不作地基

地基清单：DB 查询 80ms；SLA 120ms；请求串行执行 4 次 DB（实测）。
重新推导：4×80=320ms 已超标 → 根因是串行调用次数，而非单次速度
         → 合并/并行化查询即可达标，缓存非必需。
对比：原「加缓存」方案绕过了真正约束（调用次数）。

注意事项

• 拆解有成本：只对高价值、高不确定性的问题用，不要事事从头推导。
• 警惕「伪地基」：把惯例或行业标准误当成不可违反约束，是最常见错误。
• 地基依赖事实质量：错误的「硬事实」会污染整条推导链，存疑即核验。
• 第一性原理负责「推导是否成立」，不替代「事实是否为真」——二者分工。
• 重建方案需经实证检验，逻辑自洽不等于现实可行。

互见

• requires：无。
• related：fact-checking（拆解出的硬事实存疑时，先核验再作为地基）。
• combines_with：无。