AI 编程智能体现在可以在你冲一杯咖啡的时间里，跨十几个文件写出数千行生产代码。瓶颈不再是代码生成，而是审查，而且还没有人真正确定怎样才能做好这件事。

我们的人机体验团队与隆德大学的研究人员合作，研究了用于审查 AI 生成代码的工具应该是什么样，以及应如何融入开发流程。这项研究已写成一篇新论文，并将于 10 月在 2026 年实证软件工程国际周（ESEIW）上展示。

这项研究的核心信息是：审查 AI 生成代码的核心问题在于信任校准。在工具迎头赶上之前，开发者只能继续盲飞。

我们的论文提出了一个概念框架，用于构建面向 AI 的代码审查工具，这些工具应在开发者真正投入注意力的实际粒度上揭示风险与信心信号。该提案基于一项参与式设计研究，17 位从业者提供了积极反馈与协作，另有 43 位软件专业人士参与了后续调查。在这篇博文中，我们介绍这一概念框架，然后讨论它如何应用于开发者工具，以及如何借助该框架进行设计。

为什么你惯常的审查直觉在 AI 生成代码上会失灵

传统上，当你审查同事的代码时，有许多隐形支架在暗中帮你。你大致知道对方资历如何、对代码库的哪些部分有把握、又倾向于在哪些部分赶工。你可以向他们提问。当某处看起来奇怪时，你可以在 Slack 上戳一下对方，30 秒内就能得到解释。然而，当作者是大语言模型（LLM）时，这一切都不存在。

除此之外，语言模型会以同样的表面信心呈现每一行生成代码，无论它生成那一行时实际上有多不确定。没有任何信号告诉你：身份验证逻辑很直接，而数据库迁移则有些勉强。一切看起来都一样，读起来也都一样。

对此的理性反应是逐行阅读，因为任何一行都可能是出错的那一行。但是，这意味着可能要对数千行代码进行逐行审计，而且随着 AI 智能体能力增强、开始生成越来越大的变更集，这种做法的可扩展性极差。

在我们的论文中，我们主张，AI 生成代码的审查需要重新定义，以跟上时代变化。我们将其概括为：diff 视图范式无法扩展。传统 diff 查看器假定审查者的任务是理解改了什么。但当作者是一个能够快速生成大量变更、并以同质信心呈现异质输出的 LLM 时，理解改了什么反而是容易的部分。

知道是否该信任它——以及在何处信任——才是困难的部分。随着 AI 智能体承担越来越大、越来越复杂的任务，以及专业代码库中 LLM 生成代码的数量持续增长，这种重新定义将变得越来越重要。diff 查看器是审查同事所写代码的合适工具，但它可能不是审查你的智能体所写代码的合适工具。

换句话说，审查 LLM 生成的多文件变更不是一个 diff 问题，而是一个信任校准问题。我们将信任校准定义为：当无法追问作者其信心或推理时，仍能按片段级风险成比例地分配审查精力的能力。这是一种知道该在哪里仔细看、在哪里可以略读的技能——人类编写的代码审查通过社交和上下文线索隐性地支持这种技能，而 AI 生成代码的审查目前几乎完全没有提供支持。

三层审查工作流：从高层到选择性细节

信息可视化领域有一个来自 Shneiderman 的著名原则：先概览，再缩放和过滤，然后按需查看细节。如下图所示。

[LOADING...]

我们的三层审查工作流几乎与之完全对应，遵循了资深开发者关于如何阅读不熟悉代码的经验说法。如下图所示。

[LOADING...]

也就是说，审查者首先形成高层假设，然后有选择地深入查看，以验证这些假设。相比之下，更传统的逐行 diff 会迫使开发者跳过高层审查，而面对大量 AI 生成变更时，这会让人觉得认知成本更高。也就是说，当一个任务包含许多相互作用的元素时，组织不佳的呈现方式会消耗本可用于理解和判断的处理能力。

我们通过一系列四场研讨会，发展出了所提出的工作流结构。除了工作流结构之外，我们还从参与者的意见中提炼出反复出现的设计构件，用以支撑该工作流结构。关于我们的提案，以及我们如何与开发者一起头脑风暴他们在工作流中需要什么，更多细节可在我们的论文中找到。

工具：目前有哪些，以及我们的提案如何帮助工具构建者支持开发者

这些想法都不是凭空出现的，我们在论文中对此进行了讨论。其中一些构件在已有工具中已有部分对应物：CodeRabbit 提供对拉取请求的文字导览式摘要。Claude Code 会启动多个审查智能体，并按严重程度给发现的问题打标签。Graphite 的堆叠式拉取请求模型将大型变更拆分为可独立审查的单元——这是与我们的分块思路最接近的现有类似方案，尽管它跨多个拉取请求运作，而不是拆分单个生成的提案。GitHub 也注意到了这一转变。该平台现在专门发布了审查 AI 生成代码的指南。它还报告称，Copilot 辅助的代码审查已占该平台审查总量的五分之一以上。

所有这些都表明，我们提出的工作流已经与开发者相关，即使没有任何一个工具完整采纳这些想法。尤其没有工具以能够解决信任校准的方式做到这一点。工作流的高层起点——先概览后文件、先文件后行、先风险分层后分析性阅读——并不是当前任何工具强制要求甚至建议的做法。这正是我们的框架试图填补的实际设计空白。

对工具设计者的启示清晰而直接：如果你正在为 AI 原生开发时代构建 IDE 工具，那么需要围绕的核心问题不是我们如何显示 diff？，而是审查者需要在什么粒度上分配注意力，以及我们需要在那里呈现什么信号？

我们的三层框架为你构建这些工具提供了有原则的支架。一些指导原则如下：

• 概览级工具应替代人类作者审查天然获得的人际了解，例如能够询问作者当时在想什么，能够利用对其强项和弱点的了解。
• 文件级工具应在审查者阅读任何一行之前完成风险分层——帮助他们在真正重要的地方投入精力。
• 代码片段级工具应恢复优秀代码审查一直需要的细粒度分析工作，但配备人类作者审查无法提供的分块拆解和思维链关联。

我们的框架还指出了构建时应避免什么。也就是说，只解决理解问题而不解决信任校准问题的工具，可能会提高低风险变更的效率，却未触及后果更严重的失败模式。我们指的是系统性地将审查精力错误地分配到低风险片段，而偏离高风险片段。

查看我们的论文

在之前的博文中，我们讨论了如何将扩展现实集成到工具中，以帮助开发者审查 AI 生成的代码（见《可能构建之物的草图》一节）。请关注本专栏，获取类似研究的更新。