《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 幫助信息