本文整理自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站、小紅書、抖音、小宇宙等平臺鏈接及本地音視頻文件視頻轉文字后自動生成精華速覽、思維導圖和結構化圖文筆記幫助你把幾小時的視頻內容變成可搜索、可復習的圖文筆記。