用 AI Debug 的正确流程：喂什么信息、怎么描述现象、什么时候别问

同样一个 bug，有人问 AI 三轮解决，有人问十轮越问越乱。差别不在模型，在喂进去的信息。

一、喂什么：一份信息清单

我固定按这五样给，缺一样就补上再问：

  1. 完整报错堆栈。从第一行到最后一行，别只截最后一句，前面往往才是根因。
  2. 最小可复现的代码。把问题从项目里摘出来，写成能独立跑的小例子。这一步看着麻烦，但它本身就能解决一半问题——做最小复现的过程中，bug 经常自己就现形了。
  3. 你希望它做什么，实际发生了什么。这两句一定要分开写清楚。
  4. 已经试过的方案。“我试过重启、清缓存、重装依赖，都没用"比"我试了很多办法"有用得多。
  5. 环境信息。语言版本、框架版本、操作系统、依赖版本号。

二、怎么描述现象

一个好用的模板：

预期：[一句话，正常情况应该发生什么]
实际：[一句话，实际发生了什么]
复现率：[必现 / 十次里大概三次 / 只在某个条件下出现]
报错原文：[完整粘贴]
最近改动：[出问题前你改了什么]
环境：[版本信息]
已尝试：[1. xxx，结果 yyy  2. xxx，结果 yyy]

对比一下两种问法：

  • 差的：“我的代码报错了，怎么办”
  • 好的：“点保存按钮应该写入数据库并返回成功提示，实际返回 500，日志报 NullPointerException 在 UserService.java 第 42 行。必现。昨天把 User 类的 address 字段改成可选之后开始出现的。JDK 17 + Spring Boot 3.2。我试过重启和清缓存，都没用。”

第二种问法，AI 第一轮就能猜到大概是空字段没判空。第一种要来回五轮才能问出这些前提。

三个描述习惯：

  1. 说复现率。必现和偶现是两个完全不同的排查方向。
  2. 说最近改了什么。绝大多数 bug 都是最近一次改动引入的，这条信息价值最高。
  3. 贴原文，不要转述。转述时会不自觉加上自己的判断，可能把它带偏。

三、效率对比：什么时候比搜索快

比传统搜索快很多的情况：

  1. 报错信息很长。一屏装不下的堆栈，搜索很难命中，AI 能直接读。
  2. 跨技术栈的问题。报错在 A 层、原因在 B 层，靠关键词基本搜不到。
  3. 你不知道该搜什么关键词。知道关键词的话搜索更快，不知道的话 AI 更合适。
  4. 配置类问题。把配置文件贴进去让它找错，比对着文档一条条比对快。

体感上，传统方式要十几分钟到半小时的定位，用 AI 通常几轮对话就能收敛，前提是信息给全了。

差不多或者更慢的情况：很常见的错误，搜一下第一条就是答案；版本很新的库，它的训练数据可能没覆盖，会编 API；需要看运行时数据的问题（内存泄漏、性能瓶颈、并发），得看 profile。

四、什么时候别问它

第一类：它拿不到必要信息的情况。

  • 环境配置、网络、权限问题。这类问题高度依赖你的具体机器，它只能给通用排查清单。
  • 需要运行时数据才能判断的问题。你没给日志、没给监控数据，它只能猜。
  • 刚发布几天的库的 bug。它会一本正经地编一个不存在的 API。

第二类：你判断不了它对不对的情况。

这条更重要。如果你对某个领域完全不了解，它给的答案你没法验证，那你其实是在赌博。这种情况下，先去补一点基础，至少能看出它是不是在胡说。

五、两条止损规则

  1. 两轮没进展就换方法。如果问了两轮还在原地打转，说明信息不足或者它在瞎猜。停下来，回到最小复现、加日志、二分法注释代码这些传统手段。
  2. 它改的代码一定要自己跑一遍。不要因为它说"改这个就好"就直接提交。跑测试，或者手动验证，验证不了就别信。

六、我的实际流程

  1. 先把报错完整读一遍，自己先猜一个方向。
  2. 做最小复现，八成问题在这一步就定位了。
  3. 定位不到，按上面的模板组织信息问 AI。
  4. 拿到答案先验证再采纳，验证不了就打回继续问，或者自己上调试器。
  5. 解决了之后，让它总结一句根因，记到自己的笔记里。这类笔记攒多了，你会发现重复踩的坑就那几个。
返回AI编程