findscripter 何时使用
- 现有方案沿用类比、惯例或「业界都这么做」，但需要质疑其是否成立时。
- 面对复杂或陌生问题，缺乏现成模板，需自行拆解并重建推导链时。
- 多个方案陷入路径依赖或局部最优，需要回到约束本身重新设计时。
- 触发词：第一性原理、从头推导、本质、拆解假设。
不该用：
- 问题已有可靠成熟解、只需直接执行时（直接做，不要过度拆解）。
- 时间/信息严重不足、需快速决策时（用类比或经验更划算）。
- 争议焦点是「事实是否为真」而非「推导是否成立」时（改用 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：无。