《Cursor文档》-Bugbot

Bugbot 会评审 PR，并识别 bug、安全问题和代码质量问题。

配置自动化中的 Bugbot。

Bugbot 在 PR 中添加评论

工作原理¶

Bugbot 会分析 PR diff，并留下说明和修复建议。它会在每次 PR 更新时自动运行，也可手动触发。

• 每次 PR 更新时都会运行自动评审
• 在任意 PR 中评论 cursor review 或 bugbot run 即可手动触发
• 使用现有 PR 评论作为上下文：读取关联的 PR 评论 (顶层评论和行内评论) ，避免重复建议，并参考之前的反馈
• 在 Cursor 中修复链接会直接在 Cursor 中打开问题
• 在网页端修复链接会直接在 cursor.com/agents 中打开问题

设置¶

通过 Cursor 仪表盘连接仓库，即可开始使用 Bugbot。

• GitHub (包括 GitHub Enterprise Server) ：请参阅 GitHub 集成页面
• GitLab (包括 GitLab Self-Hosted) ：请参阅 GitLab 集成页面
• Bitbucket (包括 Bitbucket Data Center) ：请参阅 Bitbucket 集成页面
• Azure DevOps (Azure DevOps Services，有限可用)：请参阅 Azure DevOps 集成页面

连接后，打开自动化中的 Bugbot，在特定仓库中启用它。

CI 检查状态¶

Bugbot 会为每次评审运行发布状态。在 GitHub 上，它会显示为名为 Cursor Bugbot 的检查；在 Bitbucket 上，则显示为键为 cursor-bugbot 的构建状态。在 Azure DevOps 上，它会显示为上下文为 cursor-bugbot/review 的状态。状态可能有以下结论：

• success：Bugbot 未发现问题，且之前的运行没有遗留未解决的 Bugbot 评论。
• neutral：Bugbot 发现了问题、运行被较新的 commit 取消，或 Bugbot 遇到内部错误。这是 Bugbot 报告发现结果时的默认结论。
• failure：Bugbot 发现了问题，且该检查配置为在存在未解决问题时失败。

如果使用分支保护，请将 Bugbot 检查或构建状态设为必需，以确保 Bugbot 在合并前运行。仅将该状态设为必需不会因发现结果而阻止合并，因为发现结果默认使用 neutral。如果你的组织支持“存在未解决问题时失败”行为，请启用该功能，使未解决的发现结果产生失败状态。Bugbot 不会生成 skipped 结论。

启用 Bugbot Autofix 后，GitHub 还可能显示单独的 Cursor Bugbot Autofix 检查。该检查只会使用 success 或 neutral。

配置¶

个人¶

代码仓库设置¶

在安装列表中，按代码仓库启用或禁用 Bugbot。Bugbot 仅会在您创建的 PR 上运行。

个人设置¶

• 仅在通过评论 cursor review 或 bugbot run 提及时运行
• 每个 PR 仅运行一次，跳过后续提交

团队¶

代码仓库设置¶

团队用户和管理员可按代码仓库启用 Bugbot、配置审阅人允许/拒绝列表，并设置：

• 每次安装中，每个 PR 仅运行一次，跳过后续提交

Bugbot 会为已启用代码仓库的所有贡献者运行，不受团队成员身份影响。

个人设置¶

团队成员可为自己的 PR 覆盖这些设置：

• 仅在通过评论 cursor review 或 bugbot run 提及时运行
• 每个 PR 仅运行一次，跳过后续提交
• 在草稿 PR 上启用评审，将草稿 PR 纳入自动评审

企业版¶

代码仓库设置¶

企业版管理员可按代码仓库启用 Bugbot、配置审阅人允许/拒绝列表，并设置：

• 每次安装中，每个 PR 仅运行一次，跳过后续提交

Bugbot 会为已启用代码仓库的所有贡献者运行，不受团队成员身份影响。

个人设置¶

企业版用户可为自己的 PR 覆盖这些设置：

• 仅在通过评论 cursor review 或 bugbot run 提及时运行
• 每个 PR 仅运行一次，跳过后续提交
• 在草稿 PR 上启用评审，将草稿 PR 纳入自动评审

使用分析¶

打开 自动化中的 Bugbot，查看评审活动和结果。

API¶

企业版团队可使用 Bugbot API 触发评审并获取每次评审的使用分析数据。在 Cursor Dashboard → API Keys 中创建 API 密钥，并通过 Basic 认证进行身份验证。

触发评审¶

/bugbot/review

将 PR 或合并请求的 Bugbot 评审加入队列。评审加入队列后，请求即会返回；评审将异步运行。

需要具有 admin:* 作用域的 API 密钥。每个团队对此端点的请求上限为每分钟 30 次。

将 dryRun 设为 true，即可运行完整分析流程，而不发布评审评论、行内评论、检查或产生其他 SCM 副作用。Dry-run 评审仍会保存发现结果，并按正常评审计费。可通过 GET /analytics/team/bugbot-reviews 获取这些评审。Dry-run 请求另有每个团队每分钟 10 次的限制。

请求正文¶

prUrl 字符串 (必填)

完整的 GitHub PR 或 GitLab 合并请求 URL。

dryRun 布尔值 (可选)

设为 true 时，运行分析并保存发现结果，但不会向 SCM 提供商发布任何内容。默认值：false。

curl --request POST \
  --url https://api.cursor.com/bugbot/review \
  -u YOUR_API_KEY: \
  --header 'Content-Type: application/json' \
  --data '{
    "prUrl": "https://github.com/your-org/your-repo/pull/42"
  }'

curl --request POST \
  --url https://api.cursor.com/bugbot/review \
  -u YOUR_API_KEY: \
  --header 'Content-Type: application/json' \
  --data '{
    "prUrl": "https://github.com/your-org/your-repo/pull/42",
    "dryRun": true
  }'

响应：

{
  "outcome": "success",
  "message": "Bugbot review queued",
  "request_id": "6e0d261c-86a2-4383-89f0-9162c1c10662",
  "dry_run": false
}

Dry-run 响应中会使用 "message": "Bugbot dry-run review queued" 和 "dry_run": true。

请保存 request_id，以便在使用分析端点中匹配已完成的评审。

如果 Bugbot 无法评审该 PR，端点会返回 400 Bad Request 及原因：

{
  "outcome": "error",
  "message": "Bugbot is disabled for this repository"
}

评审使用分析¶

/analytics/team/bugbot-reviews

每项已完成的 Bugbot 评审返回一条记录，包括已评审的提交、发现项数量、计费费用以及每个发现项的解决状态数据。

包括已发布的评审和 Dry-run 评审。已发布的发现项通过 comment_id 和 resolution_status 标识。由于不会向 SCM 发布任何内容，Dry-run 发现项会改为返回 title、description 和 locations。

需要具有 read:* 范围的 API 密钥。

查询参数¶

startDate string (可选)

使用分析时间范围的开始时间。默认值为 7 天前。请参阅 日期格式。

endDate string (可选)

使用分析时间范围的结束时间。默认值为当前时间。请参阅 日期格式。

repo string (可选)

代码仓库筛选条件，格式为 host/owner/repo。协议和 .git 后缀均可省略。

prNumber number (可选)

PR 或合并请求编号。

page number (可选)

分页页码。默认值：1。

pageSize number (可选)

每页评审数量。默认值：100，最大值：250。

dryRun boolean (可选)

仅筛选 Dry-run (true) 或已发布 (false) 评审。

curl --get https://api.cursor.com/analytics/team/bugbot-reviews \
  -u YOUR_API_KEY: \
  --data-urlencode 'startDate=2026-06-01' \
  --data-urlencode 'endDate=2026-06-29' \
  --data-urlencode 'repo=github.com/your-org/your-repo' \
  --data-urlencode 'prNumber=42' \
  --data-urlencode 'page=1' \
  --data-urlencode 'pageSize=100'

curl --get https://api.cursor.com/analytics/team/bugbot-reviews \
  -u YOUR_API_KEY: \
  --data-urlencode 'dryRun=true' \
  --data-urlencode 'repo=github.com/your-org/your-repo' \
  --data-urlencode 'prNumber=42'

回复 (已发布的评审) ：

{
  "data": [
    {
      "request_id": "6e0d261c-86a2-4383-89f0-9162c1c10662",
      "timestamp": "2026-06-29T19:42:18.000Z",
      "repo": "github.com/your-org/your-repo",
      "repo_node_id": "R_kgDOABCDEF",
      "pr_number": 42,
      "commit_sha": "9f3c2a1b7d8e4f5061728394a5b6c7d8e9f0a1b2",
      "bugs_found": 2,
      "cost_cents": 42.5,
      "dry_run": false,
      "publication_status": "posted",
      "bugs": [
        {
          "comment_id": "2147483999",
          "resolution_status": "resolved",
          "severity": "high"
        },
        {
          "comment_id": "2147484000",
          "resolution_status": "unresolved",
          "severity": "medium"
        }
      ]
    }
  ],
  "pagination": {
    "page": 1,
    "pageSize": 100,
    "totalItems": 1,
    "totalPages": 1,
    "hasNextPage": false,
    "hasPreviousPage": false
  },
  "params": {
    "metric": "bugbot-reviews",
    "teamId": 12345,
    "startDate": "2026-06-01",
    "endDate": "2026-06-29",
    "repo": "github.com/your-org/your-repo",
    "prNumber": 42,
    "page": 1,
    "pageSize": 100
  }
}

响应 (Dry-run 评审) ：

{
  "data": [
    {
      "request_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "timestamp": "2026-06-29T20:15:03.000Z",
      "repo": "github.com/your-org/your-repo",
      "repo_node_id": "R_kgDOABCDEF",
      "pr_number": 42,
      "commit_sha": "9f3c2a1b7d8e4f5061728394a5b6c7d8e9f0a1b2",
      "bugs_found": 1,
      "cost_cents": null,
      "dry_run": true,
      "publication_status": "dry_run",
      "bugs": [
        {
          "comment_id": null,
          "resolution_status": null,
          "severity": "medium",
          "title": "Unbounded retry loop",
          "description": "retry() recurses without a ceiling.",
          "locations": [
            { "file": "src/net.ts", "start_line": 5, "end_line": 9 }
          ]
        }
      ]
    }
  ],
  "pagination": {
    "page": 1,
    "pageSize": 100,
    "totalItems": 1,
    "totalPages": 1,
    "hasNextPage": false,
    "hasPreviousPage": false
  },
  "params": {
    "metric": "bugbot-reviews",
    "teamId": 12345,
    "startDate": "2026-06-01",
    "endDate": "2026-06-29",
    "repo": "github.com/your-org/your-repo",
    "prNumber": 42,
    "dryRun": true,
    "page": 1,
    "pageSize": 100
  }
}

repo_node_id、pr_number、commit_sha、cost_cents、bugs[].comment_id、bugs[].resolution_status 和 bugs[].severity 在不可用时可能为 null。当该次评审不单独计费时，cost_cents 为 null。对于 Dry-run 评审，发现的内容由 bugs[].title、bugs[].description 和 bugs[].locations 承载。Dry-run 发现的 comment_id 和 resolution_status 均为 null，因为不会向 SCM 发布任何内容。

触发并获取评审¶

1. 使用 PR URL 调用 POST /bugbot/review。传入 "dryRun": true 可在不向 SCM 发布内容的情况下进行分析。
2. 保存返回的 request_id。
3. 轮询 GET /analytics/team/bugbot-reviews，按 repo 和 prNumber 进行筛选。如果触发的是 Dry-run 评审，请使用 dryRun=true。
4. 查找 request_id 与触发响应中的 request_id 匹配的项目。

评审进入队列后，使用分析数据可能需要短暂等待才能提供。

增量评审¶

默认情况下，Bugbot 仅评审自上次 Bugbot 评审以来的更改。在 Bugbot Automations 中关闭增量评审，即可在每次推送时评审整个 PR 的 diff。

Effort 级别¶

Effort 级别决定 Bugbot 在评审期间投入多少时间进行推理。更高的 effort 级别可发现更多缺陷，但每次评审可能耗时更长，且消耗更多用量。

可选择以下 effort 级别：

• 默认值：兼顾效率与速度。评审成本更低，但 Bugbot 可能发现较少缺陷。
• 高：投入更多时间进行推理。评审成本更高、耗时更长，但 Bugbot 可能发现更多缺陷。
• 自定义：可描述 Bugbot 应在何种情况下使用更长、更深入的评审。Cursor 会根据你的指示动态设置 effort 级别。

Effort 级别仅适用于按用量计费的 Bugbot 方案。

规则¶

通过团队规则、代码仓库规则和项目 .cursor/BUGBOT.md 文件来指导评审。

团队规则¶

团队管理员可以在 Bugbot Automations 中创建适用于团队内所有代码仓库的规则。这些规则适用于每个已启用的代码仓库，便于贯彻组织范围内的标准。

当团队规则、代码仓库规则和项目规则文件均适用时，Bugbot 会将它们合并为一个评审规则块。合并顺序：团队规则 → 项目 .cursor/BUGBOT.md (包括嵌套文件) → 已学习规则 → 手动规则。

规则限额¶

每条规则纳入评审时最多保留 30,000 个字符。Bugbot 在一次评审中纳入的规则总长度上限为 100,000 个字符。超过该总上限时，部分规则可能会被省略。必需的团队规则优先于非必需规则。

查看评审使用的规则¶

在 PR 中评论 bugbot run verbose=true 或 cursor review verbose=true。Bugbot 会发布一个表格，列出该次运行包含的所有规则，并标记被截断或省略的规则。

代码仓库规则¶

项目规则¶

创建 .cursor/BUGBOT.md 文件，为评审提供项目专属的上下文。Bugbot 始终会包含根目录中的 .cursor/BUGBOT.md 文件，以及从修改的文件向上遍历时找到的其他文件。

project/
  .cursor/BUGBOT.md          # 始终包含（项目范围的规则）
  backend/
    .cursor/BUGBOT.md        # 评审后端文件时包含
    api/
      .cursor/BUGBOT.md      # 评审 API 文件时包含
  frontend/
    .cursor/BUGBOT.md        # 评审前端文件时包含

Cursor 项目规则 (.cursor/rules/ 中的 *.mdc 文件) 不会应用于 Bugbot 运行。

已学习规则¶

在 Bugbot 代码仓库规则中，为您的组织和代码仓库启用学习功能。

规则会根据团队在该代码仓库的 GitHub 活动自动生成，也可以通过从代码仓库历史记录中手动回填生成。

您也可以在任何 PR 中评论 @cursor remember [fact]，直接教 Bugbot 学习新规则。Bugbot 会将该事实保存为已学习规则，并将其应用于后续评审。

随着对团队活动的不断了解，Cursor 会自动启用或禁用规则。

手动规则¶

在 Bugbot 代码仓库规则中，您可以为各个代码仓库创建手动规则。

规则使用分析¶

Bugbot 规则的使用分析可反映其在实际 PR 中的表现：

示例¶

安全性：标记所有对 eval() 或 exec() 的使用¶

如果任意修改的文件包含字符串模式 /\beval\s*\(|\bexec\s*\(/i，则：
- 添加一个阻塞性 Bug，标题为“危险的动态执行”，正文为：
  “发现使用了 eval/exec。请替换为安全的替代方案，或通过详细注释和测试说明其合理性。”
- 将该 Bug 分配给 PR 作者。
- 添加“security”标签。

开源许可证：禁止引入不允许的许可证¶

如果 PR 修改了依赖文件（package.json、pnpm-lock.yaml、yarn.lock、requirements.txt、go.mod、Cargo.toml），则：
- 运行内置的许可证扫描。
- 如果任何新增或升级的依赖项的许可证属于 {GPL-2.0, GPL-3.0, AGPL-3.0}，则：
  - 添加一个阻塞性 Bug，标题为“不允许的许可证”
  - 在 Bug 正文中列出违规包的名称、版本和许可证
  - 添加“compliance”和“security”标签

语言规范：标记 React componentWillMount 的使用¶

对于 React 项目中匹配 **/*.{js,jsx,ts,tsx} 的文件：
如果修改的文件包含 /componentWillMount\s*\(/，则：
- 添加一个阻塞性 Bug，标题为“已弃用的 React 生命周期方法”
- 正文：“请使用 constructor 或 useEffect 替换 componentWillMount。参阅 React 文档。”
- 建议提供将副作用迁移到 useEffect 的 Autofix 代码片段。

规范：后端更改必须包含测试¶

如果 PR 修改了 {server/**, api/**, backend/**} 中的文件，且 {**/*.test.*, **/__tests__/**, tests/**} 中没有任何更改，则：
- 添加一个阻塞性 Bug，标题为“后端更改缺少测试”
- 正文：“此 PR 修改了后端代码，但未包含相应的测试。请添加或更新测试。”
- 添加“quality”标签

代码风格：禁止 TODO 注释¶

如果任意修改的文件包含 /(?:^|\s)(TODO|FIXME)(?:\s*:|\s+)/，则：
- 添加一个非阻塞性 Bug，标题为“发现 TODO/FIXME 注释”
- 正文：“请将 TODO/FIXME 替换为已跟踪的 issue 引用，例如 `TODO(#1234): ...`，或将其删除。”
- 如果 TODO 已引用符合 /#\d+|[A-Z]+-\d+/ 的 issue 模式，则自动将该 Bug 标记为已解决。

在智能体中运行¶

推送代码前，在智能体中使用 /review-bugbot 或 /review 技能运行 Bugbot。

评审的 diff： 默认情况下，/review-bugbot 会评审当前分支的更改：相对于基准分支的所有更改，包括已提交和未提交的更改。如需更聚焦的反馈，可要求它仅评审未提交的更改。

对比的分支： /review-bugbot 会与你的默认基准分支对比。如果你的基准分支不是默认分支 (例如 main) ，请告诉智能体要对比的分支，或让它根据上下文推断。

与 PR 保持同步¶

/review-bugbot 评审会与已连接的 SCM (GitHub、GitLab 或 Bitbucket) 中的 Bugbot 保持同步。

/review-bugbot 会在后台存储已评审 diff 的补丁 ID。当 SCM 中的 Bugbot 发现具有相同补丁 ID 的 diff 时，会跳过评审，并留下一条评论，说明该 diff 已被评审。

常见用法是：运行 /review-bugbot，然后针对相同的 diff 创建 PR，Bugbot 会识别该评审并跳过远程 PR 评审。

/review 和 /review-bugbot 可在 Cursor 3.7+ 及 cursor.com/agents 中使用。CLI 支持即将推出。

Autofix¶

Bugbot Autofix 会自动启动一个云端代理，修复 PR 评审中发现的缺陷。

工作原理¶

当 Bugbot 在 PR 评审中发现缺陷时，可自动：

1. 启动云端代理，分析并修复报告的问题
2. 将修复推送到现有分支或新分支 (取决于你的设置)
3. 在原 PR 中发布包含结果的评论

配置¶

在 Bugbot Automations 中配置 Autofix 行为。

个人¶

个人用户可以在 Bugbot 个人设置中配置 Autofix 偏好：

• 使用安装默认值 — 遵循组织的设置
• 关闭 — 禁用 Autofix；使用“Fix in Cursor”或“Fix in Web”链接手动修复
• 创建新分支 (推荐) — 将修复推送到新分支
• 提交到现有分支 — 将修复推送到您的分支 (为防止循环，每个 PR 最多尝试 3 次)

对于您自己的 PR，个人设置会覆盖团队默认值。

团队¶

团队管理员可以为 GitHub 组织中的所有团队成员设置默认 Autofix 模式：

• 关闭 — 默认禁用 Autofix
• 创建新分支 (推荐) — 将修复推送到团队成员的新分支
• 提交到现有分支 — 直接将修复推送到 PR 分支 (为防止循环，每个 PR 最多尝试 3 次)

团队成员可在个人设置中覆盖这些默认值。

Autofix 使用您在 设置 → 模型 中指定的默认智能体模型。如果您尚未设置个人模型偏好，Autofix 会回退到团队默认模型 (如果您属于某个团队) ，否则使用系统默认模型。

要求¶

Autofix 需要：

• 启用按需用量计费
• 启用存储 (旧版隐私模式下不可用)

计费¶

Autofix 使用云端代理额度，并按您当前方案的费率计费。云端代理的计费方式遵循您现有的定价方案。

MCP 支持¶

Bugbot 可与你的 MCP 服务器集成，让 AI 工具能够直接与 Bugbot 交互。使用 MCP 服务器提供额外工具，帮助引导 Bugbot 的评审流程。

快速入门：

1. 按照 MCP 文档中的说明设置 MCP 服务器。
2. 将工具添加到 自动化中的 Bugbot。

MCP 支持仅适用于团队版和企业版方案。

管理员配置 API¶

团队管理员可使用 Bugbot Admin API 管理仓库，并控制哪些用户可以使用 Bugbot。该 API 可用于自动化仓库管理、在多个仓库中启用 Bugbot，或将用户预配与内部工具集成。

身份验证¶

所有端点均要求通过 Bearer token 提供团队 Admin API Key：

Authorization: Bearer $API_KEY

创建 API 密钥：

1. 前往 Cursor 仪表盘中的 API 密钥
2. 点击 新建 API 密钥
3. 保存 API 密钥

所有端点的速率限制均为每个团队每分钟 60 次请求。

启用或禁用代码仓库¶

使用 /bugbot/repo/update 端点为代码仓库启用或禁用 Bugbot：

curl -X POST https://api.cursor.com/bugbot/repo/update \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "repoUrl": "https://github.com/your-org/your-repo",
    "enabled": true,
    "manualTriggerOnly": false
  }'

参数：

• repoUrl (string，必填) ：代码仓库的完整 URL
• enabled (boolean，必填) ：true 表示启用 Bugbot，false 表示禁用 Bugbot
• manualTriggerOnly (boolean，可选) ：为 true 时，Bugbot 不会在该代码仓库的 PR 更新后自动运行。手动触发方式 (如评论 cursor review 或 bugbot run) 仍然有效。

由于缓存，通过 API 所做的更改可能需要稍等片刻才会显示在自动化 UI 中。API 响应显示的是数据库中的当前状态。

列出仓库¶

使用 /bugbot/repos 端点列出团队中所有仓库及其 Bugbot 设置：

curl https://api.cursor.com/bugbot/repos \
  -H "Authorization: Bearer $API_KEY"

响应中包含各代码仓库的启用状态、仅手动设置以及时间戳。

管理用户访问权限¶

使用 /bugbot/user/update 端点，控制哪些 GitHub、GitLab 或 Bitbucket 用户可以使用团队的 Bugbot 许可证。企业可借此将 Bugbot 的许可证配置与内部访问请求工具集成。

前提条件¶

调用此端点前，请在团队 Bugbot 设置中启用允许列表或阻止列表模式：

• 允许列表模式 (“仅…”) ：只有列表中的用户可以使用 Bugbot
• 阻止列表模式 (“除…以外的所有人”) ：除列表中的用户外，所有用户都可以使用 Bugbot

如果两种模式都未启用，API 将返回错误。

添加或移除用户¶

curl -X POST https://api.cursor.com/bugbot/user/update \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "username": "octocat",
    "allow": true
  }'

参数：

• username (string，必填) ：GitHub、GitLab 或 Bitbucket 用户名 (不区分大小写)
• allow (boolean，必填) ：是否授予或撤销访问权限

allow 的行为取决于当前模式：

响应：

{
  "outcome": "success",
  "message": "Updated team-level allowlist for @octocat",
  "updatedTeamSettings": true,
  "updatedInstallations": 0
}

允许列表在团队级别存储，适用于该团队拥有的所有 GitHub、GitLab 和 Bitbucket 安装实例。用户名会统一转换为小写。

示例：通过内部工具为用户配置访问权限¶

将此 API 连接到内部访问权限申请门户。员工申请 Bugbot 访问权限时，门户会调用该 API 将其添加。员工离职或失去访问权限时，门户会调用该 API 将其移除。

授予访问权限：

curl -X POST https://api.cursor.com/bugbot/user/update \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"username": "employee-scm-username", "allow": true}'

撤销访问权限：

curl -X POST https://api.cursor.com/bugbot/user/update \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"username": "employee-scm-username", "allow": false}'

定价¶

Bugbot 采用按用量计费。

Bugbot 定价已于 2026 年 5 月更新。有关详情，请参阅公告博文。如果您仍在使用旧的按席位计费方案，请参阅旧版 Bugbot 定价。

计费¶

个人版¶

按用量计费¶

Bugbot 包括：

• 为您所有仓库中的 PR 提供评审
• 使用 Bugbot 规则
• 设置 Bugbot 进行评审时使用的 effort 级别

Bugbot 会先使用套餐包含的用量，之后额外的评审将通过按需消费计费。当前费率请参阅定价页面。

开始使用¶

请在账户设置中订阅。

团队¶

按用量计费¶

Bugbot Teams 包括：

• 为所有 PR 提供代码评审
• 使用分析和报告
• 设置 Bugbot 进行评审时使用的 effort 级别
• 高级规则和设置

Bugbot Teams 通过按需消费计费。当前费率请参阅定价页面。

开始使用¶

请在团队仪表盘中订阅以启用计费。

疑难排查¶

如果 Bugbot 无法正常运行：

1. 通过添加评论 cursor review verbose=true 或 bugbot run verbose=true 来启用详细模式，查看详细日志、已加载的 Bugbot 规则和请求 ID
2. 检查权限，确认 Bugbot 有权访问代码仓库
3. 验证安装，确认已安装并启用代码仓库提供商集成

报告问题时，请附上详细模式提供的请求 ID。

常见问题¶

Bugbot 会读取 PR 评论吗？¶

会。Bugbot 会读取已连接提供商中的 PR 顶层评论和行内评论，并在评审时将其作为上下文。这有助于避免提出重复建议，也让 Bugbot 能够参考审阅人此前的反馈。

如何查看 Bugbot 使用了哪些规则？¶

在 PR 中评论 bugbot run verbose=true 或 cursor review verbose=true。Bugbot 会发布一个表格，列出本次运行包含的所有规则，并标记被截断或省略的规则。如果规则缺失或被截断，请参阅规则限额。

Bugbot 是否符合隐私模式要求？¶

是。Bugbot 遵循与 Cursor 相同的隐私合规标准，并以与其他 Cursor 请求相同的方式处理数据。

用完包含的 Bugbot 用量后会怎样？¶

用完包含的 Bugbot 用量后，额外的 Bugbot 评审将从按需消费额度中扣费。

如何让 Bugbot 访问自托管源代码控制实例？¶

请参阅相应集成页面中的设置和网络指南：

• GitHub Enterprise Server
• GitLab Self-Hosted
• Bitbucket Data Center

相关内容¶

• Bugbot 帮助信息