Code Review 遇到的挑战
对于核心的业务项目来说，Code Review (代码评审) 是必不可少的。但现实中的代码评审时常常被以下几件事所困扰：
- 类似的 Bug 出现过，复盘文档也有，然而新人不知道，老人记不清
因此，我们希望打造一个有记忆、懂业务、还看过你们线上事故的评审的 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;
}
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);
实践反馈
该审核工具自上线以来，作为内部的 Code Review 工具，经过一段时间的推广与迭代，在多个部门中的使用并得到很好的反馈。
核心业务深度实践
审核工具目前已在内部核心业务大组中完成深度落地。通过对底层服务及复杂业务中台等多种场景的覆盖，其实战价值得到了充分验证
全流程质量守卫： 系统已平稳运行于多个核心项目，确保每一行代码变更在合入主干前，都能经过知识库的逻辑校准。
馈驱动进化 ：凭借基于业务上下文的风险预警能力，工具在团队内部获得了积极的反馈。
老事故的复发率明显下降
历史复盘文档的命中为参与评审的开发者提供了极其重要的上下文。它告诉评审者：“当前代码与历史某次事故的逻辑模式相似度达 85%，请重点关注。” 这种的提醒，极大缩小了人工审计的盲区。
未来规划
结合用户的使用与反馈，目前主要存在以下待解决的问题，也是后续的优化方向
RAG 召回的 “噪音” 与 “幻觉”
由于代码的逻辑复杂性，单纯的语义向量检索有时会召回一些 “似是而非” 的历史案例。如果注入了无关的知识，模型可能会产生幻觉，输出一些与代码无关的建议，导致 “误报”。
优化方向：
筛选相似度高的案例：过滤一些相似度低于 0.85 的案例，剩余命中的案例进入最终的环节，从而将干扰降至最低
构建知识库的 ‘反馈学习链路’。当审核给出建议后，如果开发者标记为 ‘误报’，系统将自动根据反馈进行微调检索策略。
如何做到可以一键采用建议
目前生成的建议是放在报告中的，无法让评审人员可以一键采用，还有生成的建议代码可能不是很完善
优化方向：
- 调优模型，给出直接可运行的修复代码，或者给出 2+种不同方式处理的代码，供使用者选择。
与 cursor 相结合
我们将进一步强化与 Cursor 的原生集成，借助 Cursor CLI 实现本地与审核工具结合，将审计反馈直接嵌入编辑器内侧边栏，用户可一键采纳和修复。
与发布平台相结合
增加发布卡点校验：将审核工具的审计结果作为发布流水线的标准条件。
结语
AI 的能力不仅仅是局限于代码生成，我们希望把它视为一个有经验，懂业务的好搭档。我们做的事情，本质上就是：把团队踩过的坑，变成模型的直觉。
粤ICP备14082021号
免费POC，
零成本试错
