找Bug这件事，AI正在学会“自己动手”

一个干了八年的后端工程师跟我说过一句话：修Bug不难，难的是知道Bug在哪。给一个明确的报错堆栈和复现步骤，大部分问题半小时内能搞定。真正消耗人的，是从“用户说有问题”到“定位到哪一行代码”之间那段漫长的、靠经验和直觉填满的灰色地带。

AI正在进入这段灰色地带。但它的表现，比营销话术里讲的要复杂得多。

从“看代码”到“用软件”

大多数人对AI找Bug的想象是：把代码扔给模型，它指出哪里有错。这条路确实有人在走。2026年IEEE发表的一项研究用T5架构的Transformer做缺陷预测和代码审查，在CodeXGLUE等数据集上跑出了接近八成的准确率。另一套叫GenAI的全栈审查系统声称在230万行代码上实现了87%到93%的Bug检测精度，误报率低于8%。这些数字如果当真，听起来已经很能打了。

但这里有一个根本性的错位。静态看代码找出来的“Bug”，和用户真正遇到的Bug，往往不是一回事。代码审查工具擅长发现的是空指针风险、资源泄漏、逻辑分支遗漏这类模式化的缺陷。而一个购物车在删除商品后总价显示NaN，可能不是因为任何一行代码“写错了”，而是几个服务之间的数据契约在某条特定路径上断裂了。看diff看不出这个问题，跑单元测试也跑不出来，只有真的点那个删除按钮，看到屏幕上跳出那个刺眼的“NaN”，你才知道出事了。

这正是新一代AI找Bug的转向所在。arXiv上有一篇关于SWEeper-Bench的论文，标题问了一个很直接的问题：AI能不能在我们发现Bug之前找到它们？论文的结论不太乐观：当Bug报告已经存在时，当前智能体修Bug的成功率相当高；但当要求它们自己去找Bug时，通过率最高只有59%。差距不在修复能力，在测试。智能体需要自己决定该试什么场景、怎么在界面上操作、以及最重要的——看到异常时能不能认出来这是个Bug。论文里举了一个例子：在一个任务中，四个被检查的智能体都看到了故障现象，但只有两个把它判定为Bug。另外两个觉得“这大概就是设计如此”。

这个细节比任何基准分数都更有信息量。AI找Bug的瓶颈，正在从“看不懂代码”变成“不理解什么算不对劲”。

那些已经跑通的路

不过，在边界更清晰的场景里，AI找Bug已经跑出了可用的闭环。

一个叫opscopilot-core的开源项目展示了很务实的思路。用户提交一个Bug报告加一张截图，系统先读图、再结合API响应做结构化理解，然后用这个理解去检索仓库里最可能相关的代码，给出根因诊断和置信度。置信度不够的时候，它不硬猜，而是问一个具体的问题——“能把GET /api/cart的响应贴一下吗？”。这个设计的聪明之处在于承认了AI的局限：看图说话能缩小范围，但确认事实需要人补最后一脚。

字节跳动的LogSage走的是另一条路，针对CI/CD流水线失败。它用token高效的日志预处理过滤噪声，再用RAG复用历史修复方案。在367个GitHub CI/CD失败案例上，根因分析的精确率超过98%。更关键的是在字节内部部署一年的数据：处理了超过107万次执行，端到端精确率超过80%。这个数字的意义在于，CI/CD失败的根因相对收敛——依赖冲突、环境配置、测试超时——模式重复度高，AI的历史经验确实能派上用场。

更激进的是SENTINEL这类工具。它在Docker沙箱里跑测试、定位失败、提出补丁、再跑一遍测试确认变绿，低风险的修复直接自动合入，敏感文件才留给人审。这套流程的前提是测试覆盖足够好，否则“修好了”可能只是把测试骗过去了。IBM Research对五个先进修复智能体的分析印证了这个风险：它们擅长简单修复，但面对逻辑密集的Bug时，经常产出“仅仅满足现有测试”的过拟合补丁，而且普遍缺乏调试器和程序分析器的支持，手里只有bash脚本。

一个被低估的变量：解释的价值

在讨论AI找Bug时，人们习惯用“找没找到”“修没修对”来衡量。但有一类价值被严重低估了：解释。

一项针对编程初学者的研究发现，LLM在定位故障时不仅给出位置，还提供解释和引导，这对新手的学习帮助极大。参与实验的一年经验程序员对解释质量给出了持续的高评价。这个发现的意义超出了教育场景。想想日常工作中最消耗人的时刻：不是修Bug本身，而是当你知道某段代码有问题但说不清楚为什么，或者你需要向一个不熟悉这块代码的同事解释“这里为什么会炸”。一个能说清楚“get_total_price除以了len(items)，而items为空时这里就是NaN”的工具，即使不自动修复，也已经省掉了半小时的排查和半小时的沟通。

这或许才是AI找Bug最现实的落地形态：不是替代人做判断，而是把“从现象到根因”那段推理过程变得可见、可追溯。人依然要做最终决定，但决策的信息基础从“我猜大概是这里”变成了“有证据指向这里，置信度0.86，这是推理链”。

冷静的必要

把话说回来。AI找Bug这件事，厂商数据和研究数据之间存在一道不小的鸿沟。

SWR-Bench的独立评测给AI代码审查泼了一盆很冷的水：最好的系统F1只有19.38%，大多数技术精确率不到10%，意味着被标记的问题里绝大多数是误报。论文作者的结论是“尚未准备好投入真实部署”。这和厂商自己发布的“82%检出率”之间的落差，一部分来自评测方法的不同，一部分来自“检出率”和“精确率”的选择性披露——说抓到了多少Bug很容易，说有多少次是冤枉的，没人爱提。

另一个根本性的限制是测试质量。AgentRepair在51个BugsInPy基准Bug上修好了26个，成功率刚过一半。SENTINEL和LogSage的亮眼数字都建立在“有可运行的测试套件”或“历史失败模式可复用”的前提上。对于没有测试覆盖的遗留系统，或者从未出现过的新类型故障，AI找Bug的能力会迅速退化回“猜”的水平。

结语

找Bug这个行当，本质上是信息不对称的博弈。你知道系统大概哪里不对劲，但需要付出大量成本才能把“大概”变成“确定”。AI在做的，是把这段成本的一部分承接过去：用视觉理解读截图、用检索缩小代码范围、用历史案例匹配已知模式、用解释把推理过程摊开给人看。

但它还没有学会的是，知道什么算“不对劲”。那个判断需要的是对产品意图的理解、对用户预期的感知、以及在模糊信号中分辨“这是Bug”还是“这是特性”的直觉。SWEeper-Bench里那两个看到故障却无动于衷的智能体，恰恰说明了这个缺口有多真实。

所以现阶段最诚实的描述大概是：AI能让找Bug的过程快很多、解释清楚很多，但它还不会替你说出那句最关键的话——“等一下，这不对。”那句话，仍然需要一个人看着屏幕，皱起眉头。