训练AI测Bug发现CTO十年前遗留的屎山

这事过去两周了，但回想起来还是会让人心头一紧。

起因其实很简单，就是在团队里搞了个小实验——用历史缺陷数据训练一个模型，让它学会“闻”代码里的坏味道。目标并不复杂：在提交代码之前，自动扫一遍，把高风险区域标出来，省得每次都要靠人眼去review那些陈年代码。

训练数据用的是我们仓库过去五年的缺陷记录和对应的代码提交。模型本身不算复杂，一套基于代码AST的向量化表示，加上一个缺陷倾向性分类器，跑了几轮交叉验证，准确率还不错。

有意思的事情，发生在第一次全库扫描的时候。

它在一个人人都不敢动的模块里，标记了一个极高风险函数。模块是订单对账的核心，代码注释里写着“2009/03/15 老张”。那个函数逻辑极其扭曲：各种硬编码的魔数、嵌套五层的if-else、还有一段明显是反着写的金额比较。模型给它的风险评分是0.97，而我们人工标注过的已知缺陷区最高才0.82。

我把这段代码摘出来，找了一位在公司待了13年的架构师看。他盯着屏幕沉默了两分钟，然后说了一句让人后背发凉的话：“这是当年CTO写的。那时候公司刚起步，对账老差1分钱，他半夜临时糊上的。”

这段代码在线上跑了十年，从未被改过。不是因为没问题，是因为没人敢碰，也没人在回归测试里覆盖到它的异常分支。

AI把它揪出来了。

为什么突然想训练一个“闻Bug”的AI

我们团队的自动化用例覆盖率早过了85%，线上事故却没见少。复盘时发现一个规律：真正造成线上问题的，不是新功能逻辑，而是改老代码时触发的隐藏副作用。那些十年前的代码，没人记得当初的上下文，单元测试要么没有，要么写的假，回归用例又不可能把每行代码的每个分支都跑一遍。

人工review面对这种代码，其实也力不从心。reviewer的注意力会被新业务逻辑吸引，老模块的改动只要编译过、看起来不突兀，大概率直接放行。

于是就有了一个想法：有没有办法让机器把全仓库扫一遍，专门找出那些“看起来就像会出Bug”的代码？ 这个想法的核心假设是：缺陷不是均匀分布的，它们会聚集在某些特定模式的代码里。如果能让模型学会识别这些模式，我们就能在代码合入前精准预警。

屎山是怎么形成的：CTO留下的时光胶囊

模型标出的那个高风险函数，场景是这样的：对账系统需要比对内部订单金额和外部支付渠道的回调金额，在分账场景下，要把总金额按比例拆给多个商家。

正常写法是：总金额先转成int（分），按比例乘除，最后再转回元。但这函数用了一堆浮点数直接做加减，末尾还用了一个魔数0.001做误差容忍。更诡异的是，有一行判断写了if (Math.abs(diff) > 0.001 && diff < 0)。第一眼看过去，这个条件永远为false，因为diff大于0.001就不可能是负数。但仔细看上下文才发现，他在前面把diff取了一次反，这行判断其实是生效的——以一种极度扭曲的方式。

当年的背景是：支付渠道回调金额偶尔会有浮点尾差，导致对账报错，技术团队排查了很久没找到根因。CTO为了保上线，半夜写了这个容忍逻辑，硬把误差吃掉了。

这段代码的问题不在于逻辑错误，而在于它的“隐蔽正确性”。它在当前数据下恰好正确，但只要上游金额计算的精度规则稍有变化，这个0.001的硬编码就会产生真正的对账差异。而且没有任何测试用例能发现它，因为异常分支的触发条件被浮点误差掩盖了。

训练过程：让AI学会闻代码的“味道”

说回模型本身。它的目标不是理解业务逻辑，而是学习“缺陷倾向模式”。这个模式被拆成了三个维度。

第一个维度是代码结构复杂度。圈复杂度、嵌套深度、函数长度这些硬指标是基础，但更关键的是“修改频次与缺陷的关联”。一个函数如果改10次有7次伴随缺陷修复，那它的结构大概率有问题。

第二个维度是代码克隆率。如果一段代码是通过复制粘贴产生的，并且在不同模块里有轻微变体，它的缺陷概率会显著上升。因为当初的bug很可能也被复制了，只是还没暴露。

第三个维度是注释与代码的一致性。这里用了一个小模型来比对函数注释和实际实现。注释说“计算退款金额”，实际代码里却有扣减积分的逻辑，这种不一致是高危信号。

训练数据是过去五年里4300多个缺陷修复的commit，提取出每次修复前的“坏代码”和修复后的“好代码”，做成成对样本。模型结构就是CodeBERT做backbone，后面接一个二分类头，输入是函数的AST序列化表示，输出是0到1的风险分。

验证集上做到0.79的precision和0.83的recall。不算惊艳，但作为辅助筛查工具足够了。

模型发现的不止一个Bug，是一类反模式

CTO那坨代码被标出来之后，顺着模型的高分结果继续排查，发现它不止找出一个具体问题。它实际上标记出了一类反复出现的反模式：“带误差容忍的浮点金额计算”。

全仓库一共扫出14处类似模式，分布在对账、结算、优惠券分摊、运费计算四个模块里。其中3处已经暴过线上问题并被修复，剩下的11处里，有5处在特定条件下可以重现计算偏差。虽然大部分偏差在1分钱以内，但叠加高频业务场景后，部分月份的对账差异能累积到几百元。

这类问题靠人工review几乎不可能全揪出来。因为它分散在多个模块，每个单独看都像是正常的容错处理，只有拉通全局才知道这是一个系统性的设计缺陷。

一个缺陷是事故，一组同模式缺陷就是架构负债。

如果没有AI，这类Bug能藏多久

CTO那段代码藏了十年。不是没有测试，而是所有测试都在验证“正常情况下对账金额正确”，没有任何一个用例去验证“误差容忍的边界值”。因为当年写用例的人根本不知道有这个容忍逻辑——它写死在代码里，没有在需求文档里出现，也没有在接口说明里暴露。

这种“代码里偷偷做了容错”的情况，在老旧系统里其实很常见。开发人员为了解决一个紧急问题，在底层做了兜底，但没告诉任何人。测试人员按照接口文档写用例，永远触达不到那个分支。代码就这么安安静静地躺在线上，成了一个定时冲击波。

AI能把它找出来，靠的不是聪明，而是“不挑食”。它不会因为这段代码在核心模块就不敢报，也不会因为注释写着“临时”就放松警惕。它会平等地扫描每一行代码，用数据训练出的嗅觉做判断。

这件事改变了我对测试的认知

以前认为测试的价值在于“验证”，确认系统做了该做的事。现在觉得测试的更大价值在于“发现未知”——找到那些连开发者自己都忘了的隐藏逻辑和假设。

传统测试依赖一个前提：需求明确，预期清晰。但老旧系统的真实状态是：代码即需求，行为即文档。当你面对十万行无人维护的代码，谁也不知道它真正在做什么的时候，用例覆盖率的数字是骗人的。

AI在这件事上的优势是，它不需要理解业务就能发现异常。它把“未知的未知”转化成“已知的未知”，然后人再去判断这个未知是不是风险。这可能是AI测试最被低估的价值。

不是用AI替代人写用例，而是用AI做人做不到的全量扫描。

你也可以训练一个，不需要大模型

这个方案的门槛没有想象中那么高。核心三件套：Git历史、缺陷记录、一个轻量级代码模型。

这里用的CodeBERT是开源的，一张消费级显卡就能跑推理，训练用colab的免费GPU也能搞定。真正的工程量在数据清洗上——你需要从Git历史里把“缺陷修复”的commit挑出来，和对应的“缺陷引入”commit配对。这一步可以用SZZ算法自动标注，准确率70%左右，再加人工抽样校验就够了。

如果不想训模型，还有更简单的路径：用现有code embedding工具把仓库所有函数向量化，再用已知缺陷函数做相似度检索。这个方法虽然粗暴，但对于找出“复制粘贴型缺陷”特别有效。

不管用什么技术路径，核心逻辑是一样的：让数据说话，让模式显形。

你现在维护的系统里，有没有那种“没人敢动、动就出事”的代码区域？你有没有想过，里面可能也藏着一颗十年前埋下的雷？

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：训练AI测Bug发现CTO十年前遗留的屎山要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题