初衷
年初，随着DeepSeek的爆火出圈，相信大家一定脑暴过各种利用LLM的创新应用场景。
在这场技术浪潮中，我们团队内部也在积极规划探索AI能在现有研发流程中带来哪些助力，但同时考虑到目前行业飞速进化的趋势，大致明确了几个探索原则：
? 核心原则
- 快速行动，持续验证：做思想上的巨人，行动上的实践者，有想法就积极行动尝试；
- 注重投入产出比：中小型公司不要去卷底层技术和平台建设，最好根据现有资源快速整合；
基于以上原则，在寻找具体切入点时，我们注意到团队内部长期以来对代码审查（CR）的规范统一性、审查深度及人力投入等方面存在改进的呼声。鉴于此，我们决定尝试利用AI，探索优化代码审查流程的潜力，期望在提升CR效率和质量的同时，也能在实践中积累AI应用经验。
简而言之：我们希望通过 小成本投入 的方式，利用AI技术优化CR流程并能有所沉淀。
? 项目进展与成果
? 整体流程
? 开发历程
- 完成改动内容处理 ->
AI CR-> 评论反馈流程
? 使用数据
| |
|---|
| 64个 |
| 150+ |
| 2%（目前偏低但结合差评率，说明用户对 AI 审查结果的默认接受度尚可） |
| 4% |
? 产品演进历程
关于CR环节的现状问题，主要是规范统一、精力投入、审查力度上，此处不再赘述。主要还原一下项目的历程，侧重问题解决和过程思考。
?️ 0.1 版本：探索验证（MVP）
在初始阶段，我们首先构想如何将AI CR无缝集成到现有开发流程中。当时考虑了以下几个方案：
| | |
|---|
| 独立平台方案 | | ❌ 成本过高，与低投入初衷冲突，初次构建及后续维护成本均较大 |
| 报告输出方案 | | |
| 行级评论方案 | | ✅ 目前看最合适，用户体验友好，集成度高，但同时存在上下文不足问题 |
经过评估，最终选择了行级评论方案，该方案能够提供细粒度的代码反馈，同时保持开发人员熟悉的工作流程，避免多平台切换。
基本流程：
用户提 MR → 调用 LLM → 写入 MR 评论
? 关键环节拆解
MR 事件捕获与内容解析
首先需要解决MR事件通知与内容获取的问题。幸运的是，GitLab提供了完善的API和webhook机制：
- MR 事件通知：
webhook配置Merge Request Event - MR 内容获取：
/projects/${id}/merge_requests/${mrId}/changes
获取到对应的diff内容后，我们将其解析成包含行号、改动内容等的结构化数据，使LLM能更好地理解上下文。
? 为什么需要将diff结构化？
经过上述接口，我们能拿到实际的diff内容。虽然这部分内容可以直接提供给LLM处理，但会存在明显的不确定性：
@@ -1,7 +1,7 @@
class User {
- constructor(name, age) {
+ constructor(name, age, role) {
this.name = name;
this.age = age;
+ this.role = role;
}
}
将上述diff直接提供给LLM会导致无法明确确定需要评论的行。通过结构化数据处理，我们能够明确改动对应的新旧文件行数以及相关上下文，提高 AI 分析的准确性。
{
"file_meta": {
"path":"当前文件路径",
"old_path":"原文件路径（重命名时存在）",
"lines_changed":"变更行数统计",
},
"changes": [
{
"type":"变更类型（add/delete）",
"old_line":"原文件行号（删除时存在）",
"new_line":"新文件行号（新增时存在）",
"content":"变更内容",
"context": {
"old":"当前改动上下文",
"new":"当前改动上下文"
}
}
]
}
LLM 调用与评论写入
上述已经完成了改动内容的结构化封装，接下来需要将这部分内容拼接到对应的提示词，调用大模型来生成评论。LLM调用是核心环节，我们综合考虑成本因素，决定使用公司内部已有的飞书 Aily 平台。
- （
Aily）是一款全新的企业级智能应用开发平台，围绕着大语言模型（LLM）提供AI技能编排、知识数据处理、效果调优和持续运营能力，让用户可以高效的开发出专业的企业级智能应用，并一键发布到飞书、Web等多个渠道，与企业业务系统深度集成，提升企业内部业务流转和客户服务效率。
所以这部分工作，主要变成了基于Aily的流程编排和提示词调试（完整编排流程在下方）。
提示词设置原则：
结构如下：
# 角色
你是专业的审查专家xxxx
# 审查维度及判断标准（按优先级排序）
xxx
# 输入数据格式
输入结构如下：
{
"file_meta": {
"path":"当前文件路径",
"old_path":"原文件路径（重命名时存在）",
"lines_changed":"变更行数统计",
"context": {
"old":"原文件上下文",
"new":"新文件上下文"
}
},
"changes": [
{
"type":"变更类型（add/delete）",
"old_line":"原文件行号（删除时存在）",
"new_line":"新文件行号（新增时存在）",
"content":"变更内容"
}
]
}
其中：
- old_line：content 在原文件中的行号，为null表示新增
- new_line：content 在新文件中的行号，为null表示删除
- content：新增或删除的行内容
# 输出格式
1.格式为：
[{"file":"文件路径","lines":{"old":"原文件行号（删除时存在）","new":"新文件行号（新增时存在）"},"category":"问题分类","severity":"严重程度（critical/high/medium/low）","analysis":"结合上下文的具体技术分析（200字内）","suggestion":"可执行的改进建议（含代码示例）"}]
需要注意行号处理：
- 新增内容：`lines.old=null`,`lines.new=变更的new_line`
- 删除内容：`lines.old=变更的old_line`,`lines.new=null`
- 行号必须精确到具体变更行
2.输出格式为JSON字符串数组，内部结构必须完整，必须是完整且合法的json格式，除此之外不要输出多余内容
以上提示词的设计配合结构化的输出，能让AI生成的评论的准确性在95%以上（这里的准确性指的是精准评论到具体的代码行，不包括实际评论内容的准确性），同时生成结构化的评论内容，方便解析和使用。
而评论写入直接采用GitLab提供的API写入即可：
- 评论内容：
/projects/${id}/merge_requests/${mrId}/discussions
完整处理流程
用户提交 MR → webhooks 通知内部应用 → 解析diff内容 → 调用 aily 能力 → 生成 Prompt → LLM 分析 → 结构化LLM评论 结果 → 在原 MR 处提供评论
基于上述实现，第一个版本已经可以投入使用。接入非常简单：
- 配置完成后，每次提交 MR 时系统自动调用
LLM分析
效果如下：
?️ 0.2 版本：迭代优化
? 问题发现与分析
0.1 版本如期上线，但正如快速迭代理念所预期的，问题也随之而来。我们迅速发现了以下核心问题：
? 解决方案
减少干扰评论
问题根源：
GitLab MR的webhook在MR有任何修改时都会触发（包括修改描述、提交新commit、关闭、合并）- 评论分级（
High、Medium、Low）全量输出，导致不重要问题也被显示
解决措施：
- ? 只处理首次提
MR时的全量改动，后续commit支持增量CR
// action 枚举，只需要处理 open 和 update 并且实际有commit提交的 操作
constactionEnum = ['open','update','close','reopen','merge','unmerge','approved','unapproved'];
// base_sha, start_sha, head_sha 需要从 mrChangeInfo 是为了后续 comment 的时候，使用正确的 diff 信息
{
base_sha: mrChangeInfo.data.diff_refs.base_sha,
start_sha: mrChangeInfo.data.diff_refs.start_sha,
head_sha: mrChangeInfo.data.diff_refs.head_sha,
}
- ? 评论筛选机制，仅输出 High 及以上的改动评论
# 输出要求
1.严重程度标准：
- Critical：导致系统崩溃/数据损坏
- High：功能异常/安全漏洞
- Medium：潜在风险/代码异味
- Low：样式问题/不影响功能
提升评论质量
问题根源：
上下文优化： 提示词中携带更丰富的上下文信息
- 由当前 改动行上下文 → 当前文件改动完整上下文
多轮LLM分析： LLM 评论流程增加多轮校验，渐进式深度分析
主要目的：
- 通过多轮验证，可以发现并纠正因缺乏上下文导致的错误判断第二轮专门验证第一轮评论的合理性，明确标记有效/无效/部分有效，最终结果优先采用经过验证的评论，提高准确性
同时将Aily整体编排流程拆分，将提示词定义为以下部分：
- 提示词角色：
PromptRole（按MR内容动态生成） - 提示词业务规则：
PromptBizRules（按MR内容动态获取对应业务审查规则） - 提示词输入格式：固定（不可修改）
PromptInputFormat - 审查维度和评判标准：
PromptReviewDetails（按MR内容动态获取对应业务审查规则） - 提示词输出格式：固定（不可修改）
PromptOutputFormat - 提示词输出规则：（可重新定义或者不用）
PromptOutputRules
具体设置：
完整编排流程：
建立反馈机制
解决措施：
- ✨ 增加优化脚本，支持在
AI评论处提供一键反馈功能
业务定制能力
拓展现有编排流程，将业务规范开放到多维表格，用飞书文档来沉淀业务生成规范和定制化的审查规则。
解决措施：
- ?️ 利用飞书多维表格各接入应用的规范手册及配置，实现应用审查规范统一
? 展望与总结
✅ 成果回顾
经过两个版本的快速迭代，我们成功实现了最初的目标：以小成本投入优化代码审查流程。具体表现在：
- 投入产出比高：总计约
10人日投入，实现了64个应用的接入，日均150+评论，已发现50+有效问题 - 流程无缝集成：通过选择行级评论方案，AI审查自然融入现有开发流程
- 迭代速度快：从问题发现到解决方案部署，保持了快速响应节奏
- 持续优化：基于用户反馈不断调整，形成了良性迭代循环
? 关键经验
- 务实为先：选择"拿来主义"而非重复造轮子，利用现有资源（
GitLab API、飞书Aily等）快速构建 - 小步快跑：先求可用，后求好用，
MVP思想贯穿整个开发过程 - 重视反馈：构建反馈渠道，及时收集用户意见并转化为改进点
- 精细化定制：认识到不同业务场景的差异性，提供定制化方案
? 未来方向
经过对业界主流AI CR实现方案的全面调研（如腾讯AICR、字节跳动BitsAI-CR等），我们对未来方向有了更加务实的认识：
轻量化路线
我们发现，要构建一个企业级完整的AI CR系统需要大量资源投入：
对于中小团队而言，投入大量资源去构建类似腾讯、字节等大厂的全面系统性价比不高。我们更倾向于：
- 在现有基础上持续改进，而非追求完美的端到端解决方案
- 聚焦于提示词工程和上下文优化，这是成本最低、收益最高的优化点
AI CR 定位
我们观察到目前AI CR可能的定位：
- 辅助人工CR：提供初步筛查，发现明显问题，减轻人工负担
- 替代人工CR：完全自动化代码审查，取代大部分人工环节
我们认为，在当前阶段， 辅助人工CR是更务实的定位，理由是：
技术迭代与工具生态融合
我们注意到底层能力迭代非常快速：
- 各大
IDE（如Cursor 0.49版本）已开始内置代码审查功能 OpenAI、Anthropic等不断推出更强大的编程辅助功能
因此，我们计划：
- 更多关注如何与现有工具生态（如
IDE插件）协同合作
? 结语
AI辅助代码审查是AI融入开发流程的一个切入点，但绝非终点。通过这个项目，我们不仅验证了AI在特定场景下的实用价值，更积累了宝贵的实践经验。正如我们的核心原则所示，技术发展迭代太快，重要的是保持行动力，不断尝试，在实践中找到最适合自己团队的应用方式。
在未来，我们将继续秉持"小投入、快迭代、重实效"的理念，探索AI与研发流程深度融合的更多可能性。
