AICR：AI Code Review 从 0 到 1 的真实演进路线

目标不是“让 AI 多提问题”，而是构建一个懂业务、懂项目、低成本、可闭环、能被研发真正采纳的代码审查体系。

一、AICR 的核心定位：不是替代人工，而是前置风险识别

AI Code Review 的价值不应仅仅是：

• 扫描语法问题；
• 生成泛泛而谈的建议；
• 对每个 Diff 都长篇评论；
• 替代资深工程师做最终把关。

更合理的定位是：

AI 负责高频、重复、上下文可检索的风险识别；
人负责业务权衡、架构判断和最终责任确认。

因此 AICR 的建设重点应从一开始就围绕四件事：

1. 让 AI 看懂需求和项目上下文；
2. 只审真正需要审的变更，不陷入全量代码幻觉；
3. 让建议少而精，能被研发采纳；
4. 接入 CI/CD，形成修复闭环。

二、整体演进路线：从 0 到 1 可以分四个阶段

阶段 0：单次 Diff 审查

最初版本通常是：

• 输入 Git Diff；
• 调用大模型；
• 输出 Review 建议。

优点是接入简单，成本低。

但问题非常明显：

• AI 不理解业务需求；
• 不理解项目规范；
• 对上下文缺失的代码容易幻觉；
• 审查建议泛泛而谈；
• 不知道历史上是否修过类似问题；
• 没有闭环，评论完就结束。

这只能作为 Demo，不能作为真实研发流程的主力。

阶段 1：Diff + 项目上下文

开始引入：

• 关联文件；
• 被调用函数；
• 数据结构；
• 配置文件；
• 测试文件；
• 项目规范；
• 历史相似代码；
• 业务领域文档。

此时 AI 不再只看一段孤立 Diff，而是基于变更周边上下文做判断。

阶段 2：Diff Review + Commit Trace

进一步引入：

• Commit 粒度追踪；
• PR/MR 维度聚合；
• 历史风险记录；
• 修复后再次检查；
• 防止修旧引新；
• 识别“同一问题是否已经解决”。

此时 AICR 从“提出建议”变成“跟踪问题”。

阶段 3：多 Agent 审查体系

单一模型容易出现两个问题：

• 什么都审，导致噪音大；
• 什么都说不深，导致建议没有价值。

因此需要多 Agent 分工：

• 需求理解 Agent；
• Diff 理解 Agent；
• 业务风险 Agent；
• 安全 Agent；
• 性能 Agent；
• 测试 Agent；
• 架构一致性 Agent；
• 规则收敛 Agent；
• 最终裁决 Agent。

但最终输出不能是一堆 Agent 的意见合集，而要经过收敛、去重、排序，形成少而精的 Review 结果。

阶段 4：融入 CI/CD 和研发流程

最终 AICR 应该进入真实工程流：

• PR/MR 创建时自动触发；
• 每次 Commit Push 自动增量审查；
• 结果回写到 GitLab/GitHub/Bitbucket；
• 严重问题阻断合并；
• 普通建议仅提醒；
• 修复后自动验证；
• 形成状态追踪；
• 统计采纳率、误报率、逃逸率。

这时 AICR 才真正从“AI 工具”变成“工程质量系统”。

三、问题一：如何让 AI 审查理解需求、项目意图，并减少 Diff 理解幻觉？

1. 不要只给 Diff，要构造“审查上下文包”

AI 对 Diff 产生幻觉，核心原因是输入信息不足。

一个可靠的 AICR 输入不应只是：

git diff

而应构造成一个 Review Context Package：

1. 本次需求/任务信息 2. PR/MR 标题和描述 3. 变更 Diff 4. 相关文件上下文 5. 被修改函数的完整定义 6. 被调用函数的定义或摘要 7. 数据结构、接口协议、枚举定义 8. 配置文件 9. 相关测试用例 10. 项目规范和历史约定 11. 相似历史变更 12. 本次变更的影响面分析

也就是说，AI 审查前要先做一层“上下文组装”。

2. 需求理解：从 Issue、PR 描述、需求文档中提取意图

AI 审查要理解项目意图，至少需要知道：

• 这次改动是为了修 Bug、做 Feature，还是重构；
• 需求的验收标准是什么；
• 哪些行为应该改变；
• 哪些行为不应该改变；
• 是否涉及兼容性；
• 是否涉及安全、权限、计费、数据一致性等高风险领域。

可以设计一个需求理解 Agent，输出结构化内容：

{"change_type":"bugfix","business_goal":"修复订单超时状态未正确更新的问题","expected_behavior":["订单超过 30 分钟未支付时应变为 EXPIRED","已支付订单不应被修改"],"risk_points":["订单状态机一致性","并发更新","重复任务执行","幂等性"],"acceptance_criteria":["新增或更新对应单元测试","不影响已支付订单状态"]}

后续 Review 都基于这个结构化意图进行，而不是让模型凭空猜测。

3. Diff 理解：先生成变更摘要，再进行审查

不要直接让模型对 Diff 提建议。

推荐流程是：

Diff → 变更摘要 → 影响面分析 → 风险点识别 → Review 建议

例如先让 AI 输出：

本次变更： 1. 修改了订单超时任务的状态判断逻辑； 2. 将 pending 状态判断从 `status != PAID` 改为 `status == PENDING`； 3. 新增了订单超时的单元测试； 4. 未修改支付回调逻辑。

然后再让审查 Agent 基于该摘要判断。

这样可以减少直接基于代码片段的误读。

4. 使用代码索引和调用图降低幻觉

仅依赖大模型上下文窗口是不够的。

需要构建项目级代码索引：

• 文件索引；
• 符号索引；
• 函数/类定义；
• 调用关系；
• 依赖关系；
• API 路由；
• 数据表结构；
• 配置项；
• 测试用例映射。

当 Diff 修改某个函数时，可以自动检索：

• 该函数被谁调用；
• 它调用了谁；
• 是否被测试覆盖；
• 是否涉及公共 API；
• 是否影响数据库字段；
• 是否涉及鉴权、事务、缓存、消息队列。

这类上下文远比“把整个仓库塞给模型”更可靠。

5. 限制 AI 的判断边界

为了减少幻觉，Prompt 中要强制 AI 区分：

• 已确认问题；
• 高风险疑点；
• 需要人工确认；
• 仅优化建议；
• 无足够上下文，不能判断。

例如要求输出：

结论必须基于 Diff 或上下文证据。 如果证据不足，必须说明“无法确认”，不得臆测。 每条建议必须引用具体代码位置和依据。

Review 建议可以分级：

BLOCKER：确定会导致严重错误，建议阻断合并 MAJOR：高概率风险，应优先修复 MINOR：可读性、维护性问题 QUESTION：上下文不足，需要作者确认

四、问题二：如何做到“审查看 Diff，追踪看 Commit”，低成本防止修旧引新？

这句话非常关键：

审查看 Diff，追踪看 Commit。

含义是：

• Review 阶段主要看本次变更的 Diff；
• 追踪阶段要看 Commit 历史和问题演进。

1. 为什么审查不应该全量看代码？

如果每次 Review 都全量扫描项目，会有几个问题：

• 成本高；
• 噪音大；
• 大量历史问题干扰本次变更；
• 研发不愿意处理“不是我引入的问题”；
• AI 上下文过大，幻觉更严重。

因此 Review 应聚焦：

本次 Diff 直接引入或暴露的问题。

2. Commit Trace 的核心作用

Commit Trace 不是为了让 AI 读所有历史代码，而是回答几个问题：

1. 这个问题是不是本次 Commit 引入的？
2. 这个问题之前是否已经存在？
3. 上一次 Review 提的问题是否被修复？
4. 本次修复是否引入了新的风险？
5. 多个 Commit 中，问题状态如何变化？

3. 为每条 AI Review 建立唯一 Issue ID

AI 发现问题后，不应只是发一条评论，而应结构化记录：

{"issue_id":"AICR-20250101-0001","repo":"order-service","pr_id":"123","commit_sha":"abc123","file":"src/order/timeout.go","line_range":"45-56","severity":"MAJOR","category":"business_logic","title":"已支付订单可能被超时任务错误关闭","evidence":"Diff 将状态判断改为 status != CANCELED，可能包含 PAID 状态","status":"open","fingerprint":"hash(rule + code_context + semantic_summary)"}

其中最重要的是：

fingerprint

它用于判断后续 Commit 中：

• 该问题是否仍然存在；
• 是否被修复；
• 是否变成了另一个问题；
• 是否只是行号变化。

4. 每次 Commit Push 后做增量追踪

例如一个 PR 中有多个 Commit：

C1：引入功能 C2：修复 AI 提出的状态判断问题 C3：补测试 C4：重构代码

AICR 应该在每次 Push 后做：

1. 新 Diff 审查； 2. 历史问题状态刷新； 3. 已修复问题验证； 4. 新增问题识别； 5. 修旧引新检查。

输出结果不是重复评论，而是状态变化：

AICR-001：已修复 AICR-002：仍未修复 AICR-003：修复后引入新的空指针风险

5. 防止修旧引新的低成本策略

可以使用三层策略。

第一层：只看修复相关 Diff

如果某个 Commit 声称修复 AICR-001，只重点审查：

• 该问题所在文件；
• 相关函数；
• 调用链上下游；
• 对应测试。

不要全量重审项目。

第二层：对比问题前后语义

不要只看行号变化，要比较语义变化：

修复前： if status != CANCELED { expire(order) } 修复后： if status == PENDING { expire(order) }

AI 需要判断：

• 原风险是否消失；
• 新逻辑是否覆盖需求；
• 是否遗漏边界状态；
• 是否破坏原有行为。

第三层：强制要求测试或验证证据

对于高风险问题，AICR 不只问“代码改了吗”，还要问：

• 是否新增或更新测试；
• 是否覆盖原 Bug 场景；
• 是否覆盖反例；
• 是否有回归风险；
• CI 是否通过。

例如：

如果修复的是订单状态机问题，至少应覆盖： 1. PENDING 超时后变 EXPIRED； 2. PAID 不应被修改； 3. CANCELED 不应被修改； 4. 重复执行任务保持幂等。

五、问题三：如何通过多 Agent 的收拢与扩展，让审查建议少而精、精而全，驱动真实采纳？

多 Agent 的关键不在于“Agent 越多越好”，而在于：

扩展阶段多维度发现问题，收敛阶段严格筛选输出。

1. 推荐的多 Agent 架构

可以分为四层：

上下文层 → 专家审查层 → 收敛裁决层 → 输出反馈层

2. 上下文层 Agent

需求理解 Agent

负责读取：

• Issue；
• PR 描述；
• 需求文档；
• 产品验收标准。

输出：

• 本次变更目标；
• 关键业务规则；
• 高风险点。

Diff 摘要 Agent

负责解析：

• 修改了哪些文件；
• 改了哪些函数；
• 新增/删除了哪些逻辑；
• 影响哪些接口、任务、配置、测试。

输出结构化变更摘要。

上下文检索 Agent

负责从代码库检索：

• 调用关系；
• 相关类型定义；
• 配置；
• 测试；
• 历史相似实现；
• 历史缺陷。

3. 专家审查层 Agent

可以按风险维度拆分：

业务逻辑 Agent

关注：

• 需求是否实现；
• 边界条件；
• 状态流转；
• 幂等性；
• 兼容性。

安全 Agent

关注：

• 鉴权；
• 越权；
• 注入；
• 敏感信息泄漏；
• SSRF；
• XSS；
• CSRF；
• 密钥硬编码。

稳定性 Agent

关注：

• 空指针；
• 并发；
• 事务；
• 重试；
• 超时；
• 资源释放；
• 异常处理。

性能 Agent

关注：

• N+1 查询；
• 不必要的循环；
• 大对象拷贝；
• 缓存失效；
• 锁粒度；
• 慢查询。

测试 Agent

关注：

• 是否新增测试；
• 是否覆盖主路径；
• 是否覆盖异常路径；
• 是否覆盖回归场景；
• 是否存在脆弱测试。

架构一致性 Agent

关注：

• 是否破坏分层；
• 是否绕过公共组件；
• 是否违反项目规范；
• 是否引入不必要依赖。

4. 收敛层：比发现问题更重要

如果所有 Agent 的结果都直接输出，开发者会被淹没。

所以必须有一个 Review Judge / Aggregator Agent，负责：

1. 去重；
2. 合并同类项；
3. 判断证据是否充分；
4. 过滤低价值建议；
5. 按严重级别排序；
6. 控制最终建议数量；
7. 确定是否阻断合并。

5. 建议输出要少而精

可以设置硬性策略：

默认最多输出 5 条建议； BLOCKER 不限； 低置信度建议不直接评论，只进入内部记录； 风格类建议除非违反项目规范，否则不输出； 没有明确修复方案的不输出； 无法定位具体代码的不输出。

每条建议必须满足：

1. 有明确代码位置； 2. 有明确风险说明； 3. 有上下文证据； 4. 有可执行修复建议； 5. 有严重级别； 6. 有置信度； 7. 能判断是否由本次 Diff 引入。

6. 推荐的 Review 输出格式

例如：

[MAJOR] 已支付订单可能被超时任务错误关闭 位置： src/order/timeout.go:45 问题： 本次 Diff 将订单超时判断从 `status == PENDING` 修改为 `status != CANCELED`。 这会导致 `PAID` 状态的订单也满足条件，被错误标记为 EXPIRED。 依据： 需求中要求“仅未支付订单超过 30 分钟后关闭”。 当前项目状态流转中，PAID 是终态，不应被超时任务修改。 建议： 将判断条件限制为 `status == PENDING`，并补充以下测试： 1. PENDING 超时后变为 EXPIRED； 2. PAID 状态不会被修改； 3. 重复执行任务保持幂等。

这种建议比“请注意状态判断是否正确”更容易被采纳。

7. 用采纳率反向优化 Agent

AICR 不是一次性建设完成的。

需要持续记录：

• 哪些建议被采纳；
• 哪些被忽略；
• 哪些被标记误报；
• 哪些最终导致线上问题；
• 哪些规则噪音最高；
• 哪些 Agent 贡献最大。

核心指标包括：

采纳率 误报率 重复评论率 阻断准确率 平均修复时长 问题逃逸率 评论触达率

通过这些指标反向优化：

• Prompt；
• 检索策略；
• Agent 权重；
• 输出阈值；
• 阻断规则。

六、问题四：如何将审查融入 CI/CD，实现结果回写、状态追踪与修复闭环？

AICR 必须接入工程流，否则只是一个旁路工具。

1. 推荐 CI/CD 集成位置

AICR 可以在以下节点触发：

1. PR/MR 创建时； 2. PR/MR 更新描述时； 3. Commit Push 时； 4. CI 单测完成后； 5. 合并前； 6. 合并后定期抽检。

最关键的是前四个。

2. 标准工作流

推荐流程：

开发者提交 PR/MR ↓ 触发 AICR ↓ 拉取需求、Diff、项目上下文、历史问题 ↓ 多 Agent 并行审查 ↓ 收敛裁决 ↓ 结果回写 PR/MR ↓ 严重问题设置 Check Failed ↓ 开发者修复并 Push ↓ AICR 增量复审 ↓ 更新问题状态 ↓ 所有阻断项关闭后允许合并

3. 结果回写方式

可以回写到：

• GitHub Pull Request Review Comment；
• GitLab Merge Request Discussion；
• Bitbucket Comment；
• 企业内部代码平台；
• IM 通知；
• 质量看板。

建议区分两种输出：

行内评论

适合具体代码问题：

src/order/timeout.go:45 这里可能导致 PAID 状态订单被错误关闭。

总结评论

适合 PR 级别汇总：

AICR 审查结果： - BLOCKER：0 - MAJOR：1 - MINOR：2 - QUESTION：1 是否允许合并：否 主要风险： 1. 订单状态机存在潜在错误更新； 2. 缺少支付完成后的回归测试。

4. 状态追踪模型

每个问题应有状态机：

OPEN ↓ ACKNOWLEDGED ↓ FIXED ↓ VERIFIED ↓ CLOSED

也可能有：

FALSE_POSITIVE WONT_FIX DUPLICATE OUTDATED

例如：

{"issue_id":"AICR-001","status":"VERIFIED","created_commit":"abc123","fixed_commit":"def456","verified_commit":"ghi789","review_comment_url":"https://gitlab.xxx/mr/123#note_456","resolution":"fixed_by_code_change_and_test"}

5. 合并门禁策略

不要一开始就强阻断所有问题。

推荐分阶段：

第一阶段：只评论，不阻断

用于收集数据，观察误报率和采纳率。

BLOCKER/MAJOR 只提示，不拦截。

第二阶段：高置信度严重问题阻断

例如：

安全漏洞； 权限绕过； 明显空指针； 数据删除风险； SQL 注入； 密钥泄漏； 测试失败； 高置信度业务规则违反。

第三阶段：按仓库和团队定制门禁

不同项目采用不同策略：

核心交易链路：严格阻断 内部后台工具：弱阻断 实验性项目：只提示 基础组件库：加强兼容性检查

6. 修复闭环

闭环不仅是“开发者改了代码”，而是：

发现问题 → 回写评论 → 开发者处理 → AI 复审 → 状态更新 → 合并门禁解除 → 数据沉淀

修复闭环需要做到：

• 评论有唯一 ID；
• 后续 Commit 可关联问题；
• 修复后自动验证；
• 误报可反馈；
• Wont Fix 可记录理由；
• 关闭问题需要证据；
• 质量数据可分析。

七、推荐的 AICR 技术架构

整体架构可以如下：

Git 平台 Webhook ↓ 事件调度器 ↓ Diff 解析器 ↓ 上下文构建器 ↓ 代码索引 / RAG 检索 ↓ 多 Agent Review 引擎 ↓ 结果收敛器 ↓ 问题状态管理 ↓ 结果回写服务 ↓ CI/CD Check Gate ↓ 质量看板与反馈系统

核心模块说明

1. Webhook 接入层

接收：

• PR/MR opened；
• PR/MR updated；
• push commit；
• comment event；
• pipeline finished。

2. Diff 解析层

负责：

• 获取 changed files；
• 解析 hunks；
• 定位新增/修改/删除行；
• 提取函数级上下文；
• 判断文件类型和风险类别。

3. 上下文构建层

负责组装：

• 需求信息；
• PR 描述；
• Commit 信息；
• 相关文件；
• 调用链；
• 测试；
• 配置；
• 历史问题。

4. RAG / 代码索引层

可以基于：

• Tree-sitter；
• LSP；
• ctags；
• embeddings；
• 符号表；
• 调用图；
• 项目文档索引。

5. 多 Agent 审查层

负责各专业维度分析。

6. 收敛裁决层

负责最终输出控制。

7. Issue 状态层

负责：

• 问题指纹；
• 状态机；
• Commit 追踪；
• 修复验证；
• 历史查询。

8. 回写与门禁层

负责：

• PR 评论；
• 行内 Review；
• Check Run；
• Pipeline Status；
• 阻断策略；
• 通知。

八、落地建议：从最小可用版本开始

如果从 0 开始，不建议一上来做复杂多 Agent 和全量代码索引。

可以按下面路线落地。

第一步：MVP

实现：

• PR/MR Diff 获取；
• AI Review；
• 结果回写；
• 严重级别分类；
• 不阻断合并。

目标：

先跑起来，验证研发是否愿意看。

第二步：引入需求和上下文

增加：

• PR 标题和描述；
• Issue 关联；
• 修改函数完整上下文；
• 相关测试文件；
• 项目 Review 规范。

目标：

减少泛泛建议和误报。

第三步：结构化问题和状态追踪

增加：

• issue_id；
• fingerprint；
• open/fixed/verified 状态；
• Commit 追踪；
• 重复评论抑制。

目标：

让 AICR 从评论工具变成问题管理系统。

第四步：多 Agent 和结果收敛

增加：

• 安全 Agent；
• 业务 Agent；
• 测试 Agent；
• 稳定性 Agent；
• 汇总裁决 Agent。

目标：

提升覆盖面，同时减少噪音。

第五步：CI/CD 门禁

增加：

• Check Run；
• Pipeline 集成；
• 严重问题阻断；
• 修复后自动解除阻断；
• 质量看板。

目标：

形成真实质量闭环。

九、最终总结

围绕你提出的四个问题，可以总结为四句话：

1. 让 AI 理解需求和项目意图

不要只喂 Diff，要构造包含需求、PR 描述、相关代码、调用关系、测试和项目规范的上下文包；同时要求 AI 先理解变更意图，再进行 Review。

2. 审查看 Diff，追踪看 Commit

Review 聚焦本次 Diff，避免全量扫描带来成本和噪音；问题追踪则基于 Commit、issue_id 和 fingerprint，判断问题是否新增、修复或复发。

3. 多 Agent 扩展，收敛器控噪

用多 Agent 覆盖业务、安全、稳定性、性能、测试、架构等维度；但最终必须通过收敛裁决，只输出证据充分、可定位、可修复、真正有价值的建议。

4. 融入 CI/CD，形成闭环

AICR 要接入 PR/MR、Commit Push、CI Pipeline 和合并门禁；实现评论回写、状态更新、修复验证、误报反馈和质量数据沉淀。

最终的 AICR 不应只是“AI 帮你看代码”，而应成为：

一个围绕 Diff 审查、Commit 追踪、多 Agent 风险识别、CI/CD 闭环治理的智能代码质量系统。