---
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="/zh-Hant/docs/cursor/official/04-cloud-agents/56-security-review" />
  <Card title="Cloud Agent Capabilities" description="回看 Bugbot Autofix 背後的 Cloud Agent 能力。" href="/zh-Hant/docs/cursor/official/04-cloud-agents/52-capabilities" />
</Cards>
