Our Framework for Reviewing AI-Generated Code

我们用于审查AI生成代码的框架 - JetBrains 博客

JetBrains 研究

研究对于进步和创新至关重要，这也是为什么JetBrains对科学和市场研究都充满热情。

关于JetBrains研究

研究

我们用于审查AI生成代码的框架

Katie Fraser

Agnia Sergeyuk

Ilya Zakharov

如今，AI编码代理可以在你喝咖啡的时间里，生成跨越十几个文件的数千行生产代码。瓶颈不再是代码生成，而是代码审查，而目前尚无人清楚如何高效地进行这项工作。

我们的人机体验团队与隆德大学的研究人员合作，探讨用于审查AI生成代码的工具应具备哪些特征，以及如何将其集成到开发流程中。这项研究以论文形式发表，并将于2026年10月在实证软件工程国际周（ESEIW）上发表。

研究的核心信息是：审查AI生成代码的主要问题是信任校准。在工具尚未完善之前，开发者将继续在缺乏明确信息的情况下进行判断。

我们的论文提出了一种构建AI就绪代码审查工具的概念性框架，该框架能够在开发者关注的实际粒度层级上揭示风险和置信度信号。这一方案基于与17位实践者的参与式设计研究（包含积极反馈和协作），以及对43位软件专业人士的后续调查。在本文中，我们将介绍这一概念框架，并讨论它如何应用于开发者工具的设计。

为什么常规的代码审查直觉在AI生成代码面前失效

传统上，当你审查同事的代码时，你有许多隐形的支撑条件在帮助你。你知道对方的大致资历，清楚他们对代码库哪些部分有信心，哪些部分容易草率处理。你可以向他们提问。当发现某些地方异常时，你可以在Slack上快速联系他们，30秒内就能得到解释。然而，当作者是大型语言模型（LLM）时，这些条件都不存在了。

更糟糕的是，语言模型对生成的每一行代码都表现出相同的置信度，无论生成该行代码时实际存在多少不确定性。没有信号能告诉你认证逻辑是简单的，而数据库迁移则充满挑战。所有代码看起来都一样，读起来也完全相同。

面对这种情况，理性的反应是逐行阅读，因为任何一行都可能是错误的。但这样就需要对可能成千上万行代码进行逐行审计，随着AI代理变得越来越强大并开始生成更大规模的代码变更集，这种审查方式的扩展性将变得极差。

在我们的论文中，我们主张需要重新定义AI生成代码的审查方式，以适应时代的变化。我们将这种情况描述为差异视图范式（diff-view paradigm）无法扩展。传统的差异查看器假设审查者的任务是理解发生了哪些变更。但当作者是能够快速生成大规模变更并以统一置信度呈现异构输出的LLM时，理解发生了什么变更反而变得容易了。

知道是否信任它——以及在何处信任——才是困难所在。随着AI代理承担的任务日益庞大复杂，且专业代码库中由大型语言模型（LLM）生成的代码量持续增长，这种重新定位将变得至关重要。差异查看器是审查同事编写代码的合适工具，但可能并不适合审查代理生成的代码。

换一种说法，审查LLM生成的多文件修改不是差异比对问题，而是信任校准问题。我们将信任校准定义为：在无法向作者询问其置信度或推理过程时，根据片段层级风险合理分配审查精力的能力。这是掌握在哪些地方需要深入检查、哪些地方可以快速浏览的技能——这种技能通过社会和情境线索，隐含地支持了人类编写的代码审查，而当前AI生成的代码审查几乎完全无法提供这种支持。

三层次审查工作流程：从宏观到选择性细节

信息可视化领域有一个广为人知的原则，由Shneiderman提出：先提供概览，然后进行缩放和过滤，最后按需查看细节。这在下图中有所展示。

我们的三层次审查工作流程几乎完全对应这一原则，符合专家开发者关于他们如何阅读陌生代码的描述。这在下图中有所体现。

具体而言，首先审查者形成宏观假设，然后选择性地深入验证这些假设。相比之下，传统的逐行差异审查会迫使开发者跳过宏观审查阶段，当面对大量AI生成的修改时，这种做法在认知成本上更高。也就是说，当任务包含许多相互作用的元素时，混乱的呈现方式会消耗本可用于理解和判断的处理能力。

我们提出的流程结构是基于四次研讨会的成果。除了流程结构，我们还从参与者的反馈中提炼出反复出现的设计构建模块，这些模块支持了流程结构。关于我们的提案细节，以及我们如何与开发者讨论工作流程需求，更多内容可参见我们的论文。

工具：当前可用工具与我们的提案如何帮助工具构建者支持开发者

这些想法并非凭空出现，我们在论文中对此进行了讨论。其中一些构建模块在现有工具中已有部分对应：CodeRabbit为拉取请求提供文本摘要说明。Claude Code启动多个审查代理，按严重程度标记发现的问题。Graphite的堆叠拉取请求模型将大规模修改拆分为独立可审查的单元——这是与我们“代码块”概念最接近的现有工具，尽管它跨多个拉取请求运行，而非对单个生成提案进行分解。GitHub也注意到了这一趋势。该平台现已发布专门针对AI生成代码审查的指南，并报告称由Copilot辅助的代码审查已占平台总审查量的五分之一以上。

所有这些都表明，我们提出的协作流程对开发者来说已经具有现实意义，即使没有单一工具能完全涵盖这些理念，尤其是无法解决信任校准问题。当前工具既没有强制要求，甚至没有暗示这种高层次的协作流程——在文件层面之前进行概览，在代码行之前进行文件层面分析，在分析阅读之前进行风险分层——这正是我们框架试图填补的设计缺口。

对工具设计者的启示是明确且直接的：如果你正在构建面向AI原生开发时代的IDE工具，需要思考的核心问题不是"我们如何展示差异？"，而是"评审者需要在什么粒度上分配注意力，以及在这些粒度上需要呈现什么信号？"

我们的三级框架为构建这些工具提供了原则性框架。一些指导原则包括：

• 概览层级工具应替代人工评审中免费获得的社交属性导向，例如向作者提问其设计思路、利用对其优缺点的认知等能力。

• 文件层级工具应在评审者阅读任何代码行之前完成风险分层，帮助其将精力投入到关键位置。

• 代码片段层级工具应恢复优质代码评审始终需要的精细分析工作，但需配备代码块分解和思维链关联能力——这是人工评审无法提供的。

我们的框架也指出了构建工具时需要避免的问题：仅解决理解问题而未解决信任校准的工具，可能在低风险变更中提升效率，却对更严重的失败模式毫无作为。我们指的是系统性地将评审精力错误分配到低风险段落而忽视高风险段落。

查看我们的论文

在之前的博客文章中，我们讨论了如何将扩展现实技术整合到工具中，以帮助开发者进行AI生成代码的评审（参见"可构建内容的设想"章节）。请关注此领域以获取类似研究的更新。

代码评审

HAX

• 分享

• Facebook

• Twitter

• Linkedin

上一篇

AIDEs框架：我们如何构建AI开发工具的"万物理论"