AI CR PLATFORM · TRAINING自建数产品线

01 / 20

◆　◇　◆

AI 代码审查
从一次 MR开始

FROM COMMENT TO QUALITY GOVERNANCE

把团队经验变成可执行、可证明、可迭代的审查标准。

AI研发小组

方银威分享人

2026/8/12日期

AI CR PLATFORMOPENING2026 · INTERNAL

第二部分AI 代码审查平台

03 / 25

◆　◇　◆

第二部分

从三类真实问题
看见审查盲区

规范、结构与业务语义，为什么不能只依赖人工记忆或模型猜测？

AI 代码审查平台03部门宣导培训

CASE 01 · DETERMINISTIC代码规范，需要稳定执行

03 / 20

一条代码规范，过去靠人肉记忆

禁止的 import，
必须在 MR 里被指出。

团队规范很明确：不能使用阿里云 StringUtils。真正的问题是，它能否稳定、自动、逐行地落到开发现场？

平台做法
规则卡片固化规范，规则检测器用正则 / 代码模式匹配检测，MR（合并请求）创建后自动评论违规 import 与替代建议。

p-7 · 行级评论证据

案例一03RULE → EVIDENCE

CASE 02 · AST / DATAFLOW性能风险也能确定性识别

04 / 20

p-8 · 循环体与 IO 调用关系

一个风险，不能靠大模型猜

循环体内禁止调用 IO

检测器沿代码结构追踪“循环体 → IO 调用”的关系，在规则层直接确认风险，保证同样的代码得到同样的结论。

01定位循环体for / while / stream

02识别 IO 调用文件、网络、数据库

03回写行级评论指出位置与建议

案例二04AST → DATAFLOW → COMMENT

案例三 · BdcXmServiceImpl 2624–2626代码看似正确，却不符合业务逻辑

05 / 24

项目摘要，不能精确查权利人明细

“拼接摘要”
不能精确找人。

bdc_xm.qlr / qlrzjh 是项目上多名权利人的拼接摘要，用于列表展示和候选筛选；真正可定位到人员的记录在 bdc_qlr 明细表中。

为什么会错？
一个项目可能有张三、李四两名权利人。项目表保存的是“张三、李四”这样的汇总文本，不代表其中任何一个人。应以 xmid 关联，查出该项目的全部权利人明细。

问题代码 · 将项目摘要当作精确条件

// qlr / qlrzjh 是多值拼接摘要，不是人员唯一标识
BdcQlrDO bdcQlrDO = new BdcQlrDO();
bdcQlrDO.setQlrmc(bdcXmDO.getQlr());
bdcQlrDO.setZjh(bdcXmDO.getQlrzjh());
entityMapper.selectByObj(bdcQlrDO);

修复方式 · 按项目 ID 查询权利人明细

// xmid 关联明细，结果可准确对应项目下的每位权利人
BdcQlrDO bdcQlrDO = new BdcQlrDO();
bdcQlrDO.setXmid(xmid);
List<BdcQlrDO> qlrList =
    entityMapper.selectByObj(bdcQlrDO);

案例三05

THE COMMON THREAD问题的共同结构

06 / 20

三类问题，三种审查依据

同在代码里，
判断依据却并不相同。

代码规范

禁止使用什么？

禁用引用、危险 API、固定写法。

正则 / 代码模式匹配

结构与性能

代码关系是否危险？

循环体与 IO、调用链与资源释放。

代码结构与数据流分析

业务语义

业务上什么才正确？

摘要字段、状态边界、服务职责。

知识库与智能体分析

平台的关键，不是让一个模型回答所有问题，而是让每类问题进入最适合的判断路径。

从案例抽象方法06THREE EVIDENCE TYPES

第三部分AI 代码审查平台

08 / 25

◆　◇　◆

第三部分

人工审查和传统 AI
为什么仍会漏问题？

接入模型可以很快，但没有确定性规则、正式知识与证据链，就难以成为稳定门禁。

AI 代码审查平台08部门宣导培训

传统方式人工代码审查为什么仍会漏问题

08 / 24

缺少开发规范

大部分团队的代码审查停留在文档纸面上，成员之间口口相传。

人工评审受限

疲劳、无时间、主观偏见、认知局限，让审查质量随人和时段波动。

业务语义难判断

只看代码表面，难以识别业务背景、状态边界和服务职责。

问题无法沉淀

评论停在当前 MR（合并请求），误报、漏报和修复经验没有回到下一次审查。

人工检查有盲区，问题仍会从裂缝漏出

传统方式08

THE CONVENTIONAL AI LOOP传统 AI 代码审查是如何运行的

08 / 20

把 AI 当成一个“外接评审员”

从 webhook 到评论区，
一条直线。

它能快速生成意见，但判断路径通常是自由的：规则、业务知识与证据没有被拆开管理。

p-1 · DIFF → Prompt → LLM → Comment

01Webhook 触发 MR（合并请求）

02拼 DIFF 与提示词

03发送给 LLM 自由判断

04脚本写回评论区

传统流程08WEBHOOK → PROMPT → LLM

THE LIMIT传统AI代码审核的局限

09 / 20

生成评论，不等于会治理。

自由判断

同一个问题可能因上下文、提示词和模型状态不同而给出不同结论。

证据缺口

评论里有观点，却缺少规则版本、知识来源和可复核的检测证据。

经验不沉淀

一次 MR（合并请求）解决了一个问题，但下一次仍要重新提问、重新解释。

从“能说”到“能证”09SHIFT

第四部分AI 代码审查平台

10 / 25

◆　◆　◆

第四部分

从评论机器人到
质量治理平台

把确定性规则、业务知识与 Agent 方法组织成一条可追踪的审查链路。

规则可执行

知识可引用

方法可复用

AI 代码审查平台10部门宣导培训

平台能力平台由哪些能力共同组成

11 / 20

从配置、执行到沉淀，能力彼此咬合

接入层

GitLab MR（合并请求）、Webhook、状态与评论。

执行层

规则检测器、项目模型与智能体。

资产层

规则、知识库、Skill 与版本证据。

工作台

仪表盘、模型配置与审查详情。

反馈层

线上意见回流为质量资产。

可追溯性

结论能回到代码、知识与过程。

平台地图11CONFIGURE · RUN · LEARN

第五部分AI 代码审查平台

14 / 25

◆　◇　◆

第五部分

一次 MR 如何成为
可追溯的审查链路？

规则检测始终先行；需要时，再增加模型或智能体审查，结论给回到开发人员。

AI 代码审查平台14部门宣导培训

一次 MR（合并请求）一次 MR（合并请求）在平台中如何被审查

12 / 20

p-2 · 当前平台执行一次 MR（合并请求）流程

从触发到复核，形成审查闭环

01MR（合并请求）触发获取仓库、分支与 DIFF

02规则检测器先行确定性规则直接判断

03按模式补充模型或智能体深审

04平台汇总结果评分、问题、证据与修复建议

05回写 GitLabCommit Status、汇总评论和行级评论

06审核人员复核正确、误报或漏检反馈

平台流程12MR（合并请求） → 规则检测器 → 审查

审查方式规则检测先行，再按需加深审查

14 / 20

每一类审查都先做规则检测，不需要配置 LLM

仅规则检测

只运行规则卡片检测器，无需配置 LLM。适合禁用 API、引用方式、结构性约束，稳定、快速、可门禁。

无需 LLM / 正则 / 代码模式 / 结构分析

快速审查

先做规则检测；已有知识库作为上下文，又希望以较低延迟得到评审结果时使用。

规则检测 + 知识库 + LLM

智能体深度审查

先做规则检测；有业务知识库、业务语义复杂，并需要配合审查 Skill 推理时使用。

规则检测 + 知识库 + Skill + 智能体

审查方式14RULES FIRST · THEN DEPTH

反馈闭环审查结果如何回到开发人员

15 / 24

不离开 GitLab，问题就有闭环

状态先给结论，
评论再给证据。

01Commit Status 提供门禁信号
02汇总评论帮助快速浏览
03行级评论把问题定位到具体代码与替代方案

开发人员看到的不是一段泛泛而谈的报告，而是可以直接处理的下一步动作。

审查结果如何回到开发现场

反馈闭环13STATUS · SUMMARY · LINE

第六部分AI 代码审查平台

18 / 25

◆　◇　◆

第六部分

规则、知识库审查Skill
共同构成质量资产

代码规则定义什么不能做，知识库辅助代码修改方向，审查 Skill 规定 Agent 如何分析。

AI 代码审查平台18部门宣导培训

质量资产一规则卡片：把规范变成可执行资产

15 / 20

把团队经验编译成可执行规则

可复用、可导入、
可版本化的规则包。

RuleCard 包含规则定义、检测器、适用范围、严重级别和正反例；它只做确定性判断。

cr-rule-author Skill
把规范描述、代码审查发现或线上故障复盘，转化为包含检测器和正反例的规则卡片。

148 条自建数 Java 开发规范 · 支持产品线自定义扩展

质量资产一15WHAT IS NOT ALLOWED

质量资产一 · 执行引擎规则检测器：规则检测不依赖模型

16 / 20

确定性，先于解释性

规则层不接入任何模型。

能用正则表达式解决的，不用猜；能用代码模式匹配解决的，不交给生成式判断；需要关系分析时，用代码结构与数据流分析。

正则表达式

文本与引用

精确捕捉禁用类、包名与固定模式。

代码模式匹配

代码结构

匹配调用、条件、返回值等代码形状。

结构与数据流

关系与路径

识别循环体与 IO 调用关系。

证据回写

稳定回写

直接产出可定位、可复核的代码证据。

p-7 · 规则检测器直接产出确定性证据

质量资产一 · 执行引擎16NO MODEL IN RULE DETECTION

质量资产二知识库：让修改方向不走偏

17 / 20

p-9 · 知识库管理与快照

规则归规则，知识归知识

知识库不是
文档堆放区。

规则卡片解决“代码怎么写才合规”；知识库沉淀业务知识、边界和背景，帮助审查判断 MR（合并请求）的修改方向有没有走偏。

审查效果，很大程度取决于知识库质量。
业务知识库不应混入代码规范；代码规范应尽量抽离成规则。

代码规范

禁用 API、引用方式、结构约束
→ 抽离为规则卡片

业务知识

业务边界、背景与正式事实
→ 结构化、向量化后使用

文档堆砌

设计、需求文档未经整理
→ 噪声增加，审查更差

质量资产二17WHAT IS CORRECT

QUALITY ASSET 03审查 Skill：让 Agent 按方法工作

18 / 20

Agent 应如何分析

Skill 不是提示词装饰，
而是审查方法。

它规定上下文读取顺序、关注的风险维度、证据引用方式、结论格式与停止条件，让 Codex / Qoder Agent 的深度审查可复用。

01读什么DIFF、仓库与知识

02怎么看按领域路径推理

03怎么证引用证据与位置

p-11 · 审查 Skill 管理

质量资产三18HOW THE AGENT WORKS

第七部分AI 代码审查平台

23 / 25

◆　◇　◆

第七部分

为什么审查结论
可信、可复核？

每条审查结论都有规则版本、检测位置、知识证据与审查过程，才值得进入团队质量闭环。

AI 代码审查平台23部门宣导培训

可信设计为什么审查结论可信、可复核

23 / 24

可信不是一句“模型很聪明”，而是四份可以回看的证据

从规则加载、命中结果、知识引用，到完整审查详情，每个结论都有对应的过程记录。

01规则有版本

知道哪一版规则卡片触发了结论。

已加载的规则清单

02检测有证据

知道哪一行、哪一种规则检测器发现了问题。

规则命中与检测结果

03知识可引用

业务判断能回到正式知识与快照。

知识库引用证据

04过程可回看

审查详情保留模式、模型、Skill 与结果。

审查详情与过程记录

可信机制19VERSION · EVIDENCE · TRACE

收束让经验成为系统能力

20 / 25

◆　◇　◆

让每一次审查都成为组织记忆

让经验
可执行，让结论
可复核。

下一次代码审查，不从“谁记得这条规范”开始，
而从平台已经沉淀的质量资产开始。

AI 代码审查平台20部门宣导培训

AI 代码审查从一次 MR开始

从三类真实问题看见审查盲区

禁止的 import，必须在 MR 里被指出。

循环体内禁止调用 IO

“拼接摘要”不能精确找人。

同在代码里，判断依据却并不相同。

代码规范

结构与性能

业务语义

人工审查和传统 AI为什么仍会漏问题？

从 webhook 到评论区，一条直线。

从评论机器人到质量治理平台

一次 MR 如何成为可追溯的审查链路？

状态先给结论，评论再给证据。

规则、知识库 审查Skill共同构成质量资产

可复用、可导入、可版本化的规则包。

规则层不接入任何模型。

知识库不是文档堆放区。

Skill 不是提示词装饰，而是审查方法。

为什么审查结论可信、可复核？

让经验可执行，让结论可复核。

AI 代码审查
从一次 MR开始

从三类真实问题
看见审查盲区

禁止的 import，
必须在 MR 里被指出。

“拼接摘要”
不能精确找人。

同在代码里，
判断依据却并不相同。

人工审查和传统 AI
为什么仍会漏问题？

从 webhook 到评论区，
一条直线。

从评论机器人到
质量治理平台

一次 MR 如何成为
可追溯的审查链路？

状态先给结论，
评论再给证据。

规则、知识库审查Skill
共同构成质量资产

可复用、可导入、
可版本化的规则包。

知识库不是
文档堆放区。

Skill 不是提示词装饰，
而是审查方法。

为什么审查结论
可信、可复核？

让经验
可执行，让结论
可复核。