原来的做法与痛点
原来读代码是从上往下硬读，300 多行读完要两小时，读完还不知道哪里会超时，因为调用链跨了三个内部服务，我看不到它们的实现。真正卡住我的是：我不知道该信它给的结论——它把慢查询归因成「可能是数据量增长」，这句话没错但没法开工。
实际用的提示词（原文）
角色：你是和我一起接手了一个没人维护的模块的后端工程师同伴。
下面是我贴出的代码和它的报错。你的任务是帮我定位，
但我要的是证据链，不是可能性列表。
【模块背景】
服务：订单履约，Java 11 + Spring Boot 2.3，MySQL 5.7
这个类上线两年没人改过，日均调用 40 万次，最近开始出现超时告警
上游依赖：{{库存服务}}，超时时间设成了 800ms
【代码】{{OrderDispatchService.java}}（约 300 行，我分成 3 段贴）
第 1 段：dispatch() 主流程
第 2 段：queryStock() 与重试逻辑
第 3 段：catch 块与日志
【告警现象】
工作日 10:00-11:00，P99 从 300ms 涨到 2.4s。
慢查询日志里出现一条
SELECT ... FROM t_order WHERE status = 0 LIMIT 500，
这条 SQL 每天执行约 3000 次。
【请你按这个顺序回答】
1. 这条慢 SQL 是索引问题还是查询写法问题？给出你的判断依据，
以及「怎么验证」的具体命令，或者 EXPLAIN 结果里该看哪几列
2. dispatch() 里最多列出 3 个可能原因，按可能性排序。每个给出：
证据（从代码第几段看出来的）／验证方式／修复动作／修复的回归风险
3. 给一个最小改动方案：只改必要的地方，逐处说明改的理由。
如果你认为需要重构，把它单独放在「以后再说」里，不要混进方案
4. 列出 3 个你无法从代码判断、需要我补充信息才能确认的点
限制：
- 不要假设我没贴出来的代码。需要看别的类时，写清楚你要看哪个类的哪个方法
- 不要凭框架版本的行为差异下结论，需要查文档的地方直接说「需要查 X 文档」
- 修复方案要给出上线顺序和回滚条件
- 不要写「建议增加缓存」这种没有具体动作的话这是这个案例最有价值的部分：注意它把「背景、约束、输出格式」写在了哪里。
实际结果
它把慢 SQL 的问题判断对了，而且给出了我没想到的验证动作：用 EXPLAIN 看 Extra 字段里有没有 Using filesort。第 2 段的重试逻辑它指出了一个真实存在的 bug——catch 里重试时把原异常吞了，导致失败请求被记成成功。但它的排序里有一个原因排在第 2 位，我实测下来并不成立。整体这次是「省了读代码的两小时，省了验证的两小时」，但改完我仍然花了一整天做灰度和回归，这部分 AI 帮不上。
花费时间：首次定位 3 小时（比原来的两天少一半），后续同类问题约 1 小时
踩过的坑
- 不给模块背景，它会给你一份通用最佳实践清单，跟我的代码无关。背景那四行（语言、版本、调用量、超时配置）是提示词里最值钱的。
- 它倾向于一次给三个以上的原因。我在提示词里写死「最多 3 个，按可能性排序」，它才开始把最可能的那个说清楚。
- 不要把整个仓库丢给它做「整体分析」。我只贴相关的那 300 行并且分三段，第一次贴的时候它把三段当成了三个文件，推理就断了。分段贴的时候必须标明「这是同一个类的第几段」。
本案例更新于 2026 年 9 月 19 日。结果数据来自实际使用，工具能力更新后表现可能变化。