B站技术债务治理实战：存量修复加增量拦截的双轨治理体系
本文整理自QCon北京《何之真 - B站的存量修复和增量拦截》，通过AI音视频总结工具Ai好记视频转文字转录整理，以下为精炼整理后的会议笔记内容。
讲到技术债务治理，很多团队的第一反应是搞专项治理，短期把告警曲线降下来，过一阵子又反弹回去，然后再来一次专项。
B站工程技术团队的这篇分享提出了一个不同的思路：存量修复和增量拦截双轨并进，加上AI深度参与，构建一套可持续、自动化的技术债务治理体系。
整场内容对在中大型互联网公司做工程效能、开发者工具、代码治理的人都很有参考价值。
痛点：为什么技术债务治理这么难
B站除了视频，业务还包括直播、社区、生态、游戏、漫画、大会员、商业等，语言也很丰富，主力是 Java、Go、C++，移动端还有 Kotlin、Swift、鸿蒙等，代码仓库量级大且持续增长。
单以用户技助中心为例，整体代码量六七千万行，平均每人十几万行，每季度新增数百万行，而主站研发只有五六百人的规模。
传统治理有几个绕不开的问题：
- 专项治理不治本：是临时性、阶段性的动作，无法常态化，还会打断正常开发节奏，人必须做优先级取舍。
- 问题引入是持续过程：正常迭代、重构、bugfix 都会引入新问题，引入速度往往超过修复速度，债务越来越多。
- 人工修复周期长：从定位、复现、理解、尝试修复、验证（编译、单测、lint，甚至部署测试环境），到 app owner review 和合入，每一步都靠人，每步都可能因优先级卡住。
核心矛盾在于：修复是单点、离散的行为，而问题引入是持续不断的。所以作者认为要做好治理需要四个能力：
- 稳定的修复产能（不依赖人工排期）
- 可信的验证链路
- 风险分层机制
- 有人负责兜底确认问题并处理
AI 在治理中的价值
- 极大提高修复产能：人工一个一个修，AI 可以批量自动化，还包含验证步骤。
- 拓展增量拦截：在 MR 阶段的增量拦截里发现更多问题，避免它们变成历史债务。
- 知识沉淀：修复获得的经验转成 prompt 或 skill 及对应评测级，用于持续优化。
- 降低修复门槛：原来人要理解规则再改代码，现在 AI 能根据自然语言描述直接修，人只需看修复对不对。
双轨治理总体架构与核心原则
存量修复解决如何清空历史债务，增量拦截解决如何避免新问题合入主干成为新债务。两条轨道互相依赖：
- 存量修复的产出也是一个 MR，必须通过增量拦截再验证
- 增量拦截发现的新问题又能作为存量修复的输入扩大范围
- 存量端 AI 负责执行修复，验证交其他工具和角色
- 增量端 AI 扩展发现问题的范围并持续提高准确率
四条核心原则：
- 双轨并进：存量修复和增量拦截必须同时进行
- 风险分层：减少人工介入但保持可控
- 职责明确：规则负责发现和验证，AI 负责修复，owner 兜底决策
- 回流优化：成功失败结果都回流优化规则、prompt 和策略
存量修复：约束下的批量自动化修复
背景
团队 2024 年做了全公司工程能力建设，为几乎所有应用都增加了增量拦截环节，配置了包含编译、单测、lint（静态代码扫描）的流水线，要求不能有新增 bug，有的团队还要求不能新增异位或漏洞，甚至配置接口测试流水线发现接口不兼容影响。
流程
存量修复流程从 sonar 扫描开始，每个 MR 合并后流水线自动扫描相关应用拿到最新问题数。达到修复阈值后触发自动修复流水线，AI 在约束下工作：
- 只在自定义 linter 工具和 prompt 指定的问题类型内修复，不在全量问题上自由发挥
- 只在指定文件范围内修改
- 修复结果必须通过同一 linter 工具验证
- 生成的 MR 必须通过增量拦截流水线再次检验，最后由 app owner review 决策合入
为什么是半自动化？
早期试点时对所有有问题的应用每天全量跑修复，但研发正处于紧急新功能迭代，没时间 review，加上主干频繁合入导致 MR 一直冲突、最后不得不用 MR。
后来改成先收集扫描得到的问题数据做报表（按应用等级、部门、问题严重程度），同步给应用负责人，再根据应用重要程度和问题严重程度商定修复阈值，达到阈值才批量触发修复流水线，owner 也更有动力去 review 合入。
效果数据
- 用户技助中心代码异位从第一季度最高 1 万 4 千多降到接近平缓的 1 千 1 百多
- 叠加上其他业务整体一个季度下降约 90%
- bug 数因为工程能力建设加增量拦截，长期维持在个位数
增量拦截：在主干之外拦下新问题
AI 是对原有 CI 流程的补充增强。MR 的增量拦截流水线必跑编译、单测、lint，部分开启 AI 能力的仓库还会跑 AI 相关的流水线，比如 AI CodeReview、单元测试补充、接口测试补充。
所有流水线跑完后汇总结果，参考配置判断哪些弱软性失败不阻塞合入，综合得到 MR 是否 ready 合入的状态。
研发能看到问题描述和修复建议；对 AI 部分的问题可据建议修复，其他常规编译问题自行处理或暂缓。最终 owner 再做一次 review 决定合入。
AI CodeReview：对传统 lint 的补充而非替代
传统 lint 的局限：
- 要把经验固化成规则由工具执行，确定性极强
- 只能发现能形式化表达的问题
- 基于单行或局部模式匹配
AI CodeReview 的优势：
- 可以用自然语言描述审查意图
- 能理解代码上下文、函数模块调用链，甚至变更意图
- 从而发现难以规则化的逻辑和规范问题
- 具备需求视角，能对照需求、接口约束、预期行为判断实现有没有偏差
- 可构建数据闭环，审查结果（人工反馈、误报分析、问题归因）回流去迭代提示词、更新规则，提升识别能力和准确度
分层处理很关键：
- 对代码本身的审查是高置信度结论，作为阻塞合入的门槛，有问题必须修复
- 对需求实现的理解和评估是低置信度结论，只作为提示不阻塞，供研发参考
目前 AI CodeReview 只对一部分仓库开启，开启范围内准确率在 85% 以上。
AI 补充单元测试：围绕 MR 变更函数
流程：
- 从 MR diff 获取变更函数
- 用代码图谱加静态分析梳理这些函数的下游依赖
- 先去远端存储找现成单测执行并看覆盖率，超过阈值就结束
- 否则生成新测试
- 生成时在 prompt 里提供整条函数链路信息
- AI 生成的测试文件可能编译不过，会有修复编译循环（把编译报错、堆栈喂给 AI 修）
- 之后做两轮分析：
- 第一轮用变更函数及下游依赖信息对失败 case 归因，把非代码问题（环境、框架）的失败去掉，但不简单丢弃而是人工收集处理
- 第二轮给 AI 完整代码库梳理上下游依赖，去除无效 case（比如针对防御性编程的失败用例）
- 最终保留 AI 认为有效并经部分人工确认的用例保存云端复用
当前状态：
- 上线不到一个月，增量覆盖率约 85%
- 正确率还没到门槛（AI 标注有效 28 条、人工标注完成 22 条里 12 条有效、准确率 54.5%）
- 暂时不把它作为合入门槛，等正确率提到 80% 到 90% 再考虑
AI 补充接口测试：覆盖率驱动的迭代闭环
整体设计：
整体是两层循环。外层循环生成测试用例，内层循环修复测试用例执行中的问题。
设计原则：
- 尽可能覆盖未覆盖的链路
- 一轮只生成一个测试用例（避免批量生成互相干扰）
- 内层也一次只修一条问题（批量修容易出现级联问题、排查困难）
执行过程：
- 基于 mock 回放工具，发现下依赖缺失或 mock 内容不对就修
- 对时间戳、随机值这类高波动内容通过策略忽略
- 最后一轮数据链路复盘，比较接口实际响应和预期是否一致
- 不一致时让 AI 根据应用日志做完整归因复盘，输出交人工确认
当前状态：
目前是内部试点，效果波动较大，好的应用两三轮就能到 60% 覆盖率。
总结与展望
核心观点：
- 技术债务治理本质是持续运行的系统，不能靠一两次专项完成
- 存量修复和增量拦截必须同时做
- 验证要优先，AI 或人工修复都先通过验证再人工 review 合入
当前局限：
- 存量修复主要覆盖少部分低风险类型的规则
- 补充单测和接口测试都还处于小规模试点
未来方向：
- MR 合入最终还是由 owner 决定，后续可以尝试更精细的分层机制让某类问题自动修复
- 持续优化成本
- 总体落地思路是：先证明局部成立，再平台化扩张
以上内容由 Ai好记 转录整理。
Ai好记是一款支持音视频转图文笔记的AI知识库工具，支持B站、小红书、抖音、小宇宙等平台链接及本地音视频文件，视频转文字后自动生成精华速览、思维导图和结构化图文笔记，帮助你把几小时的视频内容变成可搜索、可复习的图文笔记。