Cursor Bugbot 使用指南：AI code review 配置、计费与自动修复

我的看法： 如果团队希望把 PR 中发现的问题接入 Cursor 的修复流程，Bugbot 值得列入候选清单。人工审批和现有自动化检查仍然要保留。使用 Azure DevOps 的团队，应单独评估审查能力，因为该平台不支持 Bugbot Autofix。使用 GitLab 或 Bitbucket 的团队，则应先确认能否接受工具直接修改 PR 分支，再决定是否启用 Autofix。

Cursor Bugbot 的 AI code review 会检查什么？

Bugbot 从拉取请求的 diff，也就是准备合并的代码改动入手，查找 bug、安全问题和代码质量问题。可以把它理解为检查装修工程的验收人员：先看这次改了什么，再根据仓库规则判断这些改动是否符合项目自身的要求。

审查可以在 PR 更新时自动运行，也可以通过评论 cursor review 或 bugbot run 手动触发。PR 中已有的普通评论和行内评论会作为上下文，帮助 Bugbot 纳入此前的反馈。审查结果会解释问题、给出修复建议，并提供链接，让开发者继续在 Cursor 或网页中处理。Bugbot 的工作方式。

实际价值在于更早发现原本可能漏过审查的缺陷，评论数量并不能说明效果。评估一条发现时，要看它是否指出了真实故障、解释了触发条件，并促成有效修复。测试、安全扫描和代码负责人的审查都应继续保留。

如何按仓库配置 Bugbot？

先在 Cursor 集成面板连接代码托管平台，再打开 Automations 中的 Bugbot，为需要审查的仓库启用服务。连接平台和启用仓库是两个独立步骤。Cursor 支持接入 GitHub、GitLab、Bitbucket 和 Azure DevOps Services，也支持文档列出的前三个平台的自托管版本。Bugbot 配置说明。

GitHub

需要 Cursor 管理员权限和 GitHub 组织管理员权限。在 Integrations 中，点击 GitHub 旁的 Connect（连接）；如果已经连接，则选择 Manage Connections（管理连接）。选择 All repositories（所有仓库） 或 Selected repositories（指定仓库），完成连接后返回 Cursor，在 Bugbot 中启用所选仓库。GitHub Enterprise Server 有单独的配置选项卡和网络接入说明。Cursor 的 GitHub 集成文档。

GitLab

接入 GitLab.com 需要 Cursor 管理员权限、GitLab maintainer 权限，以及付费的 GitLab Premium 或 Ultimate 套餐。Cursor 需要使用项目访问令牌，而 GitLab Free 不提供这类令牌。在 Integrations 中选择 Connect（连接） 或 Manage Connections（管理连接），完成 GitLab 安装，再通过 Manage → Sync Repos（管理 → 同步仓库） 同步，之后才能在 Bugbot 中启用仓库。自托管部署有独立的连接说明。Cursor 的 GitLab 集成文档。

Bitbucket

Bitbucket Cloud 目前处于公开测试阶段。先从 Integrations 连接账号并授权 Cursor。工作区还需要安装 Cursor 应用：由 Bitbucket 工作区管理员在 Cursor 中打开 Bitbucket 管理菜单，选择 Install Cursor app（安装 Cursor 应用），并将应用安装到工作区。随后，拥有该工作区访问权限的 Cursor 团队管理员，需要在 Bitbucket 工作区设置中打开 Forge Apps → Cursor，选择 Connect to Cursor（连接到 Cursor），完成团队关联。最后再到 Bugbot 中启用仓库。仅连接个人账号，并不会建立发布审查评论所需的应用身份。Bitbucket Data Center 使用另一套配置流程。Cursor 的 Bitbucket 集成文档。

Azure DevOps

Azure DevOps Services 需要使用 Bugbot 专用的配置流程，并取得 Microsoft Entra 租户管理员同意。由 Project Collection Administrator（项目集合管理员） 连接 Azure DevOps 并为仓库启用 Bugbot；这一步会在组织中创建 Cursor 的服务主体，也就是一个应用身份。对于每个需要审查的项目，项目管理员都必须将该身份加入 Project Administrators（项目管理员），使其能够管理用于触发审查的服务钩子通知。

权限变更可能需要一段时间才会生效。如果配置报错，先解决错误，再重试仓库开关。Bugbot 支持团队仓库，不支持个人范围的仓库。Cursor 的 Azure DevOps Bugbot 配置说明。

设置审查的触发方式

对于每个已启用的仓库，需要决定是随更新触发审查，还是每个 PR 只运行一次，并按需配置作者允许名单或拒绝名单。个人设置还可以将某位作者的审查设为仅在提及时触发、每个 PR 一次，或将草稿 PR 纳入审查。仓库启用后，即使贡献者不属于你的 Cursor 团队，Bugbot 也能审查其提交。仓库与个人设置。

Azure DevOps 的手动触发还有一项条件：评论者的 Azure DevOps 登录邮箱，必须与仓库所属 Cursor 团队中的某个账号匹配。自动审查没有这项限制。Azure DevOps 触发条件。

.cursor/config/bugbot.yaml 应该怎么写？

如果希望审查行为的变更也经过代码审查，就把配置放进仓库。下面是 Cursor 仓库配置文档发布的示例：

# .cursor/config/bugbot.yaml
version: 1

triggers:
  drafts: false
  frequency: everyPush # everyPush | oncePerPr

review:
  effort: default # low | default | high | smart
  smartPrompt: ""
  incremental: true

prSummary:
  mode: comment # disabled | description | comment
  riskScore: true

autofix:
  mode: disabled # disabled | newBranch | existingBranch

按上述路径，从仓库根目录提交并推送这个文件。Bugbot 读取的是 PR 的目标分支（base branch），也就是接收合并的分支，而不是 PR 来源分支中的版本。因此，一次待合并的改动无法改写约束自身的审查配置。可以借助仓库的文件归属机制 CODEOWNERS，指定由谁审查配置变更。

所有字段都是可选的。字段缺失或无效时，会继续向下一优先级的设置来源查找；超过 64 KB 的文件会被忽略。优先级如下：

1. PR 作者针对自己 PR 设置的个人覆盖项。
2. 仓库中的 YAML 文件。
3. 团队和组织在控制面板中的设置。

这意味着，仅检查 YAML 文件，无法确认某位作者最终会使用哪些设置。另外，autofix.mode 可以收紧控制面板允许的行为，但如果面板已关闭 Autofix，它无法将其打开。配置行为与优先级。

示例选择了以评论形式发布摘要，并不代表控制面板中的所有默认值。没有这项覆盖配置时，PR 摘要默认写入描述。增量审查检查的是上次 Bugbot 审查之后的改动。更高的 effort 档位可能会投入更多时间和用量来查找 bug；Smart 则根据你的指令决定投入程度。摘要、增量审查与 effort 设置。

用 BUGBOT.md 写清项目审查规则

将审查者需要了解的项目知识写入 .cursor/BUGBOT.md。根目录下的规则文件始终会被加载。Bugbot 还会从改动文件所在位置向上查找嵌套的 .cursor/BUGBOT.md，因此后端目录可以使用与前端不同的指令。Cursor 编辑器在 .cursor/rules/*.mdc 中的规则不适用于 Bugbot。Bugbot 项目规则。

有效的规则应明确必须始终成立的约束，以及需要警惕的故障。例如，支付团队可以说明：重试操作不得再次向客户扣款。后端团队可以说明：哪些状态变更必须写入审计记录。这些只是建议写入规则的主题，不代表 Bugbot 能发现所有违规情况。

团队规则、项目规则文件、学习得到的规则和手动仓库规则会合并使用。要使用控制面板中的学习规则和手动规则，组织和仓库都必须启用学习功能。指令应尽量聚焦：每条规则超过 30,000 个字符的部分会被截断，合并后的审查规则上限为 100,000 个字符。如需检查实际加载的内容，可以评论 bugbot run verbose=true 或 cursor review verbose=true；回复会列出哪些规则已加载、被截断或被省略。规则与限制。

Bugbot 现在如何计费？

Bugbot 的预算应按用量估算，Autofix 则单独核算。Cursor 目前的表述如下：

以上是当前的 Bugbot 计费条款。不要默认团队的编辑器额度可以支付 Bugbot 审查费用。Autofix 消耗的是 Cloud Agent credits，按现有套餐费率收费。Autofix 计费说明。

五月公布的价格调整，会在现有订阅于 2026 年 6 月 8 日之后的下一次续订时生效。因此，旧版年付订阅在续订之前，可能仍按原有条款执行。Cursor 价格调整公告。

当前 Bugbot 文档没有提供可以直接代入预算的固定单次审查价格。PR 复杂度、审查频率和 effort 设置都会影响实际工作量。服务商公布的平均单次运行成本只能作为参考，不能当作你的仓库必然适用的费率。

评估投入产出时，应将审查费用 + Autofix 费用 + 工程师判断审查结果所花的时间，与团队因此减少的审查和返工成本进行比较。原有的人工审查预算仍然需要保留。决策依据是有效发现和节省的注意力，而不是能否再多一个发表评论的机器人。

Autofix 和 MCP 各需要什么条件？

Autofix 会启动一个 Cloud Agent，让它远程处理代码，修复 Bugbot 发现的问题，并把结果反馈到 PR。使用前必须启用按需用量和存储；Legacy Privacy Mode 不满足这项存储要求。在 Bugbot Automations 中选择受支持的模式即可。Autofix 使用条件。

以上是 Cursor 文档列出的 Autofix 模式。为防止循环运行，现有分支模式下每个 PR 最多尝试 3 次。我的建议是先保持 Autofix 关闭，等团队就生成的修复如何审查达成一致后再启用；GitHub 团队届时可以选择新分支模式，单独检查这些改动。

MCP 是一种让 AI 工具访问其他工具和上下文的协议，可以扩展 Bugbot 的审查流程。配置 MCP 服务器后，在 Automations 中将其工具加入 Bugbot。Bugbot 的 MCP 支持仅限 Team 和 Enterprise 套餐。MCP 可用范围。

Bugbot、CodeRabbit 和 Greptile 怎么选？

选择代码审查工具，首先要看它是否适合团队流程，以及计费方式是否便于管理。下面列出的是公开价格，不是对比测试结果。

来源：Cursor Bugbot、CodeRabbit 定价、Greptile 定价。CodeRabbit 的年付价格是按年结算后折合的每月金额。Greptile credits、Cursor 用量和 CodeRabbit 的已审查文件费用，不能直接等量换算。

从预算结构看，CodeRabbit 是席位订阅费加上可能产生的继续审查费用；Greptile 将席位与 credits 结合；Bugbot 当前则以审查用量为核心变量。仅凭席位价格，无法可靠地判断哪款工具对你的团队最便宜。

更深入的两款产品对比，可阅读 Greptile 与 CodeRabbit 对比。如果还想扩大候选范围，可参考 CodeRabbit 替代方案和适合小团队的 AI 代码审查工具。

哪些团队场景更值得优先尝试？

我会优先考虑那些漏掉缺陷的代价，高于判断一条审查发现所需注意力的场景。下表列出的是潜在用法，按我建议的尝试顺序排列，并非实测结果。

这些示例涉及的审查、上下文、规则和 Autofix 机制，均见 Cursor 的 Bugbot 指南。能发挥多大价值，取决于你的代码和审查者。

围绕 Bugbot，还值得做什么工具？

最值得考虑的方向，是帮助工程负责人看清审查成本与效果。成熟工具已经能提供审查，再做一个评论生成器，吸引力会更难证明。

审查成本与效果台账

平台团队可以开发一个看板，将仓库支出与工程师接受、忽略或修复的问题关联起来，面向工程负责人销售。Greptile Pro 的 $30/席位/月 定价说明代码审查已经是一个成熟的付费产品类别，但并不能证明这些客户愿意为附加工具付费。Greptile 定价。

最小可用版本，可以把审查发现、账单记录和人工标注的有效性合并展示。Cursor 的 Enterprise 审查 API 提供审查分析数据，包括发现的问题和已计费成本；但成本字段可能没有已计费金额。面向非 Enterprise 用户的版本，则需要采用经授权的手动输入，不能默认拥有该 API 的访问权限。Bugbot API 与分析功能。

难点： 评论被标记为已解决，并不等同于发现了有价值的 bug；账单归因不完整，也可能让看板产生误导。我会优先做这个方向，因为它回答了每次续订都会遇到的问题：这款审查工具是否值得付出全部使用成本？

仓库审查策略检查工具

平台工程团队可能需要一个工具，用来检查仓库是否采用了获准的 Bugbot 配置、是否缺少项目规则，以及是否存在未经审查的策略变更。CodeRabbit Team 的月付价格为 $60/开发者/月，说明团队审查管理已经属于付费产品的覆盖范围；但客户是否愿意另购策略工具，仍需验证。CodeRabbit 定价。

最小版本可以读取仓库文件，再生成报告供负责人检查。难点： 个人设置的优先级高于 YAML，因此仅审计文件，无法证明实际生效的审查行为符合要求。应清楚展示这一限制，并在授权访问允许的范围内，将控制面板设置也纳入检查流程。Bugbot 配置优先级。

合并审批的责任必须明确

把 Bugbot 设为必需检查，并不自动意味着存在未解决的问题就会阻止合并。默认情况下，发现问题产生的是 neutral（中性） 结果。将该状态设为必需，只能确保检查已经运行；如果你的组织可以使用 fail-on-unresolved-issues 设置，启用后才会把未解决的问题转为失败状态。依赖分支保护前，应先核对这项设置。Bugbot 检查状态。

我的建议是，把 Bugbot 当作供审查者参考的额外证据。一份没有发现问题的报告，不能证明功能满足需求；自动生成的补丁，也应接受与其他代码同样严格的检查。

下周一就可以这样开始

选择一个仓库，让负责人先明确希望发现哪些故障。由具备相应权限的管理员完成平台连接，为仓库启用 Bugbot，把配置提交到目标分支，并写好聚焦的审查规则。明确预算负责人，将是否启用 Autofix 单独决策。先在日常审查中记录有效发现、被否决的建议，以及评估两者所花的时间，再决定是否扩大使用范围。

如果需要把审查报告或仓库管控接入交付流程，我们可以提供 AI 自动化服务。