first-principles-thinkinglisted

## 何时使用 - 现有方案沿用类比、惯例或「业界都这么做」，但需要质疑其是否成立时。 - 面对复杂或陌生问题，缺乏现成模板，需自行拆解并重建推导链时。 - 多个方案陷入路径依赖或局部最优，需要回到约束本身重新设计时。 - 触发词：第一性原理、从头推导、本质、拆解假设。 **不该用**： - 问题已有可靠成熟解、只需直接执行时（直接做，不要过度拆解）。 - 时间/信息严重不足、需快速决策时（用类比或经验更划算）。 - 争议焦点是「事实是否为真」而非「推导是否成立」时（改用 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 已超标 → 根因是串行调用次数，而非单次速度 → 合并/并行化查询即可达标，缓存非必需。 对比：原「加缓存」方案绕过了真正约束（调用次数）。 ``` ## 注意事项 - 拆解有成本：只对高价值、高不确定性的问题用，不要事事从头推导。 - 警惕「伪地基」：把惯例或行业标准误当成不可违反约束，是最常见错误。 -