Bugbot
基於 Cursor 官方 Bugbot 文件解釋自動 PR review、手動觸發、rules、autofix、MCP、Admin API、定價和排障。
Bugbot 是 Cursor 的自動 PR review 產品，用來發現 bug、安全問題和程式碼質量問題。
閱讀目標：讀完本章，你應該能把 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 有多層來源。官方順序是：
- Team Rules。
- Repository rules，包括 learned rules 和 manual rules。
- Project
.cursor/BUGBOT.md，包括巢狀檔案。 - User Rules。
專案規則建議放在 .cursor/BUGBOT.md。Bugbot 總是包含 repo root 的 .cursor/BUGBOT.md，並會從 changed files 向上查詢更近的 .cursor/BUGBOT.md。
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 不工作時先跑可追蹤排障：
- 在 PR 評論
cursor review verbose=true或bugbot run verbose=true，拿 detailed logs 和 request ID。 - 檢查 Bugbot dashboard 中 repo 是否 enabled。
- 檢查 GitHub App 或 GitLab integration 是否已安裝並有 repo 許可權。
- 檢查個人設定是否開啟“only when mentioned”。
- 檢查 team allow / deny list 是否阻止了當前 author。
- 檢查 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 兜底。
深讀：Bugbot 的價值在規則質量，不在“多一個機器人”
如果團隊沒有沉澱 review 標準，Bugbot 只能給通用建議。真正值得上線的是把團隊已經反覆人工指出的問題寫進 Team Rules、repository rules 和 .cursor/BUGBOT.md，讓它在每個 PR 裡穩定執行。
本章自檢
- Bugbot 是自動執行、手動觸發，還是兩者都啟用？
- 規則來源和應用順序是否清楚？
- Autofix 是 off、新分支還是現有分支？
- 成本、seat、PR cap 和 storage 條件是否已經確認？
- 排障時是否能拿到 verbose request ID？
透過標準：你能把一個 repo 接入 Bugbot，並寫出包含 rules、autofix、成本、排障和合並邊界的團隊 SOP。
官方來源
- Cursor Bugbot —— 官方 Bugbot、rules、autofix、MCP、Admin API、pricing 和 troubleshooting。
- Cursor Help: Bugbot —— 官方幫助頁中的設定、觸發和常見問題。
- Cursor GitHub Integration —— 官方 GitHub / GHES 整合。
- Cursor GitLab Integration —— 官方 GitLab / self-hosted GitLab 整合。
- Cursor MCP —— 官方 MCP 背景。