在 Cursor 中使用 Bugbot 进行自动化代码审查

Bugbot 是 Cursor 的内置自动化代码审查代理，直接与您的 GitHub 仓库集成。当您打开一个拉取请求时，Bugbot 会分析差异、识别潜在错误、提出改进建议，并在您的 PR 上留下内联评论。本指南涵盖从初始设置到高级配置的所有内容，包括论坛用户经常遇到的 PR 路由和 GitHub Teams 集成问题。

Bugbot 的功能

Bugbot 对每个拉取请求执行多个层面的分析：

• 错误检测 - 识别逻辑错误、空引用风险和边界情况
• 安全扫描 - 标记潜在漏洞，如 SQL 注入或硬编码密钥
• 风格和一致性 - 检查与代码库模式的偏差
• 性能提示 - 突出低效模式，如 N+1 查询
• 测试覆盖率 - 标注变更缺少对应测试的情况

提示

Bugbot 完全在云端运行。您不需要保持 Cursor 开启才能进行审查。一旦在仓库上启用，Bugbot 会自动审查每个 PR，无论您是否在桌前。

前置条件

在设置 Bugbot 之前，请确保您具备：

1. Cursor Pro 或 Business 计划 - Bugbot 在免费层不可用
2. 一个 GitHub 仓库，已启用拉取请求工作流
3. 对仓库的管理员或维护者权限（应用安装所需）
4. 如果需要基于团队的 PR 路由，需配置 GitHub Teams

在仓库上启用 Bugbot

论坛用户报告的最常见问题是 Bugbot 显示"disabled for this repository"。这几乎总是可以追溯到 GitHub App 安装步骤被跳过或未完成。

步骤一：安装 Cursor GitHub App

Bugbot 通过 GitHub App 运行。如果您尚未安装：

1. 打开 Cursor 并导航到 Settings > Features > Bugbot
2. 点击 Connect GitHub Account
3. 您将被重定向到 GitHub 以授权 Cursor 应用
4. 选择范围：
   • All repositories - Cursor 可以审查您账户中的任何仓库
   • Selected repositories - 选择特定仓库进行审查

注意

如果您在安装时选择了特定仓库，之后创建新仓库时，Bugbot 不会在新仓库上工作，直到您明确添加它。这是"disabled for this repository"错误的第一大原因。要修复它，请前往 GitHub > Settings > Integrations > Applications > Cursor > Configure，并添加新仓库。

步骤二：在 Cursor 设置中启用 Bugbot

GitHub 应用安装完成后：

1. 打开 Cursor Settings（Cmd/Ctrl + ,）
2. 导航到 Features > Bugbot
3. 将 Enable Bugbot 切换为 ON
4. 选择要在哪些仓库上激活 Bugbot

步骤三：验证连接

创建一个测试拉取请求并检查 Bugbot 是否响应：

# Create a test branch
git checkout -b test-bugbot-connection

# Make a small change
echo "// Bugbot test" >> README.md
git add README.md
git commit -m "test: verify bugbot connection"
git push origin test-bugbot-connection

在 GitHub 上打开一个 PR。30-60 秒内，Bugbot 应该发布一条评论。如果没有，请继续查看下方的故障排除部分。

PR 路由和审查者分配

Bugbot 可以根据文件路径、代码所有权或团队成员身份将拉取请求路由给特定的审查者。论坛用户报告 PR 路由并不总是按预期工作，特别是在使用 GitHub Teams 时。

理解 PR 路由

PR 路由决定了当 Bugbot 分析 PR 时谁会收到审查请求。路由逻辑遵循以下优先级：

1. CODEOWNERS 文件 - 如果存在，变更文件的所有者成为审查者
2. GitHub Teams 映射 - 通过 Bugbot 配置进行基于团队的路由
3. 回退 - 所有维护者收到审查请求

配置 CODEOWNERS

在仓库根目录（或 .github/CODEOWNERS）创建一个 CODEOWNERS 文件：

# Default owners
*                           @team-leads

# Frontend files
src/components/             @frontend-team
src/pages/                  @frontend-team
src/styles/                 @frontend-team

# Backend files
src/api/                    @backend-team
src/models/                 @backend-team
src/middleware/             @backend-team

# Infrastructure
terraform/                  @devops-team
docker/                     @devops-team
.github/workflows/           @devops-team

# Security-sensitive files
src/auth/                   @security-team @team-leads
.env*                       @security-team

GitHub Teams 集成

对于基于团队的路由，Bugbot 会读取您的 GitHub Teams 成员身份。要进行配置：

1. 确保您的 GitHub 组织已在 Org Settings > Teams 下设置了团队
2. 为每个团队添加成员
3. 在 CODEOWNERS 中引用团队名称（带 @ 前缀）
4. 在 Cursor 中，前往 Settings > Features > Bugbot > Advanced
5. 启用 Use GitHub Teams for routing

提示

CODEOWNERS 中的 GitHub 团队名称必须完全匹配。一个常见的错误是使用显示名称而不是团队 slug。例如，如果您的团队名为"Frontend Engineers"，slug 为 frontend-engineers，CODEOWNERS 条目必须是 @frontend-engineers，而不是 @Frontend Engineers。

常见 PR 路由问题

问题：PR 被路由到错误的团队

症状： 一个修改后端文件的 PR 被路由到前端团队。

原因： CODEOWNERS 模式重叠。第一个匹配的模式优先，模式从上到下评估。

解决方案： 重新排序 CODEOWNERS 文件，使更具体的模式在通用模式之前：

# Specific first
src/auth/                   @security-team @team-leads
src/api/                    @backend-team

# Then general
src/                        @all-developers
*                           @team-leads

问题：团队未收到审查请求

症状： Bugbot 审查了 PR，但没有 GitHub 团队成员被添加为审查者。

原因： GitHub 团队设置为"secret"（不可见）或没有成员。

解决方案： 前往 GitHub > Organization > Teams > [团队名称] > Settings。如果您希望团队收到审查请求，请确保团队可见性未设置为"Secret"。验证团队是否有活跃成员。

Bugbot 配置

除了基本启用外，Bugbot 还提供了几个配置选项来调整其行为。

审查严重性

控制 Bugbot 对其发现的严格程度：

{
  "bugbot.severity": "balanced",
  "bugbot.maxComments": 20,
  "bugbot.autoResolve": false
}

严重性	行为
strict	报告所有发现，包括轻微的风格问题
balanced	报告错误、安全问题和显著的风格问题（默认）
lenient	仅报告错误和安全漏洞

文件排除

防止 Bugbot 审查生成或第三方文件：

{
  "bugbot.excludePaths": [
    "**/*.min.js",
    "**/*.min.css",
    "node_modules/**",
    "dist/**",
    "build/**",
    "*.lock",
    "package-lock.json",
    "yarn.lock"
  ]
}

安全代理配置

Bugbot 包含一个专用的安全代理，用于扫描漏洞。独立配置它：

{
  "bugbot.securityAgent": {
    "enabled": true,
    "sensitivityLevel": "high",
    "scanForSecrets": true,
    "scanForDependencies": true,
    "ignorePatterns": [
      "test/**",
      "__mocks__/**"
    ]
  }
}

注意

安全代理会扫描您的 PR 差异中的硬编码密钥（API 密钥、密码、令牌）。如果它发现它认为是密钥的内容，会将其标记为关键问题。这是一项安全功能。在未验证被标记的字符串不是真正的密钥之前，切勿忽略这些警告。即使是看起来像真实密钥的测试夹具，如果有人将其复制到生产代码中也可能有危险。

审批工作流

Bugbot 与 GitHub 的审查审批系统集成。您可以配置 Bugbot 的发现是否阻止 PR 合并。

设置必要的审查

在您的 GitHub 仓库设置中：

1. 前往 Settings > Branches > Branch protection rules
2. 编辑主分支的规则
3. 在 Require pull request reviews before merging 下：
   • 设置必要的批准审查数（例如 2）
   • 启用 Dismiss stale pull request approvals（当推送新提交时）
   • 启用 Require review from Code Owners

将 Bugbot 设为必要审查者

您可以配置 Bugbot 作为必要审查者。启用后，在 Bugbot 完成审查并批准或审查被驳回之前，PR 无法合并。

在 Cursor 中：

1. Settings > Features > Bugbot > Workflow
2. 启用 Block merge on critical findings
3. 设置阻止合并的严重性阈值（默认：critical 和 high）

提示

谨慎使用阻止功能。如果阈值设得太低（阻止低严重性发现），当风格问题阻止合并时，开发者可能会感到沮丧。从"critical 和 high"开始，根据团队的体验进行调整。

处理 Bugbot 分歧

有时 Bugbot 标记的内容，开发者认为是误报。推荐的工作流：

1. 在 GitHub 上的 Bugbot 评论上点击 Resolve conversation
2. 添加评论解释为什么是误报
3. 如果在同一模式上反复出现误报，添加 // bugbot-ignore 注释：

# bugbot-ignore: This is intentionally using eval for a DSL interpreter
result = eval(user_expression)

故障排除"Disabled for This Repository"

这是报告最多的 Bugbot 问题。按照此诊断流程图操作。

诊断步骤一：检查 GitHub App 安装

# Check if the Cursor app has access to your repo
gh api repos/{owner}/{repo}/installation --jq '.id'

如果返回 404，说明 GitHub App 未安装到该仓库。

解决方案： 前往 GitHub > Settings > Integrations > Applications > Cursor > Configure，并添加该仓库。

诊断步骤二：检查 Cursor 中的仓库设置

1. 打开 Cursor 设置
2. 导航到 Features > Bugbot
3. 在启用列表中查找您的仓库
4. 如果不在列表中，点击 Add Repository 并选择它

诊断步骤三：检查分支保护规则

Bugbot 需要仓库允许 GitHub App 发布审查评论。如果您的分支保护规则过于严格：

1. 前往 GitHub > Settings > Branches
2. 编辑分支保护规则
3. 确保 Allow specified actors to bypass requirements 包含 Cursor 应用
4. 确保应用未被 Restrict who can push to matching branches 阻止

诊断步骤四：检查冲突的应用

如果您安装了其他自动审查工具（CodeRabbit、GitHub Copilot、SonarQube），它们可能与 Bugbot 冲突。

解决方案： 暂时禁用其他审查机器人并检查 Bugbot 是否开始工作。如果是，您需要配置这些工具共存，这可能需要调整 webhook 设置或审查触发器。

诊断步骤五：检查 Bugbot 状态

# Check Cursor service status
curl -s https://status.cursor.sh/api/v2/incidents.json | jq '.incidents[] | select(.status != "resolved")'

如果有活跃事件，等待其解决并重试。

注意

Bugbot 有时在 Cursor 更新后立即显示为"disabled"。这是一个已知问题，GitHub 令牌需要重新认证。前往 Settings > Features > Bugbot，点击 Disconnect，然后 Reconnect 您的 GitHub 账户。这会刷新令牌而不会丢失您的配置。

Bugbot 和 GitHub Teams 集成深入解析

同步团队成员身份

Bugbot 为了性能会缓存 GitHub 团队成员身份。如果您添加或删除团队成员，更改可能不会立即反映。

要强制同步：

1. 打开 Cursor 设置
2. 前往 Features > Bugbot > Advanced
3. 点击 Sync GitHub Teams
4. 等待同步完成（通常在 30 秒内）

多团队成员身份

当开发者属于多个团队时，Bugbot 根据 CODEOWNERS 匹配进行路由。如果文件由多个团队拥有且开发者在两个团队中，他们会收到一个审查请求，而不是重复的。

基于团队的审查策略

您可以为每个团队配置不同的审查要求：

{
  "bugbot.teamPolicies": {
    "security-team": {
      "requiredReviews": 2,
      "blockOnHighSeverity": true,
      "additionalScanners": ["dependency-check"]
    },
    "frontend-team": {
      "requiredReviews": 1,
      "blockOnHighSeverity": false
    }
  }
}

Bugbot 性能和限制

审查速度

Bugbot 通常在 PR 打开或更新后 30-90 秒内完成审查。影响速度的因素：

因素	影响
PR 大小（变更行数）	大差异需要更长时间分析
文件数量	每个文件需要单独分析
仓库大小	更大的代码库需要更多上下文收集
当前负载	高峰时段可能响应更慢

评论限制

默认情况下，Bugbot 每次审查最多发布 20 条评论。这防止了 PR 作者被淹没。您可以调整此设置：

{
  "bugbot.maxComments": 50
}

提示

如果 Bugbot 在每个 PR 上都达到评论限制，请考虑提高严重性阈值。达到限制意味着 Bugbot 发现了许多低优先级问题。过滤掉这些问题会使审查更具可操作性。

速率限制

Bugbot 遵守 GitHub API 速率限制。如果您的组织同时打开许多 PR，审查可能会排队。Bugbot 按顺序处理它们，所有审查最终都会完成。

Bugbot 采用最佳实践

从只读模式开始

首次在现有仓库上启用 Bugbot 时，从只读模式（不阻止合并）开始。这让团队可以在不打断工作流的情况下看到 Bugbot 发现了什么。在一两周的审查发现后，调整配置并在适当时启用合并阻止。

将 Bugbot 发现作为学习工具

Bugbot 的发现不仅仅是修复当前 PR。它们是学习机会：

1. 跟踪反复出现的发现类型（例如，"空引用风险"出现在 30% 的 PR 上）
2. 创建 .cursor/rules 条目以防止未来代码中出现该模式
3. 在团队频道中分享有趣的发现

定期配置审查

每月审查您的 Bugbot 配置：

• 文件排除是否仍然合适？
• 严重性阈值是否正确校准？
• 是否有新的误报模式需要抑制？
• 评论限制是否适合当前的 PR 大小？

总结

Bugbot 为 Cursor 连接的 GitHub 仓库中的每个拉取请求带来了自动化的、智能的代码审查。最常见的问题"disabled for this repository"几乎总是通过验证 GitHub App 安装范围并确保仓库被明确添加来解决。通过配置 CODEOWNERS 进行 PR 路由、调整安全代理，以及采用渐进式合并阻止方法，您的团队可以将 Bugbot 作为对抗错误和安全漏洞的可靠第一道防线。