摘要

很多程序员都在用 AI 帮忙排查问题，但效果差异非常大。有人觉得 AI 很强，能快速帮自己收敛方向；也有人觉得 AI 只会一本正经地胡说八道。实际用下来，我越来越觉得，问题很多时候不在模型本身，而在于提问方式。这篇文章结合我自己在排查日志、分析代码、看 SQL、定位异常时的实际使用经验，总结了一套更容易问出有效结果的提问模板，也会聊聊哪些问题适合交给 AI，哪些问题不能全信 AI。

前言

这两年，很多程序员都开始在开发里用 AI 了。

我自己也是。

最开始用的时候，我的想法其实很简单：

不就是把报错、日志、代码扔给 AI，让它帮我分析一下吗？

结果用了一段时间以后，我发现事情根本没这么简单。

过去排查问题时，我更多是自己翻日志、看代码、拆 SQL。现在 AI 已经慢慢变成我开发流程里的

一个辅助工具，尤其是在第一轮问题收敛和线索整理上，确实能明显提高效率。

有时候 AI 确实很好用，能一下帮我把方向收回来；

但有时候，它也会一本正经地说一大堆看起来很有道理、实际上没太大帮助的话。

我后来慢慢发现，问题很多时候不在模型，而在我自己怎么问。

比如我一开始最常见的几种问法就是：

• 帮我看下这个报错

• 这段代码为什么有问题

• 这个 SQL 对不对

• 为什么事务没生效

这些问题也不是完全不能答，

但 AI 给出来的内容，经常会比较泛，像是在“陪你聊天”，而不是“真的帮你排查”。

后来我慢慢开始调整提问方式：

先补背景，再说现象，再说预期，再给关键线索，最后明确我到底想让它帮我做什么。

调整之后，效果差别非常明显。

这里说的 AI 工具，不特指某一个产品。无论你用的是 ChatGPT、Claude、Cursor、DeepSeek，还是其他支持代码与文本分析的工具，这套提问思路基本都适用。真正影响效果的，很多时候不是工具名字，而是你是否把问题描述清楚了。

所以这篇文章，我不想空聊“AI 很强”或者“AI 能提效”，

而是想把我现在比较常用的一套提问思路整理出来。

核心目标就一个：

让 AI 从“泛泛回答”变成“真正帮你干活”。

一、为什么很多人用 AI 排查问题效果不好

先说结论（个人观点）：

很多无效回答，不是因为模型太差，而是因为问题问得太模糊。

对我来说，AI 最有价值的地方，不是直接替我给答案，而是帮我更快进入“有效排查”的状态。前提是，我得先把问题问对。

1）只丢现象，不给上下文

比如一句：

帮我看下这个报错。

或者：

这段代码有问题吗？

从人的角度看，这句话当然算提问。

但从 AI 的角度看，信息其实远远不够。

它不知道：

• 这是在什么项目里

• 这是在什么业务场景下

• 你预期它本来应该怎么运行

• 你已经查到了什么

• 你最想让它帮你做什么

于是它只能给你一堆“大概率没错，但也不够贴身”的回答。

这种回答不能说完全没用，

但距离真正帮你排查问题，还差得很远。

2）一次塞太多信息，但没有结构

另一种常见问题是：

信息很多，但没有层次。

比如把：

• 一大段日志

• 一大段代码

• 一段 SQL

• 一句“帮我看看”

全塞进去。

这种看起来比“只问一句”强很多，

但如果没有结构，AI 也很容易抓不住重点。

最后就会变成：

• 它挑了一个不重要的点展开

• 没抓到真正的问题主线

• 回复很长，但帮助不大

我自己也踩过这个坑。

一开始总觉得“给得越多越好”，后来才发现：

不是信息越多越好，而是信息要有组织。

3）问题目标不明确

这一点也非常常见。

很多时候我们自己心里真正想要的是：

• 帮我先缩小排查范围

• 帮我判断最可疑的点

• 帮我看这段 SQL 哪一步最可能有问题

• 帮我把日志和代码链路串起来

但真正问出来却是：

帮我看一下这个问题。

结果 AI 只能做一个很宽泛的“分析师”，

而不是你真正想要的那个“排查助手”。

二、我现在更常用的一套提问结构

我现在让 AI 帮我排查问题时，通常会尽量把问题整理成下面这 6 个部分。

这套结构不是唯一答案，

但至少在我自己日常使用里，已经比“随手一问”稳定很多了。

1）背景

先说清楚这是个什么场景。

比如：

• 这是一个 Spring Boot 项目

• 这是批量任务

• 这是事务方法

• 这是 MyBatis Plus 更新逻辑

• 这是一个环境配置问题

背景的作用不是讲故事，

而是让 AI 知道：

它现在看到的，不是一段孤立代码，而是一段有上下文的内容。

2）现象

把你看到的异常、结果、反常表现写清楚。

比如：

• 报了什么错

• 哪一步表现不符合预期

• 是没回滚，还是漏数据，还是查不到结果

• 是全部失败，还是部分失败

这一步我现在会尽量写得客观一点，

少用“我感觉”，多用“我看到”。

因为“现象”写得越清楚，

AI 越容易知道你到底在说什么。

3）预期结果

这一点很多人会漏掉，但其实特别重要。

你得告诉 AI：

正常情况下，我希望它发生什么。

比如：

• 我预期事务应该整体回滚

• 我预期这批数据应该全部更新成功

• 我预期查询结果应该只有一条

• 我预期这个接口应该返回结构化对象

没有“预期结果”，

AI 很难准确判断“现象为什么不对”。

4）已知线索

这一步特别有用。

你可以把你已经确认的信息告诉它，比如：

• 这个方法加了 @Transactional

• 这个调用是同类内部调用

• 我查到数据库里主表有数据，明细表没有

• 我已经确认这个 SQL 在数据库里能单独执行

• 我怀疑问题在后置逻辑

这一步的价值在于：

避免 AI 从头开始乱猜，而是站在你已经排查过一轮的基础上继续往前推。

5）关键材料

这里放真正的“证据”。

通常包括：

• 日志

• 代码片段

• SQL

• 配置文件

• 表结构片段

• 接口定义

这部分不一定要很多，但要尽量“够用”。

我自己现在更倾向于：

放关键片段，而不是把整个文件一股脑扔进去。

因为完整文件一丢，

很多时候不但没帮到 AI，反而会让重点更模糊。

6）明确你要 AI 帮你做什么

这是最关键的一步。

你要直接告诉它，你现在需要它扮演什么角色。

比如：

• 帮我缩小排查范围

• 帮我判断最可能的 3 个原因

• 帮我从日志反推 SQL 查询路径

• 帮我分析这段代码里事务为什么可能失效

• 帮我给出一个更稳的实现方案

这一点一定要明确。

因为你不说，它就只能默认自己是“万能问答机”；

而你真正想要的，往往不是一个“回答机器”，而是一个“排查助手”。

三、我现在常用的提问模板

下面这几套模板，是我现在自己用得比较多的。

不是说你必须一字不改照抄，但至少可以当一个比较稳的起点。

模板 1：问题排查通用版

这是我平时最常用的一版，

适合大多数“线上问题 / 排查类问题”。

我在排查一个 [问题类型]，项目背景是：[项目/技术栈/场景]。

目前现象是：
1. [现象1]
2. [现象2]
3. [现象3]

我预期的结果是：
[预期结果]

目前我已经确认的线索有：
1. [线索1]
2. [线索2]
3. [线索3]

下面是相关材料：
1. 日志：
[日志片段]

2. 代码：
[代码片段]

3. SQL / 配置（如有）：
[SQL或配置]

请你不要泛泛分析，重点帮我做这几件事：
1. 先帮我缩小最可能的排查范围
2. 判断最可疑的 2~3 个点
3. 如果有必要，给出下一步建议我查什么

模板 2：日志分析版

如果你现在手里最明确的材料就是日志，

那就别急着把所有代码都贴上去，先从日志切入更容易收敛。

下面是一段异常日志，背景是：[业务背景/项目场景]。

现象是：
[现象描述]

我预期是：
[预期结果]

目前我最想让你帮我做的是：
1. 从日志里提取关键线索
2. 判断问题更像发生在什么阶段
3. 给出下一步排查建议

日志如下：
[日志内容]

模板 3：代码分析版

这类模板特别适合“我怀疑代码有问题，但暂时还不确定具体点在哪”的场景。

下面是一段 [Java/Spring/MyBatis Plus] 代码，场景是：[场景说明]。

当前问题现象是：
[现象]

我预期是：
[预期]

请你结合代码，不要只做语法层分析，重点帮我判断：
1. 这段代码最可能的问题点在哪
2. 有没有事务/并发/调用链方面的风险
3. 如果这是线上问题，应该优先查哪里

代码如下：
[代码片段]

模板 4：SQL 排查版

这个模板我在看 SQL 问题时也挺常用。

下面这段 SQL 用在 [报表/统计/更新/查询] 场景。

当前现象是：
[现象]

我预期结果是：
[预期]

我已经确认：
1. [已知线索1]
2. [已知线索2]

请你重点帮我：
1. 判断 SQL 最可能的问题点
2. 看看是否有逻辑边界或条件遗漏
3. 如果要进一步验证，建议我先查什么

SQL 如下：
[SQL内容]

四、错误问法 vs 更有效的问法

这一部分特别重要。

很多时候，差距真的不在模型，而在问法。

错误问法 1

帮我看下这个报错。

问题在于：

• 没背景

• 没现象

• 没预期

• 没目标

AI 只能泛泛而谈。

更有效的问法 1

这是一个 Spring Boot 批量任务。现象是部分数据已经写入，但明细表没有数据。我预期是整批成功或整批失败。下面是相关日志和代码，请你帮我先判断问题更像出在事务、线程收集，还是后置逻辑阶段。

这个问法一出来，

AI 的回答通常会明显更聚焦。

错误问法 2

这个 SQL 有问题吗？

问题在于：

• “有问题吗”太宽了

• 它不知道你说的是性能问题、逻辑问题、结果问题，还是兼容性问题

更有效的问法 2

这段 SQL 用在某某业务中，现象是数量比预期少。我已经确认源表数据存在。请你重点帮我判断这段 SQL 是否有 join 条件过严、过滤条件遗漏，或者 group by 口径不一致的问题。

这样 AI 就知道你想让它重点看什么。

错误问法 3

这个事务为什么不生效？

更有效的问法 3

这是一个 Spring Boot 事务方法，方法上加了 @Transactional，但异常后数据库数据没有回滚。当前代码是同类内部调用，同时方法里有 try-catch。请你结合这两个点，帮我判断事务最可能为什么没生效，以及我下一步该优先查调用链还是异常处理。

这个版本就明显更接近“真实排查”。

五、哪些问题适合交给 AI，哪些问题不能全信 AI

这是我现在很在意的一点。

因为很多人一开始会把 AI 想成“万能助手”，

但用久了就会发现，它更像一个：

擅长加速思考，但不适合直接替你拍板的工具。

更适合让 AI 帮忙的场景

1）帮你快速梳理问题结构

比如：

• 从日志里提取主线

• 从代码里找潜在风险点

• 帮你列出最可能的几个排查方向

2）帮你做“第一轮收敛”

比如：

• 事务问题更像哪一类

• SQL 先看 join 还是先看 where

• 并发问题先查线程收集还是查状态更新

3）帮你解释陌生代码或陌生报错

尤其是刚接触的模块、框架、开源组件，

这种场景 AI 很适合当“加速器”。

不适合完全相信 AI 的场景

1）复杂业务规则判断

AI 很容易把“技术合理”当成“业务正确”。

2）SQL 统计口径判断

尤其是多表统计、边界规则、历史兼容这种，

AI 经常看起来懂，实际上不一定真懂。

3）最终根因确认

AI 可以帮你缩小范围，

但最终是不是根因，还是得你自己结合日志、数据、代码去验证。

我现在对 AI 的定位更像这样：

它适合帮我加速思考，不适合替我拍板。

六、我自己总结的 5 条使用原则

1）先描述问题，再贴材料

不要一上来就扔一坨代码或日志。

2）一定要说清楚预期结果

否则 AI 很难判断哪里不对。

3）明确让它帮你做什么

让它“缩小范围”，比让它“解决一切”更有效。

4）关键材料够用就行，不要全扔

重点是结构，不是信息量比赛。

5）最终答案一定自己验证

AI 给你的结论，最多只能算“高质量参考”，不能直接当真相。

七、一个我自己真实感受很强的结论

我现在越来越觉得：

AI 排查问题的效果，很大程度上取决于你会不会提问。

很多时候不是 AI 不行，

而是我们问得太像“随口一问”，不像“真实排查”。

如果你只是说一句：

帮我看看这个 bug。

那它给你的，大概率也只能是一个“差不多”的答案。

但如果你能把：

• 背景

• 现象

• 预期

• 已知线索

• 关键材料

• 想让它帮你做的事

整理清楚，AI 的实用价值会明显提高。

对我来说，AI 现在最有价值的地方不是“替我解决问题”，而是：

帮我更快地收敛方向、整理线索、提高排查效率。

AI 现在并没有替代排查问题本身，但它确实已经开始改变我的工作方式。以前很多问题需要我先花不少时间自己收集线索、整理思路；现在如果问题描述得足够清楚，AI 往往能帮我更快收敛范围、补齐盲区、提高第一轮排查效率。

它没有替我做判断，但确实在帮我提升效率。这也是我现在越来越愿意把 AI 真正放进日常开发流程里的原因。

总结

如果你也在开发里用 AI，我建议你先别急着问“哪个模型最好”，而是先把这件事想清楚：

你有没有把问题描述成一个真正可分析的问题。

因为很多时候，工具差异没有你想象中那么大，

真正决定结果质量的，是你提供的信息质量和提问结构。

一句话总结这篇文章：

AI 不是不能帮你排查问题，而是你得先学会怎么让它真正进入排查状态。

大家加油：）