Ohhnews

分类导航

$ cd ..
Jetbrains Blog原文

停止将IDE可捕获的AI代码错误提交至人工审核

#人工智能#代码审查#软件工程#自动化测试#开发效率

AI 编码工具或许确实提升了开发者的生产力,但也为代码审查流程带来了新的问题。合并请求(Pull Request)的数量显著增加,且提交审查的代码中出现了以往在生成式 AI 普及前并不常见的错误模式。然而,负责审查这些代码的人员及其工作时间却并未改变。

大多数工程领导者仍在摸索应对之道。根据我们对超过 24,000 名开发者进行的《2025 年开发者生态系统调查》,目前主流的模式是“临时起意”:开发者随心所欲地使用 AI 工具,缺乏上层的治理。

相关研究表明,约 20% 到 25% 的 AI 代码幻觉可以通过自动化的结构分析和静态分析检测出来。这些检查可以在代码编写环境内完成,无需等到提交合并请求时才进行。这既不需要治理框架,也不需要增加额外的流程层。

逻辑很简单:审查人员的判断力是一种有限的资源。每一个进入审查阶段的结构性错误都会消耗这种资源,而每一个在早期被拦截的错误则不会。

代码审查是一个决策过程——AI 只是增加了决策量

DX 针对 51,000 名开发者的 2025 年第四季度数据显示,每日使用 AI 的开发者每周合并的请求数量比轻度使用者多 60%。一项涵盖三家大型企业的 2025 年随机对照试验发现,拥有 AI 编码辅助工具的开发者每周完成的任务量比对照组多 26%。

这意味着审查人员每天需要处理的请求更多,做出的决策也更多。这种压力有着可衡量的代价。早在 AI 编码工具出现几十年前,研究人员就发现,审查速度是衡量缺陷移除效率的一个统计学显著因素,即使在控制了开发者能力变量后依然成立。每行代码花费的审查时间越长,发现的缺陷数量通常就越多。

仅靠技能无法弥补仓促审查带来的问题。更好的工具本应解决这一困境,但包括现代 AI 辅助工具在内的各类工具,尚未能弥合“审查者所见”与“审查者所需”之间的差距:

  • 一项针对某公司 AI 代码审查工具的 2024 年研究发现,即使 73.8% 的自动化审查意见被采纳,合并请求的关闭时间仍增加了 42%。评论虽然有价值,但审查负担并未减轻。
  • 2025 年,一项针对 16 种 AI 代码审查工具、超过 22,000 条评论的实证研究发现,它们的有效性差异极大。
  • 2026 年 1 月的一项研究揭示,有效的审查不仅仅需要查看代码的增删快照。审查人员需要在问题追踪器、文档、团队讨论和 CI 报告之间来回切换,才能理解代码变更在项目中的具体含义。

目前的审查工具依然让开发者自己去构建全局观。AI 扩大了这一鸿沟,而非弥合了它。

AI 正在向审查流程输送一种不同类型的代码

一项针对超过 50 万个代码样本的 2025 年分析发现,AI 生成的代码具有独特的错误特征:未使用的构造、硬编码的值以及比人工编写代码更常见的潜在高风险安全漏洞。另一项 2025 年的研究确定了一些在人工编写代码中几乎不存在的缺陷类别。

错误特征本身就够棘手了,而审查人员与 AI 生成代码的交互方式又加剧了这一问题。2026 年的一项研究发现了一个审查盲点:包含近两倍代码冗余的 AI 合并请求,收到的负面反馈反而比人工编写的更少。表面的合理性似乎降低了审查者的批判性投入。

工作量增加,错误类型变新,审查力度却在下降。交付数据说明了什么?

根据 DORA 的报告,AI 采用率每增加 25%,交付稳定性就会下降 7.2%。他们将这种模式部分归因于变更集变大:生成的代码越多,审查时的批次就越大,而大批次向来是系统不稳定的预兆。规模是信号,缺陷特征和审查数据则揭示了其背后的原因。

让机器去捕捉机器能处理的问题

自动化的结构检查和静态检查无需人工干预。但谁来部署这些检查呢?即使在工程实践成熟的组织中,个人层面的结构化筛选也未能充分落实:

  • Google 在其代码库中运行基于 LLM 的代码迁移时发现,审查人员需要频繁回滚 AI 生成的变更,以至于组织不得不刻意投资于自动化验证,以减轻这一负担。
  • Uber 每周处理数万次代码变更,他们发现 AI 辅助开发让审查人员不堪重负,因此构建了一个在人工审查介入前运行的自动化审查系统。

在这两个案例中,解决方案都需要组织的决策。Google 和 Uber 选择在流水线层面——即合并请求之前——进行处理。

合适的开发环境可以在更早阶段捕捉到同类错误,且无需额外的基础设施。

在流水线之前进行“零容忍”的结构分析

根据《2025 年 Stack Overflow 开发者调查》,开发者平均使用 3.6 个开发环境。使用哪些环境通常由他们自己决定。他们了解自己的语言和工作流。

作为工程领导者,您应该明确:至少有一个开发环境正在针对 AI 生成的代码,与整个代码库中所有语言的实际情况进行深度、零容忍的检查吗?许多开发环境做不到这一点;它们通常依赖于逐语言的近似检查。

这种区别在组织层面比在个人层面更重要。一名使用单一语言且配置了良好近似检查的开发者可能感觉不到这种差距,但团队中结构分析的质量,取决于其中配置最薄弱的一环。

关于 AI 代码幻觉的研究还发现,约 44% 的幻觉涉及现有自动化检查无法可靠发现的错误。这已经足够让您的审查人员头疼了。请保护他们的精力,让他们只处理那些必须由人工把关的问题。

对于团队使用的每一种主要语言,都有相应的 JetBrains IDE 可以维护代码库的全局解析模型。任何进入编辑器的代码——无论由哪个 AI 工具生成——都会对照该模型进行检查。对于希望在流水线之前和内部都进行强制执行的团队,Qodana 将同样的检查深度扩展到了 CI/CD 流程中。

审查人员的判断力是宝贵的资源。结构化筛选正是保护这一资源的手段。

了解 JetBrains for Business 如何在规模化环境下支持这种协作。