给“氛围编程”系上安全带：阿里集团 AI 代码评审实践与 Benchmark 开源

阿里集团联合南京大学开源了业界首个多语言 CodeReview Benchmark，同时分享了在 AI 代码评审这条路上的实战经验与技术思考。核心话题包括：

1. AI 代码生成带来的评审挑战，以及“氛围编程”背后隐藏的风险
2. 阿里 AI 代码评审助手如何构建人机协作的新范式
3. Agent 架构驱动的智能评审能力，究竟突破了什么

前言

这篇文章，会聊聊阿里集团在 AI 代码评审方向探索了一年半的现状——这是一个经历了“数万亿 Token 真实场景打磨”的工程实践。同时，我们还联合南京大学研发效能实验室，开源了业界首个多语言、具备存储库上下文感知的 CodeReview Benchmark。这个评测集汇聚了 80 多位资深工程师进行多轮交叉标注，目的就是为行业提供一个更精准的质量评估标准。

现在，AI 浪潮已经席卷全球，从 Copilot 到 Agent，代码生成技术的演进速度惊人。AI 以前所未有的效率和规模生产着代码，但这股洪流也给软件开发生命周期中一个关键环节——

——带来了前所未有的挑战。

面对 AI 交付的海量代码，不知道你有没有类似的“体感”：随着对工具边界的熟悉和 Prompt 技巧的熟练，信任感会慢慢建立起来。只要代码能编译、单测能通过、预发环境功能正常，我们就很容易形成一套简化的验收标准，渐渐放弃了对 AI 生成代码的逐行 Review。

这种被称为

的美好，往往会被一次突如其来的线上故障无情戳破。

代码 Bug 就像蟑螂：当你发现一只时，阴暗处可能早已潜伏着成百上千只。你不去寻找，隐患依然存在。

随着 AI 代码生成的规模与效率呈指数级增长，即使是极低概率的模型幻觉产生的 Bug，一旦逃过代码审查流入生产环境，累积起来的绝对数量就是巨大的线上风险。那么，我们如何更好地借助 AI 的能力，来预防这些由编码引起的线上故障？希望这篇文章能给你一些启发。

阿里集团的AI代码评审发展到了什么阶段？

人机协作新范式：AI 接管基础，人类聚焦核心

在代码生成技术日新月异的今天，作为编码守门员的 Code Review，也在加速智能化进程。自 2024 年初上线以来，阿里官方的 AI 代码评审助手已经深入数万开发者的日常工作。内部数据显示，每天有超过一半的有效评审意见由 AI 产出，而且这个比例还在逐步增长。有趣的是，在人工评审量小幅下降的情况下，总体有效评审量（包括采纳的 AI 意见）却实现了同比翻倍。这个趋势标志着 Code Review 正在进入人机协作的新阶段：

AI 代码评审功能示例图

Agent 驱动：像人类一样评审代码

经过

打磨，新一代 AI 代码评审助手的评审能力早已超越了初级工程师。它具备的深度问题发现能力。不同于传统的 RAG 模式，全新的 Agent 架构赋予了它“动态召回上下文”的核心优势：它能像资深工程师一样进行智能决策——既能直接响应简单的语法问题，也能在面对复杂逻辑时自主调用工具，通过多轮“思考-行动”的迭代，精准捕捉那些隐藏的代码隐患。

接下来，通过一个经典的

案例，我们来看看 Agent 是如何像人类一样进行逻辑推演的。

：示例中新增了一个获取 AI 规则的 getCodeReviewAiRuleResult 方法。该方法的逻辑是：首先调用 projectCodeReviewSettingsService.getAiReviewSettings(projectId) 方法从数据库中获取配置，然后将返回结果中的字段 aiReviewSettings.getAiReviewSetting() 传入 IntelligentReviewRuleMatcher.build 方法。

1. 感知上下文 (Context Perception)

Agent 首先根据新增代码的行号，主动读取了方法附近的完整上下文，以便理解业务逻辑的来龙去脉。

{
  "role": "assistant",
  "content": "需要详细了解新添加方法的上下文环境以更好地评估其功能和潜在问题。",
  "reasoning_content": "我将根据提供的评审检查项来审查当前文件的代码改动。首先分析新增的方法 `getCodeReviewAiRuleResult`",
  "tool_calls": [
    {
      "type": "function",
      "function": {
        "name": "file.read",
        "arguments": "{"file_path":"force-base/src/main/ja va/com/alibaba/force/base/project/service/impl/ProjectsImpl.ja va","start_line":2715,"end_line":2755}"
      }
    }
  ]
}

2. 假设与推理 (Hypothesis & Reasoning)

在理解代码逻辑后，Agent 敏锐地察觉到了风险点：如果 getAiReviewSettings 方法返回 null，后续直接调用 aiReviewSettings.getAiReviewSetting() 必然导致空指针异常。为了验证这个假设并非杞人忧天，它决定调用全局搜索工具，查证该方法的历史行为。

{
  "role": "assistant",
  "content": "需要确认AiReviewSettingsOutputDTO对象是否可能为空以及如何处理这种情况",
  "reasoning_content": "我已经阅读了相关的代码，我发现一个潜在的问题，在 `getCodeReviewAiRuleResult` 方法中，如果没有对 `aiReviewSettings` 进行空值检查，当 `projectCodeReviewSettingsService.getAiReviewSettings(projectId)` 返回null时会导致NPE。
  让我进一步确认一下这个方法的上下文和其他相关信息。",
  "tool_calls": [
    {
      "type": "function",
      "function": {
        "name": "code.search",
        "arguments": "{"search_text":"getAiReviewSettings","case_sensitive":false}"
      }
    }
  ]
}

3. 证据验证与风险上报 (Verification & Risk reporting)

全局搜索的结果证实了 Agent 的猜想。它发现该方法在多处被调用，且在测试用例 ClientLlmCodeReviewEventListenerTest.ja va 中明确存在处理返回 null 的场景。这一“铁证”表明，如果不做防御性编程，线上故障风险极高。基于确凿的证据，Agent 最终决定提交评审意见，并给出了具体的修复建议。

{
  "role": "assistant",
  "content": "发现了一个可能导致空指针异常的问题，需要提供具体的修复建议",
  "reasoning_content": "通过搜索结果可以看到，`getAiReviewSettings` 方法在多个地方被调用，并且在测试中有返回null的情况（例如 ClientLlmCodeReviewEventListenerTest.ja va 中的第151行）。这表明该方法确实可能返回null。

  因此，在新的 `getCodeReviewAiRuleResult` 方法中直接调用 `aiReviewSettings.getAiReviewSetting()` 存在空指针异常的风险。我们需要添加空值检查或者确保上层已经处理了这种情况。

  此外，我还注意到一个问题：在 `getIntelligentReviewExcludePaths` 方法中，如果配置不存在，默认值是从 `MergeRequestLlmConstants.INTELLIGENT_REVIEW_EXCLUDE_PATHS` 获取的。但是我没有看到这个常量的定义，需要确认它是否存在以及内容是否合适。

  不过基于现有信息，最主要的问题是NPE风险。我现在准备提交这个问题的反馈。",
  "tool_calls": [
    {
      "type": "function",
      "function": {
        "name": "code_comment",
        "arguments": "{"comments":[{"comment":"可能存在空指针异常风险。projectCodeReviewSettingsService.getAiReviewSettings(projectId) 的返回值可能为 null，这种情况下调用 aiReviewSettings.getAiReviewSetting() 将抛出 NullPointerException。建议增加空值检查。"}]}"
      }
    }
  ]
}

从这个示例中，可以深刻感受到 Agent 与传统工具的本质差异：它没有止步于当前修改的文件，而是展现了

的完整思维闭环。Agent 不仅识别出了语法层面的调用，更通过跨文件的全库检索，成功模拟了人类工程师查阅测试用例、验证边界条件的深层逻辑。这种具备认知与推理能力的评审助手，不仅大幅降低了误报率，更真正实现了将隐蔽的运行时风险拦截在合并之前。

AI 正在重塑人类代码评审的习惯

技术的迭代不仅改变了工具，也在深刻地重塑开发者与代码的关系。在传统研发流程中，开发者是纯粹的“作者”，写完代码后被动等待他人检查；而在 Agent 时代，这种

认知错位：AI Review 仍处于迷茫期

在 AI 辅助编程（AI Coding）领域，开发者们已经形成了一个强烈共识：“提问的质量决定了任务的质量”。要生成高质量的业务代码，用户必须清晰地描述需求、边界和约束条件。然而，在 AI 代码评审（AI Code Review）场景下，这种认知却出现了断层。绝大多数用户依然停留在传统思维惯性中，期望点一个按钮，AI 就能在没有任何背景输入的情况下，像上帝一样洞察一切隐患。这种

的期待，使得用户在评审环节依然扮演着被动的角色。

以一个简单场景为例：在一个电商应用的订单模块中，需要增加“新用户专享”优惠券功能。

• 正例（描述清晰、边界完善）
  ：

：新增“新用户专享”优惠券类型
：
1. 增加“新用户专享”的优惠券类型。
2. 该优惠券有效期为 30 天。
3. 退款时，该优惠券退回，且在过期时间在之前的基础上增加 7 天。

• 反例（描述不清、缺乏边界）
  ：

：新增“新用户专享”优惠券类型
：如题

AI 评审代码时，代码逻辑可能是通顺的（可以正常生效优惠券），没有明显的 bug 或语法错误。AI 可能会给出一些代码风格或性能上的建议，但无法感知有效期的正确性，以及退款时对应的机制，因此也无法判断当前代码改动是否满足了需求。

核心博弈：模型能力有限 vs 用户需求无限

当前的 AI 代码评审正陷入

。开发者希望 AI 能读懂复杂的架构设计、隐含的业务规则甚至团队的潜规则，却没有提供哪怕一句话的意图描述。试图让 Agent 在缺乏上下文（Context）输入的情况下猜中开发者的心思，显然不现实。

• 不仅识别 Bug，还要贴合场景：
  Agent 的能力不仅在于静态扫描，更在于理解逻辑。如果开发者不告诉 Agent “这段代码是为了解决高并发场景下的锁竞争”，Agent 就很难给出针对性的并发安全建议。

• 交互式评审的崛起：
  未来的代码评审不应是“提交 -> 等待报告”的黑盒，而应是

  “描述改动意图 -> 定义关注点 -> Agent 执行专项评审 -> 人类决策”
  的互动过程。

只有“双向奔赴”，才能打破瓶颈

引入自定义规则是弥合“通用大模型能力”与“具体工程落地”之间鸿沟的必经之路。代码评审必须通过显性化的偏好定义，才能让 AI 从“泛泛而谈”转变为“懂你所想”的专家助手。然而数据显示，目前配置 AI 评审规则的用户不到十分之一。我们曾经做过一个实验，将历史上由编码引起的线上故障抽样进行复现，结论是：

的案例都能通过适当的规则来提前发现问题。但这些编码问题却没有在“无输入”的交互模式下被拦截。

是不是将历史上所有的编码故障都总结成规则后对全部用户生效，就能改善现状呢？答案是否定的。想靠一个大而全的规则集来试图拦截所有编码问题，最终结果不但问题识别率会下降，大模型还会因为过多的规则指令而引发大量误报。根本原因在于“标准化的不可能”：

• 业务 DNA 不同：
  支付系统的资金安全规则，对内容管理系统来说可能只是噪音；流计算的并发约束，在批处理脚本中反而是束缚。

• 主观偏好不同：
  AI 指出的同一个客观代码问题，不同的用户可能持有对立的态度，在不同代码库中的性质也不相同。

因此，使用 AI 代码评审助手的正确姿势，不应该是“啥也不做等着被评审”。而是像我们学会了如何提问让 AI 写代码一样，我们也需要学会为自己的代码制定约束规则，让 AI 更好地评审代码。只有当开发者开始主动定义“评审的目标”，将自己从单纯的“代码作者”转变为 AI 的“审查者”时，Agent 驱动的代码评审才能真正突破瓶颈，成为符合预期的效能倍增器。

Ja va 默认规则示例

如何编写有效的代码评审规则？

AI 代码评审中的“边际效应递减”

在 AI 代码评审中，规则存在显著的

现象：

• 局部视角：一条规则在特定项目里，准确率可能高达 90%。
• 全局视角：一旦强制应用到全局，面对千差万别的业务场景，准确率往往会跌至 60% 以下，随之而来的是误报率飙升。随着规则叠加越来越多，大模型的指令跟随也容易出现“混乱”。

最终的结果往往是：为了追求覆盖面，反而因为噪音过大导致得不偿失。

精准治理的策略：限定上下文

想要识别故障又不产生噪音，秘诀在于

。与其让 Agent 拿着放大镜无差别地扫描每一行代码，不如通过设定严格的，告诉 Agent 只有在特定场景下才。

1. 物理边界收敛：圈定“生效范围”

最基础的降噪手段是限定文件路径与层级。不同的代码层级承担着不同的职责，通用的规则往往是错位的。

• 按模块隔离：
  例如，“禁止直接调用 DAO 层”这条规则，应显式限定仅对 Controller 层或 Facade 层生效，而自动排除 Service 层的代码；对于“交易”等核心模块，应设置严格的 NPE（空指针）和并发安全规则，而对于其他非核心模块，则可以适当放宽性能要求，以此降低噪音。

• 按文件类型隔离：
  复杂的圈复杂度检查可能适用于业务逻辑，但对于自动生成的代码（如工具类或配置类等），则完全是干扰。

2. 逻辑特征收敛：识别“关键信号”

比物理路径更高级的，是基于代码内容的语义特征进行触发。只有当代码中间出现了特定的“信号”时，才激活相应的评审规则。

• 依赖触发：
  只有当文件引入了 Redisson 或 Lock 相关类库时，才激活“分布式锁释放检查”的规则。

• 注解触发：
  只有当方法上标记了 @Transactional 注解时，才重点检查“异常捕获后是否重新抛出”或“大事务”问题。

• 特定调用触发：
  只有监测到代码中调用了 ThreadLocal.set()，才强制触发“ThreadLocal 清理检查”。

以史为鉴：根据历史故障沉淀规则

我们从线上编码故障中沉淀了一些评审规则。由于代码的敏感性，下面示例均经脱敏后由 AI 构造：

业务常量或枚举的一致性问题

当你使用枚举来管理业务状态时，由于业务的复杂性很可能会在多处都涉及枚举的逻辑。新增枚举值时，可能会遗漏某处对新增枚举值的处理，从而导致线上故障。

- path: "**/enums/**.ja va"
  rule: "枚举类新增枚举值时，检查所有使用该枚举的 switch 语句是否处理了新值，避免遗漏分支"

字段隐藏导致获取的值与预期不一致而引发故障

在多人协作的项目中，我们往往会有一些 BaseModel，然后各个业务继承它来实现 BusinessModel。当项目中管理了很多类时，容易发生一种 Ja va 语法允许，但容易导致代码混淆和维护困难的问题——字段隐藏。此类情况我们可以为数据对象所在的范围设定一条规则来避免这类故障。

- path: "**/{model,dto,do,entity}/**.ja va"
  rule: "避免字段隐藏的风险，例如在子类增加父类中已有的字段，或者在父类中增加子类已有的字段。"

日志打印必须使用代码库内部的工具类

在多人协作的项目中，如果对日志打印阶段做了统一的切面处理，就需要规范大家打印日志时使用内部的工具类。

- path: "***.ja va"
  rule: "记录日志时必须使用代码库内部的FormatLogUtil工具类"

禁止多表关联查询超过 5 张表

当多表关联查询时，随着表数量的增加，代码会变得更难维护，同时也会增加性能风险。

- path: "**/mapper/**.xml"
  rule: "禁止多表关联查询时超过 5 张表，防止复杂多表关联导致的性能问题。"

金额计算应使用 BigDecimal 而不是 double

double 使用二进制浮点表示，无法精确表示某些十进制小数。例如 double result = 0.1 + 0.2; 打印出来不是 0.3，而是 0.30000000000000004。在大量计算中，微小的误差会累积放大，这在金融交易中是非常关键的。AI 可以根据字段命名的语义来判断当前字段是否会参与金融交易，从而决定是否给出提示。

- path: "***.ja va"
  rule: "金额计算应使用BigDecimal而不是double。"

行业基准：AACR-Bench 开源评测集

在过去一年半的演进过程中，如何准确评估模型与 Agent 在代码审查场景中的真实能力，仍是一大挑战。我们深刻体会到了缺乏权威评测标准的痛点，因此将 AACR-Bench 开源，旨在填补行业空白，推动智能代码审查领域的社区进步与技术迭代。

代码评审的高质量评测是代码评审任务表现提升的基础。现有的评估基准在复杂场景下显得力不从心，主要存在两大局限性：

1. 数据质量低：
   大多数基准直接使用原始 PR（Pull Request）评论作为真值，这不仅包含大量噪声，还经常漏标潜在 Bug，导致评估结果失真。

2. 视野狭窄：
   缺乏跨文件的仓库级上下文感知，且往往局限于单一编程语言（如仅支持 Python），无法全面衡量模型在真实复杂项目中的表现。

为了解决上述问题，南京大学与阿里巴巴 TRE 联合推出了

。该基准不仅仅是一个数据集，更是一套全面的评估体系，具备三大核心优势：

• 人机结合：
  更高质量的真值采用“AI 辅助 + 人类专家校验”的先进标注流水线，汇聚了

  80 多位资深工程师交叉标注的智慧
  。相比传统数据集，AACR-Bench 的问题覆盖率提升了

  285%
  ，成功挖掘出大量原 PR 中被忽略的隐性缺陷。

• 多维度评估：
  更全面的评估维度打破语言壁垒，支持

  10 种主流编程语言
  ，并提供

  完整的仓库级依赖上下文
  ，覆盖了多种类型与多种作用域的代码问题。这使得评估场景能够真实还原复杂的跨文件代码审查过程，全面考验模型的系统性理解能力。

• 更深刻的行业洞察：
  通过对主流 LLM 的广泛评估，我们发现上下文粒度和检索方法的选择对模型表现有着巨大影响。AACR-Bench 重新定义了 ACR 任务的评估标准，揭示了以往因数据局限性而被误导或低估的模型能力。

开源资源：AACR-Bench 现已在 GitHub 及 Hugging Face 上公开，相关论文也已发布，供行业参考使用。

结语：给“氛围编程”系上安全带

回到文章开头提到的 Vibe Coding（氛围编程）：我们享受 AI 带来的极速编码体验，但内心深处或许都藏着对那只“隐形蟑螂”的担忧。

今天的 AI 代码评审助手，已经不再是一个只能发现简单问题的死板工具。它具备了理解上下文以及跨文件、跨变更的问题发现能力。但它依然有一个致命的短板——它不懂你的业务 DNA。它不知道这个静态集合是高频使用还是正常使用，也不知道那个并发逻辑是 Bug 还是 Feature。而这，需要我们这些使用工具的开发者去定义。

现阶段，请不要期待一个“开箱即用”的完美 AI 能解决所有问题。真正的智能化，始于你决定不再做 AI 的被动消费者，而是成为它的

的那一刻。只有当 AI 学会了你的规矩，它才能从一个“不太聪明”的旁观者，进化为你身后那个孜孜不倦的金牌守门员。