Cursor Bugbot 怎么开 仓库与触发方式
讲 Cursor Bugbot 接仓库、Automations 启用、cursor review 手动触发、CI check 状态与个人团队设置差异。
Cursor Bugbot 怎么开，不是装一个 IDE 扩展就完事。它审查的是托管平台上的 Pull Request，要先接仓库，再在 Automations 里按仓库启用，最后弄清自动跑与手动触发的差别。
Bugbot 在 PR 上具体做什么
官方定义很窄：Bugbot 审查 pull request，识别 bug、安全问题与代码质量问题。它分析 PR diff，留下带说明与修复建议的评论；默认在每次 PR 更新时自动跑，也可以手动触发。评论侧它会读取已有的顶层评论与行内评论，用来减少重复建议，并顺着前人反馈往下写。
评论里常见「Fix in Cursor」和「Fix in Web」链接，分别打开本地 Cursor 或 cursor.com/agents。那是跳去修问题的入口，不等于已经改完代码。自动改代码属于 Bugbot Autofix，或 Marketplace 上另一套「Autofix PR review comments」自动化；本篇只讲审查怎么开，自动修复见 Cursor 自动修复 PR 评审意见。
配置入口在 Automations：cursor.com/automations/from-cursor/bugbot。和通用 Automations 模板不同，Bugbot 有独立的仓库启用列表、努力程度、规则与 CI 行为。Automations 整体怎么建触发器，见 Cursor Automations 怎么用。
先接 GitHub、GitLab 或 Bitbucket
文档要求先通过 Cursor dashboard 连接仓库，再谈启用。支持面包括：GitHub（含 GitHub Enterprise Server）、GitLab（含 GitLab Self-Hosted）、Bitbucket（含 Bitbucket Data Center）。各自有独立的 Integrations 文档页，按提供商走安装应用、选组织、勾仓库的流程。
连接成功只代表 Cursor 能看见仓库事件。若安装应用时漏勾某个 repo，后面在 Bugbot 列表里也开不了。自建 GitLab 还多一层网络：Cursor 云端要能访问你的实例 URL，证书与 IP 放行需要自行验证；接入细节见 Cursor 连接自建 GitLab。
个人开发者常见路径是 GitHub App 装到个人账号或单个 org。团队路径则是管理员装到组织，再按仓库授权。两种路径装完后，下一步都要进 Bugbot Automations，而不是停在 Integrations 绿勾。
在 Automations 里按仓库打开 Bugbot
接好提供商之后，打开 Bugbot Automations 页面，在 installations 列表里对具体仓库启用或关闭。文档写明：启用后 Bugbot 才会对这些仓库的 PR 工作。Team 与 Enterprise 还可配置 reviewer 的 allow/deny 列表，以及「每个 installation 每个 PR 只跑一次、跳过后续 commit」这类降噪选项。
个人档与团队档的默认对象不同。Individual 下，Bugbot 只审查你自己创建的 PR。Team 与 Enterprise 下，只要仓库启用了，仓库里所有贡献者的 PR 都会跑，不论作者是否团队成员。这条很容易误判：你以为「只给自己试」，结果组织仓库一开，全员 PR 都开始收评论。
启用后建议先挑一个低流量仓库观察几天：看评论密度、误报率、以及和现有人工 review 是否打架。再决定是否铺到主业务仓库，并是否把 Bugbot check 写进 branch protection。
用 cursor review 或 bugbot run 手动触发
自动审查之外，文档提供两条等价的手动命令：在任意 PR 下评论 cursor review 或 bugbot run。个人设置里还可以改成「仅在被 @ 提到时跑」，或「每个 PR 只跑一次」。团队成员对自己的 PR 也能覆盖这些个人选项。
需要核对本轮加载了哪些规则时，用 bugbot run verbose=true 或 cursor review verbose=true。Bugbot 会回帖一张规则表，并标出被截断或省略的规则。规则来源包括 Team Rules、仓库 .cursor/BUGBOT.md（含按目录嵌套的文件）、learned rules 与 manual rules；普通的 .cursor/rules/*.mdc 不会进入 Bugbot 运行。
手动触发适合三种场景：刚改完个人设置想立刻验证；draft 阶段默认不自动审，准备 ready 前先跑一轮；自动跑被「只跑一次」跳过后，又推了关键修复想再审。
CI check 的 success、neutral、failure
每次审查会发一条状态。GitHub 上 check 名是 Cursor Bugbot；Bitbucket 上是 build status，key 为 cursor-bugbot。结论只有三类：success 表示没找到问题，且没有未解决的历史 Bugbot 评论；neutral 表示找到了问题、被更新的 commit 取消、或内部错误，这是「有发现」时的默认结论；failure 表示找到问题，且组织打开了「未解决问题则失败」的配置。
文档特别提醒：branch protection 里勾选要求 Bugbot check，只能保证它跑过，不能单靠勾选就在「有发现」时拦住合并，因为默认是 neutral。若组织提供 fail-on-unresolved-issues，需要额外打开，未解决发现才会变成 failure。Bugbot 不会发 skipped。若启用了 Bugbot Autofix，GitHub 还可能多一条 Cursor Bugbot Autofix check，且只使用 success 或 neutral。
个人与团队设置差在覆盖面
Individual 的仓库开关只影响「你是否对自己的 PR 开审查」。Team / Enterprise 的仓库开关影响该仓库全部贡献者。Team 成员个人仍可把自己的 PR 调成仅提及触发、仅跑一次，以及是否审查 draft PR。Enterprise 另有 Bugbot API：用 Dashboard API Keys 做 Basic Auth，可对指定 PR URL 调用 POST /bugbot/review 排队审查，也支持 dryRun 只分析不发帖。
用量与努力程度是另一条线。Effort Levels（Default / High / Custom）只在 usage-based Bugbot 方案里出现，拉高努力可能找出更多问题，也会更慢、更贵。Incremental Review 打开后，只审相对上次 Bugbot 审查的增量 diff，适合超大 PR。这些开关都在同一 Automations 页，和「开不开仓库」是两层配置。
什么时候别开或先收窄
噪声大时先别全量开。每个 commit 都自动审、又没有「只跑一次」，评论区会被刷屏，人工 reviewer 开始忽略所有机器人留言。此时应先开「仅提及」或「每 PR 一次」，再视接受率放开。
Draft PR 策略要单独定。Team / Enterprise 个人设置里有「Enable reviews on draft PRs」。草稿阶段 diff 剧烈变化，自动审容易堆积过期评论；更稳的做法是 draft 默认关，准备标 ready 前手动 bugbot run。规则尚未写进 .cursor/BUGBOT.md 时，也先别对核心仓库开 High effort，否则通用风格建议会淹没真正的安全问题。
Autofix 与「开审查」不要捆在一起决策。可以只开 Bugbot 评论，修复仍走人工或点 Fix 链接；自动改分支的模式、计费与 Privacy 前提，放到 Autofix 专题文处理，避免一张清单里同时改审查与写权限。
参考资料
下列链接对应本文机制描述的官方出处，建议先读 Bugbot 文档再打开 Automations 对照界面。Bugbot 文档写清了 GitHub、GitLab、Bitbucket 接入路径，Automations 按仓库启用，手动评论 cursor review 与 bugbot run，CI check 的 success、neutral、failure，以及个人与 Team、Enterprise 设置差异。Automations 入口页是仓库开关、努力程度与规则配置的操作面；Autofix 公告与文档中的 Autofix 章节只说明「审查之后自动改」这条相邻能力，计费与分支策略细节不在本文展开。自建 GitLab 或内网 Bitbucket 还要单独确认 Cursor 云端能否访问实例。若日后选项名称有调整，回到上述链接查看当前界面文案即可。