AI 排查 Bug，真正难的不是分析，而是先把代码找准 最近在做一个 Bug 定位工具时，我越来越明显地感受到一件事：AI 能不能帮你排查问题，关键不在于它会不会“分析”，而在于它一开始能不能拿到正确的代码上下文。 很多人一上来就想把整个代码文件、甚至整个项目丢给大模型，让它自己找问题。听起来很智能，实际很危险。文件太大，Token 爆炸；无关代码太多，上下文污染；模型看得越多，反而越容易抓不住重点，最后给出一个看似合理但根本不在问题现场的结论。 所以我现在更倾向于做一件事：先把代码定位做准。 我的思路不是“全文读取”，而是“线索驱动定位”。比如日志里出现了某个错误文本，就用这个日志模板反查代码；堆栈里出现了 "OrderServiceImpl.java:128"，就直接定位到这个文件和行号；Jira 描述里有接口路径，就从 Spring Controller 的 "@RequestMapping"、"@PostMapping" 里找入口；如果有错误码，就去找这个错误码真正被抛出或返回的位置，而不是只找到枚举定义。 这里面最核心的是两步。 第一步是快速搜索。代码仓库可能有几十万行、上百万行，不能靠 AI 慢慢读。用类似 ripgrep 这样的搜索能力，先根据类名、方法名、日志文本、错误码、接口路径、Mapper 方法、配置项等线索，快速锁定候选文件和命中行。 第二步是精准切片。找到行号还不够，真正需要交给 AI 的，不应该是整个文件，而应该是“命中行所在的完整方法”。比如日志命中了第 67 行，那就把这个日志所在的 Java 方法完整提取出来；如果方法太长，就保留方法头、命中行附近、尾部 return 或 catch 逻辑，中间折叠掉。这样模型看到的是问题现场，而不是一堆无关背景。 针对 Java/Spring 项目，还需要做一些专门优化。接口问题优先找 Controller；业务逻辑优先看 ServiceImpl，而不是接口定义；数据库相关线索要能关联 Mapper 接口和 XML；配置问题不能简单忽略 application.yml，因为很多线上问题就出在超时、开关、连接池、第三方服务配置上；日志没有堆栈时，也可以通过稳定的日志文本反查代码模板。 最终返回给 AI 的，不是一坨源码，而是几个高质量片段：文件路径、类名、方法名、命中行、命中原因、置信度，以及带行号的代码块。通常 Top 3 就够了。 这件事看起来没有“AI 自动修 Bug”那么炫，但我觉得它更关键。因为 Bug 排查的第一步从来不是让 AI 大胆猜，而是让它站到正确的位置上。 代码定位越准，后面的分析才越靠谱。否则再强的大模型，也只是在错误的上下文里一本正经地胡说。
