微信扫码
添加专属顾问
通过AI精准预测代码变更风险,抖音质量效能部从“到处救火”转向“精准拆弹”,这套方法的核心思路首次公开。 核心内容: 1. 明确预测目标:不是“哪个模块有Bug”,而是“每次代码变更引入线上故障的概率” 2. 样本标注的关键经验:如何正确获取正负样本,避免常见陷阱 3. 特征工程的核心价值:在庞大代码库中,哪些特征比算法本身更重要
在抖音质量效能部搬砖那几年,每隔一段日子就会被拉进同一个“紧急群”——某个看起来人畜无害的代码提交,上线后把核心链路炸出一片红。复盘的时候大家总在叹气:要是能提前知道这模块“不干净”,哪怕多分一个测试人力进去也好啊。
后来我们还真搞出来了。没搞什么玄学,就是用 AI 做了一件事:每次代码变更,自动给这个变更的“出事概率”打分。从“到处救火”慢慢变成了“精准拆弹”。离开抖音后一直想把这套思路完整写下来,核心方法不涉及业务机密,今天就把这层窗户纸捅破。
很多人一上来就去找数据集、跑 XGBoost,结果折腾一个月连基线都出不来。我们最开始也犯了这个错。
真正要预测的不是“哪个模块有 Bug”,而是——“这次代码变更,引入线上故障的概率有多高”。这两者差别巨大。模块历史 Bug 多,只代表它旧债多,不代表这次改动一定出事;一个从来不出事的模块,被一个新人改了核心逻辑,往往才是大雷。
所以我们的预测对象是 commit(变更)。每一次 MR(Merge Request)提上来,模型就给它一个风险分。分高了,测试就重点关照,甚至直接卡发布。
有监督学习,第一步是拿到“有问题的变更”和“没问题的变更”作为正负样本。听起来简单,做起来全是坑。
我们当时的做法是打通两个数据源:
正样本:能追溯到某个 commit 是故障根因的,标为 1。
负样本:上线后安安稳稳跑了两周,没惹出任何线上工单的 commit,标为 0。
这里头有三个血泪经验:
① 千万别用“修复 Bug 的 commit”直接做正样本。
因为修复 Bug 的那个 commit 本身是解决问题的,它的 diff 特征通常是“加个判空”“修个边界”,和真正“写出 Bug”的 diff 截然不同。我们一开始没区分,模型学废了,以为加 if 判空是高风险行为,闹了大笑话。
② 窗口期要卡死。
一个 commit 上线后,到底观察多久没出事才算负样本?我们试下来,双周迭代下,观察 10 个自然日比较稳。有些模块上线后三天才因为定时任务暴露问题,窗口太短会把大量“还在路上”的 Bug 标成负样本,污染训练集。
③ 别做“一视同仁”的随机采样。
业务代码里,不出事的变更占了 95% 以上。如果你直接全量丢进去,模型会学到一招绝技:永远预测低风险,准确率贼高,屁用没有。我们后来做了下采样,让正负样本比例控制在 1:5 左右,同时给正样本加高权重,模型才学会认真对待那些危险信号。
抖音的代码库极其庞大,业务线几十条,语言主要是 Java/Kotlin/Go/C++。我们设计特征的时候只有一个原则:让不懂模型的人看了也觉得“有道理”。否则你推不动,研发老大会觉得你在搞玄学。
我们最终沉淀出五类特征,每一条都是跟开发、测试反复扯皮磨出来的:
例外是什么?纯 import 整理和格式化代码。这种变更动辄几百行,但几乎零风险。我们后来用正则扫 diff 内容,如果 90% 以上的改动行只是空白/缩进/import 替换,就直接压权重。
这个特征抓“屎山上的新包”非常准。有一回直播推荐模块一个小 MR,只改了 5 行,但扎在一个 1200 行、圈复杂度 38 的老函数里。模型直接给了高危。开发不信,结果上线当晚缓存击穿,故障单编号我到现在都记得。
我们给每个提交者算了一个开发者缺陷注入率:此人过去半年提交中,引入过线上故障的比例。这个值不是固定不变的,会按时间衰减,最近一次闯祸加权最高。
另外还加上:
当时组里有个实习生,能力很强但业务不熟,模型给他的 MR 几乎每次都标高。头两个月他很不爽,后来真出过两次 P1 故障,他主动请我们吃饭,说“这玩意儿比我 Code Review 靠谱”。
这些特征从 GitLab/Jira 的 API 里都能抓到。我们把它们拼成一张宽表,一条 commit 一行,大概 60 多个特征,最后模型训练全用这个。
伙伴们,对AI测试、大模型评测、质量保障感兴趣吗?我们建了一个 「人工智能测试开发交流群」,专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索,都欢迎扫码加入,一起抱团成长!期待与你交流!👇
我们也试过把 code diff 扔进 TextCNN、CodeBERT 里学语义,效果一言难尽——有时候它会给“修了个文案”的 MR 打高分,因为训练语料里很多故障 commit 也改了文案。纯粹捣乱。
最后老老实实用 LightGBM。快、稳、可解释性好,几千个 commit 几分钟训完,AUC 能做到 0.82~0.85(看业务线),已经完全够用了。
随手贴一段我们核心训练的骨架,脱敏后的伪代码:
import lightgbm as lgb
params = {
'objective': 'binary',
'metric': 'auc',
'boosting_type': 'gbdt',
'num_leaves': 31,
'learning_rate': 0.05,
'feature_fraction': 0.8,
'scale_pos_weight': 5, # 正负样本不平衡下的正样本权重
}
model = lgb.train(
params,
train_data,
valid_sets=[valid_data],
early_stopping_rounds=50,
verbose_eval=False
)
评估的时候我们不只看 AUC,而是看业务指标:召回率@Top20%。 意思是模型给出最高风险的前 20% MR,能抓住多少真正的故障变更。在我们几个核心业务线上,这个值稳定在 75%~80% 之间。翻译成人话就是:只重点测试 20% 的变更,就能提前拦截四分之三以上的潜在线上事故。
光报个“高风险”三个字,研发迟早会骂你是算命先生。我们一开始吃过亏,被人在周会上当面质疑:“凭什么说我的 MR 有风险?”
后来我们上了 SHAP,给每一个预测结果附上归因。MR 详情页里会显示:“本次变更风险评估为 高,主要因为:【修改文件历史故障密度高】、【开发者当前迭代首次接触该模块】、【圈复杂度增量达 12】。”
这玩意儿一上,风向立马变了。研发看完不是甩锅,而是主动去优化那坨高复杂度代码。有个客户端大佬看到 SHAP 归因里“圈复杂度”排第一,直接重构了播放器模块,后面三个迭代该模块故障清零。这个结果比任何模型指标都有说服力。
模型训完如果只生成一份报告邮件,结局一定是躺在邮箱里吃灰。我们做了三件事把它真正用起来:
1. CI 自动触发预测
提 MR 时,Jenkins 流水线自动调模型推理接口。如果风险分为“高”,自动在 MR 评论区发警告,并给测试负责人打 IM 消息。
2. 质量卡点
高风险 MR,强制要求:
3. 低风险快速通道
对于风险分极低的 MR,我们给了一条“轻测通道”,只跑冒烟用例即可合入。这大大缓解了测试团队的人力瓶颈,也是测试 leader 愿意全力推这件事的动力——他可以把人挪去真正危险的地方。
模型服务本身用 Flask 简单包了一层,后来迁移到公司内部的推理平台。每季度用最新数据全量重训一次,防止模型老化。冷启动问题,我们通过组织级架构知识图谱解决:新模块没有历史数据,但可以根据它依赖的底层库、所属业务域、代码结构相似度,从相近模块“继承”一个初始风险分。
最后泼盆冷水。如果你所在的团队:
那劝你先别急着上 AI。先搞数据基建,把“谁写的代码搞出了事”这件事追踪清楚。没有这个基础,模型就是空中楼阁。
对于样本不够的小团队,其实可以先搞一个加权规则引擎:把前面那些特征加权求和,人工调阈值。虽然糙,但比裸奔强一百倍。
离开抖音质量效能部有一阵子了,回忆起来,最让我自豪的不是模型 AUC 有多高,而是有一天,一个开发哥们儿在群里说:“我靠,这个 AI 比我老婆还了解我会不会写出 Bug。” 虽然作为技术人,我更希望他把精力花在别让自己老婆有机会了解这方面。
AI 从来不能取代测试工程师,但它可以把测试从繁琐的全面覆盖里解放出来,把有限的精力聚焦在最容易出事的地方。所谓“精准测试”,不是炫技,是你真真切切少接了半夜三点的告警电话。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-07-17
Google Colab 谷歌送了你一台「AI 电脑」 你还不知道?
2026-07-16
中国 AI 真正输给美国的,从来不是算力
2026-07-13
淘宝直播数字人 AgenticRL 实践:从 RLVR 到 MultiAgent RL
2026-07-02
AReaL 2.0 正式发布:面向 Agent 应用的 Online RL 微服务架构升级
2026-06-19
从 BERT 标注到 Agent Skill:短文本标签体系的四次“工业革命”
2026-05-14
多轮 Agent 场景下,滴滴的 EAGLE-3 训推加速实践
2026-05-06
谁说 Mac 只能写代码?Google 官宣:M 芯片本地微调 Gemma 4 时代开启!
2026-04-20
用 Unsloth 微调 Embedding 模型,让你的 RAG 检索不再答非所问
2026-07-17
2026-01-02
2025-11-19
2025-09-25
2025-06-20
2025-06-17
2025-05-21
2025-05-17
欢迎您使用【53AI 官方网站】(以下简称“本网站”或“我们”)。本《会员服务协议》(以下简称“本协议”)是您(以下简称“会员”或“用户”)与【深圳市博思协创网络科技有限公司】之间关于注册、登录及使用本网站会员服务所订立的法律协议。
在您注册或登录前,请务必审慎阅读、充分理解各条款内容,特别是免除或限制责任的条款、知识产权条款、争议解决条款等。此类条款将以加粗形式提示您注意。 当您通过微信公众号授权、手机验证码验证或其他方式成功登录本网站时,即视为您已完全理解并同意接受本协议的全部内容。
一、 定义
本网站:指由【深圳市博思协创网络科技有限公司】运营的,域名为【53ai.com】的网站及相关移动端页面。
会员服务:指本网站向注册会员提供的知识库文章查阅、内容检索及其他相关增值服务。
知识库内容:指本网站发布的包括但不限于文字、图表、数据、研究报告、行业分析等数字化内容资源。
二、 账号注册与登录
登录方式:本网站支持以下登录方式,您可根据实际情况选择:
微信公众号授权登录:您同意将您的微信OpenID信息授权给本网站,用于创建或关联会员账号。
手机验证码登录:您需提供真实有效的手机号码,并通过短信验证码完成身份验证与登录/注册。
账号安全:您的账号仅限您本人使用,禁止赠与、借用、租用、转让或售卖。因您保管不善导致的账号被盗、密码泄露等损失,由您自行承担。
实名认证:根据相关法律法规要求,我们可能要求您在特定功能下完成实名认证。如您拒绝提供,可能无法使用部分或全部服务。
未成年人保护:若您未满18周岁,请在法定监护人的陪同下阅读本协议,并在征得监护人同意后使用本服务。
三、 服务内容与规范
知识库查阅权限:会员登录后,有权按照其会员等级对应的权限范围,在线浏览、检索本网站知识库中的相关文章及内容。
服务变更:我们有权根据业务发展需要,调整、变更或终止部分服务内容,并将以网站公告、公众号消息等方式提前通知。
禁止行为:您在使用服务时不得实施以下行为:
利用技术手段批量爬取、下载、转存知识库内容;
将知识库内容用于商业目的或未经授权地向第三方传播;
干扰本网站正常运行或侵犯其他用户合法权益;
发布违法违规信息或从事违反公序良俗的活动。
四、 知识产权声明
权利归属:本网站知识库中的排版设计、软件代码等内容的知识产权均归【公司全称】或原权利人所有,受《中华人民共和国著作权法》等法律保护。
有限许可:本网站授予会员一项非独占、不可转让、不可转授权的普通许可,仅限于个人学习、研究之目的在线查阅知识库内容。
侵权追责:未经书面许可,任何单位或个人不得以任何形式复制、转载、摘编、镜像、汇编或以其他方式使用上述内容。一经发现,我们保留追究其法律责任的权利。
五、 个人信息保护
我们重视对您个人信息的保护。关于我们如何收集、使用、存储和保护您的个人信息,请单独阅读 《隐私政策》。
您通过微信公众号授权或手机号验证所提供的信息,我们将严格按照《个人信息保护法》的规定处理,仅用于身份识别、服务提供及安全验证等必要用途。
您可以随时通过网站设置或联系客服行使查阅、更正、删除个人信息及撤回授权同意的权利。
六、 免责声明
内容准确性:知识库内容仅供参考,不构成专业建议。我们不对其完整性、准确性、时效性作任何明示或暗示的保证,您应自行判断并承担使用风险。
不可抗力:因自然灾害、政策法规变化、网络故障、第三方平台接口异常(如微信接口维护、运营商短信通道故障)等不可抗力导致的服务中断或延迟,我们不承担违约责任。
第三方链接:本网站可能包含指向第三方网站的链接,该等网站的内容和服务不受我们控制,请您自行甄别风险。
七、 违约责任
如您违反本协议约定,我们有权视情节采取警告、限制功能、暂停服务、注销账号等措施,并保留要求赔偿损失的权利。
如因您的违约行为导致我们遭受行政处罚、第三方索赔或商誉损失,您应承担全部赔偿责任(包括但不限于罚款、赔偿金、律师费、公证费等)。
八、 法律适用与争议解决
本协议的订立、执行和解释均适用中华人民共和国大陆地区法律。
因本协议产生的或与本协议有关的任何争议,双方应友好协商解决;协商不成的,任何一方均可向【公司所在地】有管辖权的人民法院提起诉讼。
九、 其他
本协议构成双方就本服务达成的完整协议,取代此前任何口头或书面约定。
本协议任一条款被认定为无效或不可执行的,不影响其他条款的效力。
我们对本协议享有最终解释权,并在法律允许的范围内保留随时修改的权利。修改后的协议一经公布即生效,继续使用服务即视为同意修订内容。