---
title: "Bugbot"
description: "基于 Cursor 官方 Bugbot 文档解释自动 PR review、手动触发、rules、autofix、MCP、Admin API、定价和排障。"
verifiedAt: "2026-05-09"
---

Bugbot 是 Cursor 的自动 PR review 产品，用来发现 bug、安全问题和代码质量问题。

> [!NOTE]
> **阅读目标**：读完本章，你应该能把 Bugbot 放进团队 PR 流程，并知道哪些配置会影响 review 范围、autofix、成本和误报控制。

## 1. 它解决什么问题

Bugbot 会分析 PR diff，留下带解释和修复建议的评论。它可以在 PR 更新时自动运行，也可以通过评论手动触发。

| 能力 | 说明 |
| --- | --- |
| 自动 review | 每次 PR update 后运行 |
| 手动触发 | 在 PR 评论 `cursor review` 或 `bugbot run` |
| 读取 PR 评论 | 使用 top-level 和 inline comments 避免重复建议，并延续已有讨论 |
| Fix in Cursor | 把问题直接带回 Cursor |
| Fix in Web | 打开 cursor.com/agents 处理问题 |
| Autofix | 调用 Cloud Agent 修复 Bugbot 找到的问题 |

它不是合并门禁的替代品。商业级流程里，Bugbot 评论要和 CI、human review、security policy、测试和产品验收一起判断。

## 2. 设置入口

先连接代码托管，再到 Bugbot dashboard 对 repo 开启。

| 平台 | 入口 |
| --- | --- |
| GitHub / GitHub Enterprise Server | Cursor dashboard 的 GitHub integration |
| GitLab / GitLab Self-Hosted | Cursor dashboard 的 GitLab integration |
| Bugbot repo 开关 | Cursor Bugbot dashboard |

Individual plan 下，Bugbot 只 review 你自己 author 的 PR。Team 配置下，管理员可以按 repo 启用，并影响所有 enabled repo 的 contributors。

## 3. 个人和团队配置

个人设置常见选项：

- 只在被 mention 时运行。
- 每个 PR 只运行一次，后续 commits 跳过。
- Team member 可对自己的 PR 覆盖 team 默认设置。
- Team member 可开启 draft PR reviews。

Team admin 可设置：

- 每个 repo 是否启用 Bugbot。
- reviewer allow / deny lists。
- 每个 installation 每个 PR 是否只运行一次。
- 团队级 Bugbot rules。
- Autofix 默认行为。

如果团队不先定义“什么问题要挡、什么问题只提示”，Bugbot 很容易变成噪音源。上线时至少要把 blocking / non-blocking 标准写清楚。

## 4. Rules 体系

Bugbot rules 有多层来源。官方顺序是：

1. Team Rules。
2. Repository rules，包括 learned rules 和 manual rules。
3. Project `.cursor/BUGBOT.md`，包括嵌套文件。
4. User Rules。

项目规则建议放在 `.cursor/BUGBOT.md`。Bugbot 总是包含 repo root 的 `.cursor/BUGBOT.md`，并会从 changed files 向上查找更近的 `.cursor/BUGBOT.md`。

```text
project/
  .cursor/BUGBOT.md
  backend/
    .cursor/BUGBOT.md
    api/
      .cursor/BUGBOT.md
  frontend/
    .cursor/BUGBOT.md
```

规则字段通常包含：

| 字段 | 用途 |
| --- | --- |
| Name | 短标题，方便管理 |
| Rule content | 具体检查说明、路径、严重级别和建议动作 |
| Scoped paths | 可选 glob，如 `src/components/**` |

Learned rules（学习规则，Bugbot 从团队历史 PR 行为自动总结的隐式规则）可以从团队 GitHub 活动自动生成，也可以通过 PR 评论 `@cursor remember [fact]` 教 Bugbot 记住新规则。Manual rules（手动规则）则由 dashboard 中人工创建。

## 5. 可落地规则示例

写规则时不要只写“注意安全”。要写触发条件、严重级别、输出要求和例外。

| 场景 | 规则要点 |
| --- | --- |
| 动态执行 | 检测 `eval` / `exec`，要求阻断并给安全替代方案 |
| 许可证 | 修改依赖文件时运行 license scan，拦截 GPL / AGPL 等不允许 license |
| React 老 API | 在前端路径中检查 deprecated lifecycle，并给迁移方向 |
| 后端测试 | 修改 backend / api / server 路径时要求测试变更 |
| 临时注释管理 | 发现待办或修复标记时要求 issue reference 或移除 |

好的 Bugbot 规则应该能被 code reviewer 判断为“可以执行”，而不是风格偏好宣言。

## 6. Autofix

Bugbot Autofix 会启动 Cloud Agent 修复 review 中发现的问题，然后把结果推回现有 branch 或新 branch，并在原 PR 评论结果。

Autofix 模式：

| 模式 | 行为 |
| --- | --- |
| Off | 不自动修复，只保留 Fix in Cursor / Fix in Web |
| Create New Branch | 推荐默认值，修复推到新分支 |
| Commit to Existing Branch | 直接推到 PR branch，同一 PR 最多 3 次避免循环 |
| Use Installation Default | 个人设置沿用组织默认 |

Autofix 使用 Settings -> Models 中的 Default agent model。没设置个人偏好时，Team 用户会 fallback 到 team default model；再没有才回到系统默认。

要求和边界：

- 需要 usage-based pricing。
- 需要启用 storage，Legacy Privacy Mode 下不可用。
- 使用 Cloud Agent credits，按现有 pricing plan 计费。
- 不应让 Autofix 直接绕过测试、human review 或敏感路径审批。

## 7. MCP 和 Admin API

Bugbot 可接入 MCP servers，让 AI tools 参与 review 流程。官方说明中，Bugbot MCP support 只面向 Team 和 Enterprise plans。

Team admins 还可以使用 Bugbot Admin API：

| API 能力 | 用途 |
| --- | --- |
| Toggle repo | 启用或关闭某个 repository 的 Bugbot |
| List repos | 列出团队下 repo 的 Bugbot settings |
| Manage user access | 在 allowlist / blocklist 模式下授权或撤销用户 |

Admin API 使用 team Admin API Key 的 Bearer token，官方当前说明是每 team 每分钟 60 requests。自动化批量启用 repo 前，要先做 dry-run 清单，避免错误开启到不该 review 的仓库。

## 8. 定价和成本边界

官方当前说明：

- Teams 和 Individual plans 都有有限免费 PR review。
- Bugbot Pro 可做 14 天 trial。
- Individual Pro 是每月固定费用，覆盖最多 200 个 PR reviews。
- Team Pro 按 author reviewed PRs 的用户计费。
- 每个 Bugbot license 初始 pooled cap 是每月 200 个 PR。

价格、free tier 和 seat 规则属于高波动事实。做采购、报价或课程截图时，要回到官方 pricing 页面或 dashboard 当前值核对。

## 9. 排障

Bugbot 不工作时先跑可追踪排障：

1. 在 PR 评论 `cursor review verbose=true` 或 `bugbot run verbose=true`，拿 detailed logs 和 request ID。
2. 检查 Bugbot dashboard 中 repo 是否 enabled。
3. 检查 GitHub App 或 GitLab integration 是否已安装并有 repo 权限。
4. 检查个人设置是否开启“only when mentioned”。
5. 检查 team allow / deny list 是否阻止了当前 author。
6. 检查 draft PR 是否被个人设置排除。

给支持或管理员排查时，request ID 比“它没跑”更有价值。

## 10. 上线验收

团队接入前建议留下这些证据：

- 至少一个 test repo 完成自动 review 和手动 `cursor review`。
- `.cursor/BUGBOT.md` 覆盖项目级 review 标准。
- Team Rules 和 repo rules 没有互相冲突。
- Autofix 默认策略明确，推荐先用 Create New Branch。
- usage-based pricing、storage、seat cap 和 monthly PR cap 已确认。
- verbose request ID 可被管理员定位。
- Bugbot findings 不直接作为 merge 条件，仍由 CI 与 human review 兜底。

<details>
<summary>深读：Bugbot 的价值在规则质量，不在“多一个机器人”</summary>

如果团队没有沉淀 review 标准，Bugbot 只能给通用建议。真正值得上线的是把团队已经反复人工指出的问题写进 Team Rules、repository rules 和 `.cursor/BUGBOT.md`，让它在每个 PR 里稳定执行。
</details>

## 本章自检

1. Bugbot 是自动运行、手动触发，还是两者都启用？
2. 规则来源和应用顺序是否清楚？
3. Autofix 是 off、新分支还是现有分支？
4. 成本、seat、PR cap 和 storage 条件是否已经确认？
5. 排障时是否能拿到 verbose request ID？

通过标准：你能把一个 repo 接入 Bugbot，并写出包含 rules、autofix、成本、排障和合并边界的团队 SOP。

## 官方来源

- [Cursor Bugbot](https://cursor.com/docs/bugbot.md) —— 官方 Bugbot、rules、autofix、MCP、Admin API、pricing 和 troubleshooting。
- [Cursor Help: Bugbot](https://cursor.com/help/ai-features/bugbot.md) —— 官方帮助页中的设置、触发和常见问题。
- [Cursor GitHub Integration](https://cursor.com/docs/integrations/github.md) —— 官方 GitHub / GHES 集成。
- [Cursor GitLab Integration](https://cursor.com/docs/integrations/gitlab.md) —— 官方 GitLab / self-hosted GitLab 集成。
- [Cursor MCP](https://cursor.com/docs/mcp.md) —— 官方 MCP 背景。

## 接下来去哪

<Cards>
  <Card title="Security Review" description="继续学习 Cursor 安全审查和团队安全流程。" href="/docs/cursor/official/04-cloud-agents/56-security-review" />
  <Card title="Cloud Agent Capabilities" description="回看 Bugbot Autofix 背后的 Cloud Agent 能力。" href="/docs/cursor/official/04-cloud-agents/52-capabilities" />
</Cards>
