年初，随着 DeepSeek 的爆火出圈，相信大家一定脑暴过各种利用 LLM 的创新应用场景。
在这场技术浪潮中，我们团队内部也在积极规划探索 AI 能在现有研发流程中带来哪些助力，但同时考虑到目前行业飞速进化的趋势，大致明确了几个探索原则：
? 核心原则
快速行动，持续验证：做思想上的巨人，行动上的实践者，有想法就积极行动尝试； 注重投入产出比：中小型公司不要去卷底层技术和平台建设，最好根据现有资源快速整合； 关注结果，更关注过程：持续的学习，沉淀探索过程；
基于以上原则，在寻找具体切入点时，我们注意到团队内部长期以来对代码审查（CR）的规范统一性、审查深度及人力投入等方面存在改进的呼声。鉴于此，我们决定尝试利用 AI，探索优化代码审查流程的潜力，期望在提升 CR 效率和质量的同时，也能在实践中积累 AI 应用经验。
简而言之：我们希望通过 小成本投入 的方式，利用 AI 技术优化 CR 流程并能有所沉淀。
? 项目进展与成果
? 整体流程
? 开发历程
基础功能搭建（可用阶段）：
完成改动内容处理 -> AI CR-> 评论反馈流程投入： 3人日流程调优优化（提升阶段）：
优化用户体验和系统响应 投入： 5-7人日提示词工程优化（深化阶段）：
提高AI分析质量和准确度 状态：进行中
? 使用数据
64个 | |
150+ | |
2%（目前偏低但结合差评率，说明用户对 AI 审查结果的默认接受度尚可） | |
4% |
? 产品演进历程
关于 CR 环节的现状问题，主要是规范统一、精力投入、审查力度上，此处不再赘述。主要还原一下项目的历程，侧重问题解决和过程思考。
?️ 0.1 版本：探索验证（MVP）
在初始阶段，我们首先构想如何将 AI CR 无缝集成到现有开发流程中。当时考虑了以下几个方案：
| 独立平台方案 | CR 通过该平台进行 | |
| 报告输出方案 | MR 后为开发者提供一份 AI 审计报告 | |
| 行级评论方案 | MR 界面上提供行级别的 AI 评论 |
经过评估，最终选择了行级评论方案，该方案能够提供细粒度的代码反馈，同时保持开发人员熟悉的工作流程，避免多平台切换。
基本流程：
用户提 MR → 调用 LLM → 写入 MR 评论
? 关键环节拆解
MR 事件捕获与内容解析
首先需要解决 MR 事件通知与内容获取的问题。幸运的是，GitLab 提供了完善的 API 和 webhook 机制：
MR 事件通知： webhook配置Merge Request EventMR 内容获取： /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 处提供评论
基于上述实现，第一个版本已经可以投入使用。接入非常简单：
在目标仓库中配置 webhook配置完成后，每次提交 MR 时系统自动调用 LLM分析AI评论将直接显示在MR界面上
效果如下：
?️ 0.2 版本：迭代优化
? 问题发现与分析
0.1 版本如期上线，但正如快速迭代理念所预期的，问题也随之而来。我们迅速发现了以下核心问题：
| 过度评论 | |
| 质量不足 | |
| 无反馈机制 | |
| 规则单一 |
? 解决方案
减少干扰评论
问题根源：
GitLab MR的webhook在MR有任何修改时都会触发（包括修改描述、提交新commit、关闭、合并）评论分级（ High、Medium、Low）全量输出，导致不重要问题也被显示
解决措施：
? 只处理首次提 MR时的全量改动，后续commit支持增量CR
// action 枚举，只需要处理 open 和 update 并且实际有commit提交的 操作
const actionEnum = ['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：样式问题/不影响功能
提升评论质量
问题根源：
上下文信息有限，目前只提供了行改动相关内容 单轮 AI分析缺乏自我验证和纠错能力
上下文优化： 提示词中携带更丰富的上下文信息
由当前 改动行上下文 → 当前文件改动完整上下文
多轮 LLM 分析： LLM 评论流程增加多轮校验，渐进式深度分析
第一轮：初步识别问题 第二轮：审查第一轮结果，结合上下文再次分析 第三轮：对前两轮结果进行汇总与优化
主要目的：
减少误判率 通过多轮验证，可以发现并纠正因缺乏上下文导致的错误判断第二轮专门验证第一轮评论的合理性，明确标记有效/无效/部分有效，最终结果优先采用经过验证的评论，提高准确性 上下文理解更加全面 第一轮主要关注改动点本身 第二轮引入项目结构、依赖关系等更广泛上下文 第三轮综合考虑所有因素，确保评论与整体架构一致
同时将 Aily 整体编排流程拆分，将提示词定义为以下部分：
提示词角色： PromptRole（按MR内容动态生成）提示词业务规则： PromptBizRules（按MR内容动态获取对应业务审查规则）提示词输入格式：固定（不可修改） PromptInputFormat审查维度和评判标准： PromptReviewDetails（按MR内容动态获取对应业务审查规则）提示词输出格式：固定（不可修改） PromptOutputFormat提示词输出规则：（可重新定义或者不用） PromptOutputRules
具体设置：
完整编排流程：
建立反馈机制
解决措施：
✨ 增加优化脚本，支持在 AI评论处提供一键反馈功能✨ 所有评论内容及反馈记录，用于 AI评论调优
业务定制能力
拓展现有编排流程，将业务规范开放到多维表格，用飞书文档来沉淀业务生成规范和定制化的审查规则。
解决措施：
?️ 利用飞书多维表格各接入应用的规范手册及配置，实现应用审查规范统一 ?️ 通过 Aily平台根据业务规范动态合成提示词?️ 为不同业务场景定制化 AI审查标准
? 展望与总结
✅ 成果回顾
经过两个版本的快速迭代，我们成功实现了最初的目标：以小成本投入优化代码审查流程。具体表现在：
投入产出比高：总计约 10人日投入，实现了64个应用的接入，日均150+评论，已发现50+有效问题流程无缝集成：通过选择行级评论方案，AI审查自然融入现有开发流程 迭代速度快：从问题发现到解决方案部署，保持了快速响应节奏 持续优化：基于用户反馈不断调整，形成了良性迭代循环
? 关键经验
务实为先：选择"拿来主义"而非重复造轮子，利用现有资源（ GitLab API、飞书Aily等）快速构建小步快跑：先求可用，后求好用， MVP思想贯穿整个开发过程重视反馈：构建反馈渠道，及时收集用户意见并转化为改进点 精细化定制：认识到不同业务场景的差异性，提供定制化方案
? 未来方向
经过对业界主流AI CR实现方案的全面调研（如腾讯AICR、字节跳动BitsAI-CR等），我们对未来方向有了更加务实的认识：
轻量化路线
我们发现，要构建一个企业级完整的AI CR系统需要大量资源投入：
需要专业团队构建复杂的模型训练与微调流程 需要建立完善的知识库管理机制 需要设计全面的数据飞轮生态系统
对于中小团队而言，投入大量资源去构建类似腾讯、字节等大厂的全面系统性价比不高。我们更倾向于：
在现有基础上持续改进，而非追求完美的端到端解决方案 聚焦于提示词工程和上下文优化，这是成本最低、收益最高的优化点 与现有开发工具生态共存互补，而非重复造轮子
AI CR 定位
我们观察到目前AI CR可能的定位：
辅助人工CR：提供初步筛查，发现明显问题，减轻人工负担 替代人工CR：完全自动化代码审查，取代大部分人工环节
我们认为，在当前阶段， 辅助人工CR 是更务实的定位，理由是：
模型能力有限，完全替代人工 CR仍有较大缺口辅助定位下，即使有错误评论，开发者可以轻松忽略 人机协作模式更适合当前团队文化与工作流程
技术迭代与工具生态融合
我们注意到底层能力迭代非常快速：
各大 IDE（如Cursor 0.49版本）已开始内置代码审查功能OpenAI、Anthropic等不断推出更强大的编程辅助功能开源模型性能持续提升，使用门槛不断降低
因此，我们计划：
保持现有系统的灵活性，能够方便集成新兴技术 更多关注如何与现有工具生态（如 IDE插件）协同合作探索特定场景下的定制化能力，如业务规范的自动检查
? 结语
AI辅助代码审查是AI融入开发流程的一个切入点，但绝非终点。通过这个项目，我们不仅验证了AI在特定场景下的实用价值，更积累了宝贵的实践经验。正如我们的核心原则所示，技术发展迭代太快，重要的是保持行动力，不断尝试，在实践中找到最适合自己团队的应用方式。
在未来，我们将继续秉持"小投入、快迭代、重实效"的理念，探索AI与研发流程深度融合的更多可能性。
