代码审查往往缓慢且质量不一：diff 在队列中等待，反馈则取决于谁在线。

只有当审查者掌握真实的代码库上下文时，AI 代码审查才能发挥作用。

当审查者已掌握完整 代码仓库、近期变更、测试以及一套明确的规则时，AI 代码审查效果最佳。具备这些上下文的 AI 代码审查，能够发现只盯着单个 diff 的独立 机器人 永远无法察觉的问题。审查作为产出变更的同一系统的一部分时，最具价值。

#代码审查发生了哪些变化

编程智能体并没有催生冗长的 PR，但它们让原有的审查逻辑更快失灵了。

使用编程智能体的开发者正在交付更大规模的变更。来自数百万个 Cursor 会话的数据显示，每个 PR 的新增代码行数 (p75) 同比增长约 2.5 倍。变更行数超过 1,000 行的超大型 PR 在合并中所占的比例持续上升，并且随着智能体和模型能力提升，这一趋势在 2026 年 1 月明显加速。智能体 会话也变得更深入：在最近两个月的时间窗口中，每次会话的平均工具调用次数上升了约 30%。由 AI 编写的代码也有更多被保留下来。自 2026 年初以来，60 分钟后仍然保留的已接受 AI 代码行占比，从约 76% 上升到 81%。在没有单独人工接受 diff 步骤的情况下就进入 commits 的智能体 生成变更，在这段时间里增长了 5 倍以上。

人工审查能力并没有随着这些变化同步提升。传统的同行代码审查建议一直认为，认真阅读几百行代码，大致还是能保证质量的范围。

当变更量超过能够逐一读完每个 diff 的资深工程师数量时，AI 代码审查就是帮你守住质量门槛的方式。

进入审查流程的代码里，越来越多是借助 AI 助手写出来的。人类很擅长发现“这不符合我们这里的构建方式”这类问题；但面对一个庞大、看起来合理、基本正确的智能体补丁时，要从中揪出那个细微却关键的错误，就没那么擅长了，而真正理解仓库上下文的审查者正能在这里发挥作用。编写大规模变更和检查它们是两种不同的技能，而审查就是后者。

#启动 AI 代码审查前需考虑的问题

如果您正在评估 AI 代码审查工具，请先梳理这些概念。

#什么是 AI 代码审查？

AI 代码审查是一类软件：它会读取一次变更 (通常是一个 PR，有时是本地 diff) ，并在合并前指出其中的缺陷、回归和风险。真正实用的版本关注的不只是眼前改动的几行代码，还会拉取相关文件、测试、配置和团队规则。较弱的版本则只是用文字复述 diff，或者一味挑剔注释和命名。

#它与 linting 或 CI 有何不同？

Linters 和类型检查器负责落实那些您本就知道该如何编写的规则。CI 则运行您已经自动化的各项检查。AI 审查处理的是剩下这部分问题：逻辑错误、竞态条件、身份验证失误、会影响几层目录之外的改动，以及文档与实际行为不一致的问题。它与 CI 有重叠，但不能取代 CI。

#AI 代码审查会取代人工审查吗？

不会。它改变的是人们把时间花在哪里。毕竟，人工审查意见中只有大约一半最终会在同一个 PR 中促成修改。健康的审查文化也包括后续修复备注和 FYI 背景信息。您需要先清除那些高置信度、机器可处理的缺陷，让人们继续专注于架构、产品风险，以及模型目前还不具备的团队隐性知识。

#什么会让 AI 审查变得嘈杂？

这类噪声，来自机器人给出的人们并不想看到的评论。吹毛求疵的风格提醒、没有任何失败测试作为依据的模糊“添加测试”留言，以及无法发现缺陷的重写建议，都会让人们逐渐忽略审查结果。应区分模型能发现的问题，与人们真正希望它标出来的问题。AI 代码审查应标出真实缺陷、误提交、性能和安全问题，以及文档与代码不一致之处。当 Graphite 将其 AI 审查聚焦于这部分重叠区域 时，约 52% 的评论最终促成了代码修改 (与人工审查者的比例大致相当) ，点踩率低于 4%。

#我们应该衡量什么？

解决率：在合并时，被标记的问题是否真的在最终代码中修复了？解决率胜过评论量。

这也是我们用来改进 Bugbot 的指标：在 40 次实验中，解决率从 52% 提升到超过 70%，每次运行标记的缺陷数从 0.4 提高到 0.7，每个 PR 中已解决的缺陷数从大约 0.2 提高到约 0.5，并且 每月审查的 PR 超过两百万个。到 2026 年 5 月，默认投入级别下的解决率已达到约 80%，也就是到合并时约 80% 的缺陷已被解决。如果你的解决率下降，而评论量上升，那这个机器人就是在制造噪音。

Bugbot 仪表盘会展示每个代码仓库随时间变化的解决率，以及发现和修复的问题数量，帮助你判断审查是否发现了真正的问题，并在扩大机器人评论范围前将这些问题解决。

#代码审查应该在何时进行：本地、PR 上，还是两者都要？

两者都要，但分工不同。本地审查 (在智能体任务之后、push 之前) 能在上下文还很清晰、讨论串尚未形成时发现问题。PR 审查则是团队协作的约定：共享规则、共享历史、共享合并门槛。偏重安全的检查放在哪一侧都可以，取决于您的交付方式。

#我们是否需要让审查工具和智能体集成在同一个产品中？

您可以购买独立的审查工具。很多团队都会这么做。代价是需要来回切换上下文，而且对代码是如何产生的也只能看到较为有限的一面。当审查在编写变更的同一系统中运行时，它已经知道当前打开的文件、代码仓库映射，以及您在代码旁维护的规则。修复项可以深度链接回编辑器，或直接启动一个已载入该问题的智能体。这种循环很难靠后加上去的方案来伪造。

#如何在 Cursor 中运行 AI 代码审查

Cursor 的流程是：先在编辑器中进行本地审查，再由 Bugbot 审查 PR，随后通过修复循环回到同一套工具链。

本地。 完成智能体工作后，运行 智能体 Review。你可以在智能体输入框中输入 /agent-review，也可以从 Source Control 选项卡运行它，将本地更改与主分支进行比较，或开启每次 commits 后的自动审查。push 前，还可以通过 /review-bugbot 和 /review-security 技能在本地运行 Bugbot 或 Security 智能体。趁会话仍保留上下文时，解决明显问题。

在 PR 上。 Bugbot 会审查 GitHub、GitLab 和 Bitbucket 上的 PR。在 .cursor/BUGBOT.md 中定义团队不变量，并配合团队规则和代码仓库规则使用。学习规则 (@cursor remember) 会将反馈纳入后续运行。在扩大评论类别前，请先在 Bugbot 自动化中关注解决率。

修复循环。 发现项会显示在 PR 中，并提供跳转回 Cursor 的入口 (Fix in Cursor 和 Fix in Web) 。Bugbot Autofix 可以启动云端智能体来提出修复方案。在安全方面，Cursor 的 Security Agents 覆盖两项工作：Security Reviewer 在合并前检查 PR，Vulnerability Scanner 则扫描静态代码库。

开始。 文档涵盖端到端的设置流程：连接代码仓库、选择哪些代码仓库和人员会触发审查、设置投入级别，以及配置 .cursor/BUGBOT.md。请参阅 cursor.com/docs/bugbot。

#自动化分派与审批

发现缺陷并不是代码审查的全部工作。两项 Cursor 自动化功能可处理其中的流程性环节。

自动批准低风险变更。 Approval Agents 会根据风险为每个 PR 评分，并批准达到您所设标准的 PR。文案微调或配置升级无需等待人工即可合并。超过您风险阈值的变更会被暂缓处理。Bugbot 和 Security Agent 的发现项会纳入这一决策，确保高风险变更不会被轻易放行。

分派给合适的审查者。 当 PR 需要人工处理时，Approval Agents 会根据其涉及的代码库部分，按照您为各区域定义的分派策略分配审查者。变更会直接交给负责该代码的团队，而不是进入共享队列。

#让审查贴近代码

AI 代码审查让团队在智能体不断扩大变更规模、加快变更速度时守住质量门槛。真正有效的版本具备代码库上下文、收敛的评论策略，以及能跟踪发现项是否被修复的指标。

审查应该尽可能贴近代码产生的位置，沿用同样的规则和同样的修复路径。为一个繁忙的代码仓库启用 Bugbot，在 Bugbot 自动化 中观察一周的解决率，然后再决定哪些类别值得增加覆盖量。