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