Cursor Bugbot 大提速：AI 代码审查开始进入可落地阶段

Cursor 在 2026 年 6 月 10 日更新 Bugbot：平均审查时间从约 5 分钟降到约 90 秒，单次运行成本下降约 22%，每次审查平均发现 bug 数从 0.56 提升到 0.62，并支持在 push 前通过 /review 触发审查、以及只审查上次审查后的新增变化。AI 代码审查正在从“好玩的演示”走向团队可落地的工程流程。

摘要：Bugbot 提速为什么重要

AI 代码审查过去最大的问题，不是“模型能不能看懂代码”，而是能不能进入真实团队节奏。一次 Pull Request 审查如果要等十几分钟、输出一堆泛泛建议、每次 push 又把旧代码重新翻一遍，团队很快就会关闭它。

Cursor 这次对 Bugbot 的更新，关键不只是宣传“更强”。官方在 2026 年 6 月 10 日给出了几组具体数据：平均审查时间从约 5 分钟降到约 90 秒；每次审查平均发现 bug 数从 0.56 提升到 0.62；单次运行成本下降约 22%；还新增了 push 前通过 /review 触发 Bugbot 与 Security Review 的入口，并支持只审查上一次审查后的新增变化。

这些变化说明 AI 代码审查开始进入可落地阶段。它不再只是 PR 之后的慢速机器人，而可以变成开发者 push 前的自检、PR 中的增量质量门、团队规则执行器，以及 Cursor 编辑器和云端 agent 之间的修复闭环。

如果你正在比较 AI 编程工具，可以继续阅读站内 Cursor 教程、Claude Code 教程、Codex 实战内容 和 AI 工作流教程。

Cursor Bugbot 是什么

它是面向 PR 的 AI 代码审查工具

Cursor 官方文档把 Bugbot 定位为会审查 Pull Request、识别 bug、安全问题和代码质量问题的工具。它会分析 PR diff，在发现问题时留下带解释和修复建议的评论。

这和 IDE 内补全不同。Cursor 编辑器主要帮助你写代码，Bugbot 则更接近团队交付流程：当代码进入 PR，它作为一个自动审查者，提前发现逻辑 bug、边界问题、安全风险和缺少测试的地方。

它如何触发

按照 Cursor 文档，Bugbot 可以在每次 PR 更新时自动运行，也可以通过评论 cursor review 或 bugbot run 手动触发。连接 GitHub 或 GitLab 仓库后，可以在 Cursor dashboard 中选择具体仓库启用。

这意味着团队可以按仓库、按成员、按 PR 状态设计触发策略，而不是所有改动都无差别跑一遍。

它如何和 Cursor 编辑器形成闭环

Bugbot 评论中可以提供 Fix in Cursor 或 Fix in Web 入口，把发现的问题带回 Cursor 或 cursor.com/agents。这样审查不只是“指出问题”，而是能进入修复上下文。

Cursor 文档还提到 Bugbot Autofix：当 Bugbot 在 PR 审查中发现问题时，可以自动启动 Cloud Agent 来分析和修复，并按设置推到原分支或新分支。这个能力很有想象空间，但高风险团队应先关闭或只允许新分支模式，避免自动修改生产分支。

这次大提速到底更新了什么

平均审查时间降到约 90 秒

Cursor changelog 写明，Bugbot 平均审查时间现在约 90 秒，之前约 5 分钟。对团队来说，90 秒和 5 分钟的差距很现实：前者可以进入开发者等待窗口，后者更像异步后台任务。

如果 AI review 能在开发者切换上下文前返回，修复成本会明显降低。开发者还记得刚才改了什么，PR 还没有堆积太多讨论，问题也更容易当场修掉。

每次审查发现 bug 数提升

官方数据称 Bugbot 每次审查平均发现 bug 数从 0.56 提升到 0.62，大约提升 10%。这个数字看似不大，但放到大量 PR 上就有意义。AI 审查真正的价值不是替代所有 reviewer，而是在高频 PR 中提前捞出一部分真实问题。

单次运行成本下降约 22%

Cursor 同时表示 Bugbot 每次运行成本降低约 22%。这对团队落地很关键。AI 代码审查如果按使用量计费，成本波动会直接影响是否能默认开启。更低成本意味着团队更可能把它放进常规 PR 流程，而不是只在少数重点 PR 上手动运行。

Composer 2.5 成为底层动力

Cursor changelog 提到，这些性能提升来自 Composer 2.5 的训练进展，现在 Bugbot 由 Composer 2.5 驱动；同时 Bugbot 会遵守 model block lists，速度和效果会因配置不同而变化。文章里的数据应理解为 Cursor 官方公布的整体表现，而不是每个仓库都一定得到完全相同结果。

新增的 pre-push /review 为什么关键

审查从 PR 后移到 push 前

过去很多 AI code review 只在 PR 创建后运行。问题是，一旦进入 PR，开发者已经把代码推上去了，后续修复又要产生新 commit、触发新 CI、再次等待审查。

Cursor 现在允许在 push 前通过 /review 运行 Bugbot 和 Security Review。你可以让它提示选择要运行的 agent，也可以直接使用 /review-bugbot 或 /review-security。

它能和 GitHub/GitLab 端的 Bugbot 同步

官方说明，/review 会和 GitHub/GitLab 上的 Bugbot 同步。如果你在本地或 agent 中对同一份 diff 做过审查，之后打开 PR 时，Bugbot 可以识别同一 patch ID，跳过重复审查并留下说明。

这解决了一个实际痛点：本地自检和远端 PR 审查如果互不相认，会浪费成本、制造重复评论。同步机制让 pre-push review 更适合作为正式 PR 流程的前置环节。

适合放在提交前质量门

对个人开发者来说，/review 可以像“AI 版 git diff 自检”。对团队来说，它可以成为内部约定：涉及支付、权限、数据删除、迁移、并发、缓存、鉴权等高风险改动，push 前先跑一次 Bugbot 或 Security Review。

“只审新变化”解决了什么问题

避免旧代码反复被翻出来

Cursor changelog 提到，Bugbot 默认每次 push 都会重新审查整个 PR diff，这可能导致它在已经审查过、甚至已经认可的代码上产生新 flag。现在团队可以配置 Bugbot 只审查上次审查后的新增变化，让反馈更聚焦最新修改。

减少噪音和审查疲劳

AI 代码审查最怕噪音。即使某些建议有道理，如果每次 push 都在旧问题上刷屏，开发者会逐渐忽略它。增量审查能减少重复评论，让团队更愿意把 Bugbot 留在默认流程里。

更适合小步提交

现代团队鼓励小 PR、小步提交、快速反馈。Bugbot 只审新变化后，更适合和这种节奏搭配：每次只看新增 diff，快速指出新风险，而不是每轮都重新评估整段历史。

Bugbot Rules：让 AI 审查更像你的团队

用 .cursor/BUGBOT.md 写项目规则

Cursor 文档支持在项目中创建 .cursor/BUGBOT.md 文件，为 Bugbot 提供项目上下文。根目录规则会始终包含，嵌套目录下的规则会根据变更文件向上查找并加入审查上下文。

例如你可以在后端目录写清：修改 API 必须补测试、数据库迁移必须带回滚说明、鉴权逻辑必须覆盖未登录和权限不足场景。这样 Bugbot 不只是泛泛看代码，而是按项目约定审查。

团队规则、仓库规则和用户规则会合并

官方文档说明，当 Team Rules、repository rules、project BUGBOT.md 和 User Rules 同时适用时，Bugbot 会合并它们。应用顺序包括团队规则、仓库规则、项目规则和用户规则。

这对团队治理很有价值：平台团队可以维护组织级安全规则，项目团队维护仓库级业务规则，开发者保留个人偏好。

规则学习降低维护成本

Bugbot dashboard 支持 learned rules。它可以根据团队在 GitHub 上的活动生成规则，也可以通过在 PR 中评论 @cursor remember [fact] 教 Bugbot 记住新规则。规则还带有 analytics，帮助团队观察命中次数、被接受次数和接受率。

CI Check 和合并策略

Bugbot 会发布 Cursor Bugbot check

Cursor 文档写到，Bugbot 会为每次 review run 发布名为 Cursor Bugbot 的 GitHub check。结论包括 success、neutral 和 failure。

默认情况下，Bugbot 发现问题时通常是 neutral，而不是直接阻塞合并。只有当组织可用并启用 fail-on-unresolved-issues 行为时，未解决 findings 才会导致 failing check。

不要误以为 require check 就能阻止所有问题

如果团队只在 branch protection 中 require Cursor Bugbot，它可以确保 Bugbot 运行过，但不一定阻止带有发现的问题合并。想让它成为强质量门，需要明确配置失败策略，并配合人工 reviewer。

建议先从 advisory 模式开始

新团队不要一开始就把 AI review 设成强阻塞。建议先运行两到四周，记录误报率、真实 bug 命中率、修复耗时、成本和开发者接受度。等规则和噪音调好，再考虑对高风险目录启用强 gate。

Bugbot Autofix 应该怎么用

它不是“自动合并”

Bugbot Autofix 可以自动启动 Cloud Agent 修复 Bugbot 发现的问题，并按设置推送到现有分支或新分支。但这不等于应该让 AI 自动合并代码。

优先选择新分支模式

Cursor 文档中，新分支模式被标注为推荐。对团队来说，这更安全：Bugbot 发现问题，Autofix 生成修复分支，人类审查 diff、运行测试，再决定是否合并。

高风险模块先关闭 Autofix

涉及认证、支付、权限、数据删除、加密、部署、迁移脚本的模块，建议先只启用 review，不启用自动修复。AI 可以提示问题，但最终修复应该由熟悉业务边界的人完成。

AI 代码审查为什么开始可落地

速度进入可接受范围

90 秒级别的反馈可以进入开发者日常节奏。它不像静态扫描那样毫秒级，但已经足够作为 PR 前置检查或 PR 更新后的快速反馈。

输出开始贴近真实工程问题

Bugbot 的定位不是格式化代码，而是发现 bug、安全问题和代码质量问题。相比“代码风格建议”，团队更愿意为真实风险付费和等待。

有规则、增量、同步和修复闭环

可落地的 AI 审查不是单点模型能力，而是工作流能力：规则上下文、增量审查、pre-push 自检、PR check、Fix in Cursor、Autofix 和人工审批。Cursor 这次更新补齐了其中几个关键环节。

团队落地清单

第一阶段：只读观察

先在一个非核心仓库启用 Bugbot，运行两到四周，不阻塞合并。记录它发现的问题类型、真实有效比例、误报、重复评论和平均审查时间。

第二阶段：补项目规则

根据团队真实代码约定写 .cursor/BUGBOT.md，不要只依赖默认模型判断。规则应覆盖测试要求、安全禁区、目录约定、错误处理和日志规范。

第三阶段：加入 pre-push /review

让开发者在高风险改动前使用 /review 做自检。这样可以把问题拦在 PR 之前，减少 review 来回。

第四阶段：设置合并策略

当误报率可控后，再考虑对核心仓库或高风险目录启用更强的 check 策略。即便如此，也不要取消人工 reviewer。

第五阶段：谨慎打开 Autofix

先让 Autofix 创建新分支，不要直接推到现有 PR 分支。每次修复都要通过测试、人工审查和回滚评估。

适合优先启用的场景

AI 生成代码比例高的团队

如果团队大量使用 Cursor、Claude Code、Codex、Copilot 或其他 agent 写代码，Bugbot 这类 AI review 工具更有价值。AI 生成代码速度快，但也可能引入跨文件逻辑错误和边界条件遗漏，自动审查可以补一层质量网。

PR 多、review 人手紧张的团队

Bugbot 不能替代 senior reviewer，但可以先过滤一部分常见 bug、缺测试和安全问题，让人类 reviewer 把精力放在架构、业务语义和产品取舍上。

规则明确的业务系统

如果你的项目有清晰规则，例如后端改动必须补测试、API 变更必须更新文档、权限逻辑必须覆盖边界，那么 Bugbot Rules 可以把这些规则显式写入审查流程。

不适合盲目启用的场景

缺少测试和负责人

AI review 不能替代测试体系。如果项目没有稳定 CI，也没有人负责处理反馈，启用 Bugbot 只会增加噪音。

高敏感代码没有边界

如果仓库里包含密钥、客户数据、生产配置或无法外发的敏感代码，先核对 Cursor 的隐私、数据处理和团队设置，再决定是否启用。

把 AI 评论当成绝对结论

Bugbot 会误报，也会漏报。它应该是 reviewer 的辅助输入，而不是最终判决。任何涉及高风险业务的建议都要由人复核。

成本与效果怎么评估

看每个真实 bug 的成本

不要只看单次运行价格。更有意义的是：每月花费、审查 PR 数、真实 bug 数、节省 reviewer 时间、减少线上事故的价值。如果 Bugbot 每月拦下几个高风险 bug，成本可能很容易被覆盖。

看反馈是否被接受

规则 analytics 和团队复盘可以帮助判断 Bugbot 是否有效。如果评论经常被关闭、误报多、开发者不看，就需要调规则、调触发范围或降低努力等级。

看是否减少 review 来回

理想状态不是“评论更多”，而是 PR 来回更少、缺陷更早发现、review 质量更稳定。提速后的 Bugbot 更适合用这个维度评估。

结论：AI 代码审查开始进入工程化阶段

Cursor Bugbot 这次大提速的意义，不只是一个工具变快了。它说明 AI 代码审查正在从慢速、噪音大、像演示的阶段，走向更接近真实工程流程的阶段。

90 秒级反馈、pre-push /review、增量审查、项目规则、PR check、Fix in Cursor 和 Autofix，组合起来构成了一条更完整的 AI 代码质量链路。开发者可以在 push 前自检，团队可以在 PR 中增量审查，维护者可以把规则写进仓库，最后由人类 reviewer 做最终判断。

但可落地不等于可无人值守。AI 代码审查真正成熟的标志，不是它替代人，而是它能在明确边界内稳定减少低级问题，让人类把注意力放在更高价值的判断上。

FAQ

Cursor Bugbot 这次到底快了多少？

Cursor 官方 2026 年 6 月 10 日 changelog 称，Bugbot 平均审查时间从约 5 分钟降到约 90 秒，整体超过 3 倍提速。

Bugbot 发现 bug 的能力也提升了吗？

官方数据称，每次审查平均发现 bug 数从 0.56 提升到 0.62，大约提升 10%。实际效果会因代码库、配置、规则和改动类型不同而变化。

Bugbot 会自动阻止 PR 合并吗？

默认不一定。Bugbot 会发布 Cursor Bugbot check，但发现问题时通常是 neutral。要阻塞合并，需要组织可用并配置 fail-on-unresolved-issues 等策略，同时建议保留人工 reviewer。

/review 和 PR 自动审查有什么区别？

/review 可以在 push 前运行 Bugbot 或 Security Review；PR 自动审查是在 GitHub/GitLab 端对 PR 更新运行。官方说明两者可以通过 patch ID 同步，避免重复审查同一 diff。

Incremental Review 是什么？

它让 Bugbot 只审查上一次 Bugbot 审查后的新增变化，而不是每次 push 都重新审查整个 PR diff。这样可以减少重复评论，让反馈更聚焦。

Bugbot Rules 应该写什么？

建议写项目特有规则，例如后端改动必须补测试、API 变更必须更新文档、安全敏感函数禁止使用、某些目录的审查重点等。规则越贴近项目，AI 审查越有价值。

Bugbot Autofix 可以直接改代码吗？

可以按配置启动 Cloud Agent 修复问题，并推到现有分支或新分支。团队落地时建议优先新分支模式，并要求测试和人工审查。

它能替代人工代码审查吗？

不能。Bugbot 适合提前发现一部分 bug、安全和质量问题，但仍会误报和漏报。人工 reviewer 仍需要负责业务语义、架构判断、风险权衡和最终合并决策。

参考来源

本文事实信息参考 Cursor 官方 Bugbot June 2026 changelog、Bugbot docs、Bugbot product page 和 Cursor pricing page。功能、价格和团队配置可能继续变化，正式启用前请以 Cursor 最新官方页面为准。