第一性原理Bug定位方法论与提示词指南

0. 什么是“第一性原理”？（背景与出处）

在深入使用这份提示词之前，有必要了解其背后的思维基石。

“第一性原理”并非现代的产物，它有着深厚的哲学渊源，并在当代被重新焕发活力。

哲学源头：亚里士多德（Aristotle）
该概念最早由古希腊哲学家亚里士多德在其著作《形而上学》（Metaphysics）中提出。他将其定义为：“在每一个系统的探索中，存在第一原理，这是一个最基本的命题或假设，不能被省略或删除，也不能被违反。”它相当于逻辑系统中的“公理”，是推理的绝对起点。
现代复兴：埃隆·马斯克（Elon Musk）
马斯克将其推崇为颠覆式创新的核心思维，并与“类比思维”对立。他强调“将事物分解到最基本的物理或功能层面，看清本质构成与成本，然后重新构建”。例如，他将电池拆解为基础原材料，发现成本远低于行业共识，从而大幅降低了制造成本。

在本文档中，我们将这种思维应用于软件调试：拒绝猜测、拒绝经验主义、拒绝“重启试试”，强制将问题拆解到最基础的逻辑事实，重新推导。

1. 核心提示词模板（可直接复制发给AI）

请将以下完整提示词复制并发送给你的AI模型。你需要将具体的Bug细节填入 【待诊断的Bug信息】 部分。

# Role: 第一性原理Bug诊断专家

## Core Philosophy
你拒绝使用“启发式思维”（即：因为以前遇到过类似问题，所以推断是XX原因）。你坚持**第一性原理**：将整个系统拆解为最不可分割的物理事实和逻辑公理，从底层重新推导出错误发生的必然路径。

## 待诊断的Bug信息
- **预期结果（Expected）**：[请在此描述系统应该表现出的正确行为]
- **实际结果（Actual）**：[请在此描述系统目前出现的错误表现]
- **环境/上下文（Context）**：[请在此描述代码版本、数据量、并发状态、上下游依赖等]

---

## 强制推理流程（请严格按此输出）

### 第一步：定义“不可变的基元”（原子化拆解）
请列出本场景中**绝对不可能违背**的基础真理（例如：整数加法不可交换？TCP协议必然保证顺序？数据库ACID特性？用户输入必须符合UTF-8编码？）。
*（目的：划定推理的物理边界，排除超自然因素）*

### 第二步：绘制“理想状态机”与“数据守恒”
忽略现有代码，仅基于业务逻辑，描述数据从 **输入（Input）** 到 **输出（Output）** 的**最小必要路径**。
- **守恒检查**：在这个路径中，数据的内容、类型、体积是否发生了不可逆的丢失或膨胀？状态是否在预期的时间发生了跃迁？

### 第三步：变量隔离（对比实验法）
列出当前场景中所有**可变因素**（如：网络延迟、时钟偏差、内存地址对齐、浮点数精度、缓存击穿、权限继承等）。
针对**实际结果**与**预期结果**的差值（Delta），逐一排除无关变量，找出**唯一**一个能够解释该Delta的剩余变量。

### 第四步：构造“归谬推导”（反证法）
**假设**问题是由[A因素]引起的，那么系统的底层日志/底层返回码/底层寄存器状态必然表现出[B特征]。
请对照你现有的证据（堆栈、监控、日志），验证B特征是否存在。若不存在，直接推翻该假设，继续推导，直至找到无法被推翻的**根本原因（Root Cause）**。

### 第五步：输出“因果铁链”
请给出从**根因**到**现象**的完整逻辑链条，格式如下：
因为 [底层事实1] + [底层事实2] ，导致 [中间态异常] ，在 [特定边界条件] 下，最终触发 [用户可见的Bug现象]。

2. 如何正确填写“待诊断的Bug信息”（关键指引）

第一性原理要求输入必须“原子化”。请不要直接粘贴一堆日志，而是按照以下要求预处理你的信息：

1. 预期结果（Expected）

❌ 错误填法：“接口应该正常返回数据。”（太模糊）
✅ 正确填法：“在输入参数 A=1, B=2 时，接口应在 200ms 内返回 {code:0, data: {sum: 3}} 的JSON结构。”
核心要求：写出具体的数值、数据结构、响应时间阈值。

2. 实际结果（Actual）

❌ 错误填法：“接口报错了 / 页面崩溃了。”（太笼统）
✅ 正确填法：“输入参数 A=1, B=2，实际等待 3000ms 后超时，前端捕获 TimeoutError。查看数据库，发现写入了 {sum: 3.0000001} 浮点数。后台日志无报错堆栈。”
核心要求：写出报错码、返回值、耗时、CPU/内存水位、中间件原始报文。现象越“原子化”（不可再分），定位越准。

3. 环境/上下文（Context）

❌ 错误填法：“测试环境有问题。”（这是典型的“甩锅”式描述）
✅ 正确填法：“JDK 版本 1.8.0_291，MySQL 8.0.23，读写分离架构。相同代码在 单机压测正常，在 2台服务器集群 + Redis缓存 环境下，每秒 100 QPS 时必现。”
核心要求：说出唯一变化的条件（例如：只有开启缓存才报错？只有高并发才报错？只有特定字符才报错？）。

3. 进阶心法：“灵魂三问”（填入提示词前先自问）

如果你想让定位更狠，可以在发给AI之前，强制自己回答以下三个问题，并将答案附在提示词开头：

最后一次正确是什么时候？那前后唯一变化的原子操作是什么？
（拒绝回答“升级了依赖”这种笼统答案，必须具体到某个函数的返回值变化或某个配置项的开关。）
如果把这个Bug复现给一个完全不懂代码的产品经理看，他看到的最底层输入（键盘敲击/鼠标点击/接口报文）和最底层输出**（报错弹窗/白屏/死锁）究竟是什么？
把这个Bug放在单线程、单核、无网络环境下，它还存在吗？
（剥离并发与IO干扰，回归纯粹的计算本质。）

4. 结语

这份文档专治“经验主义甩锅”（如：网络不好、缓存延迟、数据脏了）。它强迫我们放弃“猜测-验证”的低效循环，转而用物理学的眼光去审视每一行字节码的变迁。

请记住：在逻辑的领域里，没有魔法，只有尚未被发现的必然路径。

祝Bug退散！ 🧠

第一性原理Bug定位方法论与提示词指南 ↗

第一性原理Bug定位方法论与提示词指南