AI CodeReview 实践：代码变更阶段的风险识别与阻断

1. AI CodeReview 险识别与阻断演讲人：严宽实践：代码变更阶段的风

2. 01 代码审查概念及行业现状 02 AI代码审查在B 站的实践 03 未来展望目录

3.

4. 01 代码审查及行业现状

5. 传统代码变更流程开发者提交代码开发者发起PullRequest/Merge 自动化测试人工代码审查通过CI流水线的方式执行一系列的自动化任务对变更进行评估测试同时有其它开发者完成本次变更的人工代码审查反馈与修改代码提交人针对上一步流水线的执行情况以及代码审查人员的审查意见进行修改，并重复提交直到认定审查通过代码合并代码变更合入到主分支 Request

6. 代码审查的价值与痛点风险阻断与拦截耗时耗力统一标准规范主观性强传统CR 的双面性知识共享知识壁垒代码质量保障低效/流于形式

7. 大模型时代的代码审查模型 1 功能 4 国外： • Claude Opus 4 • Claude Sonnet 4 • Gemini 2.5 Pro • GPT - 5 • • • • 国产： • Qwen3 - Coder • Deepseek - R1 • Kimi- K2 PR 描述变更评审代码建议 chat 2 IDE/CLI产品 3 国外： • Claude Code • Gemini CLI • Cursor • Coplit WEB端产品 • Bito AI • CodeRabbit • Sourcery 国产： • Qwen Code • 通义灵码 • Comate • CodeBuddy

8. 02 AI代码审查在B 站的实践

9. 系统全貌

10. 系统架构 AI CodeReview 交互层 MR 内变更审查总览 MR 行间评论审查平台知识层工程编码规范业务自定义规范内部技术文档框架层 Chat Agent RAG 模型层 GPT DeepSeek Claude Gemini 问题反馈历史数据及问题追踪业务缺陷集 CodeRAG Qwen ……

11. 实践落地中的挑战 P 代码上下文缺失效果评测仅仅关注代码diff部分的简单上下文，能够支撑高质量的审查结果吗？模型切换、框架切换、提示词更新，如何对系统进行重新评估？ A 如何解决？准确性/稳定性 D 用户感知大模型输出结果存在不确定性，直接影响审查效果，如何进行修正？如何让用户感知到整套系统的存在，并深度融合研测流程？ C

12. 挑战1：代码上下文缺失如何通过变更片段感知整体仓库？变量、函数、类从哪里来？调用链路是否被破坏？跨文件/跨模块调用关系是怎么样的？

13. 方案比较：文本检索 Glob ：根据给定通配符，在文件系统中递归查到文件 1 Grep ：根据给定正则pattern，在文件中匹配相关内容方案代表：Claude Code/Gemini 2 Cli 方案特点：实施简单，没有语义，没有结构，只是原始的字符串匹配检索精度带来的误匹配/漏匹配问题，项目体积膨胀带来的检索成本问题

14. 方案比较：RAG+ 构建索引 1 RAG ：相比于传统RAG 对于文档类知识的切块方法，使用AST 可以最大程度保证代码语义和连续性，在检索方面，仍使用语义相似度的方法代码索引： Merkle 树树形层级结构，节点存储 hash 值，作为索引底层结构，方便响应代码更新方案代表：Cursor 2 方案特点：更适合本地IDE场景，而非流水线执行场景语义相似度进行代码检索，并非代码链路的真实体现

15. 解决方案：构建CodeGraph 实现CodeRAG 让大模型看到真实的代码链路 CodeBase - > CodeGraph 三元组定义

16. 构建CodeGraph ：代码节点解析仓库遍历文件过滤路径节点代码仓库结构类关系 AST 解析文件节点符号节点

17. 构建CodeGraph ：语义关系挖掘请求LSP AST 查询引用位置符号节点关系识别引用符号节点语义关系

18. 构建CodeGraph ：效率提升 MonoRepo拆分增量构建

19. CodeRAG ：CodeGraph - > CodeContext Git diff CodeContext CodeGraph Generate AST "library/cache/redis/multikey_cmd.go ": { "classes": [ …… ], "functions": [ …… ] Query # 代码上下文以下是和 git diff 相关的代码上下文信息，你可以结合这些信息进行分析。 ## 函数路径： library/cache/redis/multikey_cmd.g o.splitMSet …… ### 被调用相关函数: …… ### 上层函数（调用该函数的函数）： …… ## 类路径： …… ### 字段相关类型: …… ## 同一个模块下的文件： ……

20. 挑战2 ：准确率/稳定性提升模型给出的行号不准确怎么办？问题类型太宽泛，无法对重点问题进行召回怎么办？模型无法理解特定业务场景下的问题怎么办？模型多次审查发现的问题都不一样怎么办？

21. 行号修正提升审查准确率行号标注查询CodeGraph

22. 共建审查规范提升审查准确率 1 工程团队：编码规范 2 业务研发：自定义规范 3 架构团队：内部技术文档让大模型了解业务需要的审查规范究竟是什么

23. Multi- Agent 提升持续审查稳定性问题审查Agent 问题质检Agent 修复建议Agent Commit_1 Issues_1 历史问题审查 Agent 问题质检Agent Commit_2 修复建议Agent Issues_2 问题审查Agent 历史问题审查 Agent 问题质检Agent Commit_3 问题审查Agent 修复建议Agent Issues_3

24. 挑战3 - 效果评测：评测标准类别指标描述评价方式耗时完成一次分析的时间开销记录起止时间分析过程中消耗的 Token 数统计 API 调用 Token 使用量效率类 LLM Token 消耗上下文理解是否准确理解函数调用关系和依赖问题识别准确性是否准确识别出代码中的潜在问题修复建议质量修复建议是否合理、符合语言最佳实践性能考量是否考虑代码变更可能带来的性能影响安全性评估是否发现潜在安全风险并给出提示可维护性分析是否评估代码的可读性、可扩展性、可测试性错误率是否存在错误或误导性建议准确性准确率正确识别的问题 / 总识别出的问题 (Precision) P = TP / (TP + FP) 覆盖率召回率正确识别的问题 / 实际存在的问题 (Recall) R = TP / (TP + FN) 质量类 LLM 评估 1–10分

25. 效果评测：数据集制作类别生产方式描述正例/反例 AI生成问题 AI生成用于系统初期建设或罕见问题的评测正例线上问题反馈人工录入对线上实际发生的问题和问题代码段进行绑定用于评测正例 QA 测试BUG 人工录入对QA 测试过程中发现的BUG 和问题代码段进行绑定用于评测正例 AI代码审查发现问题自动录入对用户采纳修复意见的问题作为正例用于评测正例用户标注误报自动录入将用户任务误报的问题作为反例用于评测反例

26. 效果评测：评测平台

27. 挑战4 - 用户感知：融合DevOps 打通CI流水线，响应MR 中的代码提交，持续对代码进行自动化审查

28. 用户感知：代码准入将AI CodeReview 的结果，作为人工代码审查以及流水线执行结果的补充，共同作为MR 是否能够合入的标准

29. 用户感知：MR 变更审查总览总览评论： • 审查任务进度：根据用户配置的审查任务开关，编排审查流程，并展示执行进度 • 审查问题概览：展示审查发现问题的基本信息及状态，并提供跳转行间评论/审查平台的入口 • 变更总评：对本次变更进行整体评价，得到一个变更打分，并对是否应该合入主干进行指导

30. 用户感知：MR 行间评论行间评论： • threads：根据问题范围确定行号，将问题以行间评论的形式写入到mr中并发起一个thread，方便研发快速定位问题 • 问题详情：展示审查问题的详细描述及改动意见 • Suggest Change：对于有明确修复路径的问题，生成suggestion格式的修复结果，方便研发自动修复问题

31. 用户感知：审查平台数据聚合及追踪：问题反馈：将仓库历史MR发现的问题进行聚合展示提供反馈入口，对于置为误报/暂不处理的问题将不会在后续的审对仓库代码质量健康情况进行追踪及评估查结果中出现

32. 实践效果：典型案例逻辑校验缺失空指针解引用风险

33. 03 未来展望

34. 未来展望 1 审查左移将代码变更阶段的基础上，将能力进行封装，结合IDE插件/CLI工具，在研发本地编码过程中进行审查，提升问题发现及时性，降低修复成本 2 需求打通通过对需求文档进行解析，将其中包含的业务属性作为审查的标准之一，共同对代码变更做出评估 3 接口链路打通将代码变更节点所在的完整接口链路调用信息，以及接口间的调用拓扑信息，共同作为AI 评审的私域知识

35.

36. THANKS 大模型正在重新定义软件 Large Language Model Is Redefining The Software