我要投稿

如何用 AI 做业务级 Code Review

发布日期：2026-02-27 14:50:22 浏览次数： 1551

作者：货拉拉技术

微信搜一搜，关注“货拉拉技术”

Code Review 遇到的挑战

对于核心的业务项目来说，Code Review (代码评审) 是必不可少的。但现实中的代码评审时常常被以下几件事所困扰：

Diff 太多，看不过来开
类似的 Bug 出现过，复盘文档也有，然而新人不知道，老人记不清
AI 不懂业务，不能给出实质性的建议

因此，我们希望打造一个有记忆、懂业务、还看过你们线上事故的评审的 AI 助手，让它帮我们守最后一道门。

核心链路：从 git push 开始

整个流程可以大致分为以下几步

流程图示意图

触发机制

“触发机制的选择” 其实是个产品问题：什么时候介入，才不打扰人？ 我们最后选的是 GitLab Webhook 的事件驱动模式。开发者无需安装插件，也无需在本地执行脚本，只需按照往常一样进行 push 代码即可。

接入成本极低： 在 GitLab 项目或组织级别的 Webhook 配置中，只需勾选 Push events 和 Merge request events，并填入审核工具的统一回调地址。
多场景触发 ：

代码驱动 ：当发起目标为主分支的 MR，或已有的 MR 分支发生增量提交时，系统将即时开启审计。
工程管控 ：深度集成公司构建平台，支持通过构建 Hook 配置，针对特定业务分支在构建环节手动或自动触发评审任务。

Diff 的深度预处理与语义重塑

当 Webhook 触发后，审核工具接收到的是一段包含 + 和 - 符号的原始 Diff 文本。原始 Diff 文本包含大量冗余符号和非逻辑变更。如果直接投喂给模型，不仅消耗 Token，还会导致模型注意力分散。

我们设计了一套预处理流水线：

特征过滤 ：自动剔除 .lock、.json、样式及静态资源文件。
切片化 Diff ：先按文件切，单文件过大时再按行数或 chunk 二次切分
深度提取： 通过接口获取当前变更的完整 Context，然后识别出哪些是逻辑改动，进行一层筛选，剔除干扰项
补全逻辑代码： 识别到逻辑改动，会将整个逻辑方法的原实现也会带过去
调用模型语义化重塑： 系统会将精简后的 Diff 提交给大模型，但此时并不要求模型直接进行审计，而是要求它完成一项任务：“告诉我这段代码在做什么？”
模型分析代码的改动意图： 为后面的知识库匹配和深度 Review 打下基础

基于 RAG 的 “经验召回” 引擎

如果说语义分析是审核工具的 “眼睛”，那么基于向量数据库的 RAG (Retrieval-Augmented Generation) 流程就是它的 “大脑经验”。

这一块分为两个模块，知识库的数字化与在线语义检索

知识库的数字化

文档来源： 历史事故复盘、通用工具库、最佳业务实践、特定项目技术文档
流程： 结构化 Chunk 切片 -> Embedding Model 向量化 -> 存入公司内部 AI 平台的向量数据库

我们使用公司内部 AI 平台的知识库搭建

如何使用

查询向量化： 系统将代码变更简要作为查询指令，同样经过 Embedding Model 转换为嵌入向量。
向量检索 (Vector Search)： 在向量空间中计算当前变更向量与数据库中知识向量的余弦相似度 (Cosine Similarity)，找出相关性最高的前 2 条上下文知识。
代码打标： 这段与历史问题相似的代码进行打标并将该知识点注入 Prompt

深度 Review 与报告通知

将原始 Diff、语义简要以及检索到的历史问题，融合成复杂的上下文包，进行最终的请求：

构建 Prompt： 将三者融合成一个复杂的上下文包，给到 LLM。
可视化报告与反馈： 最终将评审意见渲染成一个可视化报告，发送消息通知给到用户。

实践中遇到的问题

模型选型与持续进化

模型的选择永远没有最优解。以下三件事需要一直持续下去：

多维选型评分：借助公司的模型审核平台使用预设的案例检验各个模型，给模型进行打分，从而选择更好的模型。
闭环反馈：抽检 review 的结果，结合用户反馈与修正行为，对模型的输出进行持续评估。
动态调优： 定期检查模型版本，持续优化 Prompt 策略。

长 Diff 的上下文窗口优化

针对非核心文件筛选

删除文件过滤
扩展名过滤： 排除 .json，.png，.lock，.css，.scss，.less

优先级权重计算： 在审核服务中会有优先级的配置项

class DiffProcessor {
private readonly coreDirs: readonly string[] = [] asconst;
private readonly baseWeight = 1;
private pathWeightCache = new Map<string, number>();

// 根据路径和重要程度计算权重，优先处理核心逻辑
private calculateWeight(change: Change): number {
    // 权重计算逻辑...
  }
}

分片策略

先粗略估算 Token，当累计超过安全余量 (30000 tokens) 时创建新 Chunk。每个 Chunk 包含文件列表、变更元信息及平均权重。

// 将changes 进行切片化处理
private groupIntoChunks(changes: Change[]): Chunk[] {
    const chunks: Chunk[] = [];
    let currentChunk: ChunkData[] = [];
    if (currentChunk.length > 0) {
      chunks.push(this.createChunk(currentChunk));
    }
    return chunks;
  }

并发 API 调用

async processMR(params) {
  const processor = new DiffProcessor();
  const chunks = processor.processChanges(changes);
  try {
    // 并行处理所有 chunks，提升审计时效
    await Promise.all(chunks.map((chunk) => this.callAPI(params)));
  } catch (error) {
    // ...
  }
}

多 Chunk 报告整合

采用缓存机制处理异步结果：通过 reportStore 缓存各 Chunk 报告，利用 isAllChunksDone 进行校验，触发最终报告的聚合与推送。

const isAllChunksDone = (
  reportStore: StorageReport,
  report_id: string,
  chunksLen: number,
) => {
  const expected = reportStore[report_id]?.chunks.length || 0;
  return chunksLen === expected;
};

// 保存分块结果
reportStore[report_id].chunks.push(params);