第一性原理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退散! 🧠