Cursor於9月23日推出兩款新的開發機器人：Rollouts負責盯著一項變更從合併到上線的整個過程，一旦發現回歸就發出警示並嘗試修復；Security Reviewer則在每個PR上執行一次安全審查，提供漏洞說明與修補建議。兩者都鎖定Teams與Enterprise方案的用戶，從Cursor的automations頁籤中開啟。
Rollouts：合併前先擬好監控計畫
依照Cursor的說法，Rollouts會"watches a change from PR to production, flags regressions, and acts to restore a healthy state"，也就是追蹤一項變更從PR到上線的過程，標出回歸問題，並設法把系統拉回健康狀態。
它要串接三類系統：程式碼託管平台、部署系統，以及Datadog、Grafana、Honeycomb這類遙測工具。流程分成兩段。合併前，它會讀取程式碼差異、判斷風險，據此產出一份監控計畫；如果這次變更牽涉的指標根本沒有埋點，就會在合併前提出警示。部署後，它拿線上數據和基準線比對，能抓出只出現在單一端點或單一地區的回歸，也會盡量把「預期中的變化」和「真正出問題」區分開來，避免只是調整了流量限制門檻就被誤判成事故。
Cursor表示，功能開關（feature flag）的整合以及對發布排程的掌握仍在規劃中。至於「恢復健康狀態」具體是要自動回滾到什麼程度、要不要人工確認，公告寫得相當籠統，只能等後續文件說明。
Security Reviewer：順著程式碼流向去找問題
Security Reviewer的定位是"runs on every PR, reads the change in the context of the whole codebase"。它按照程式碼流向追蹤資料從哪裡進、又從哪裡出，Cursor強調這和只靠規則比對的掃描器不同。偵測範圍包括：
- SQL、命令、樣板、LDAP等注入攻擊；
- 身分驗證與授權缺陷；
- 憑證外洩；
- 不安全的反序列化與重新導向；
- 相依套件漏洞與基礎設施設定問題。
Cursor公布的數據顯示，平均審查時間從4.8分鐘降到3.8分鐘，留言採用率從45%-50%升到60%-70%。公告並未說明這組數字是跟自家舊版本比較，還是跟其他方案比較，樣本規模與統計期間也沒有揭露。「採用率」指的是開發者採納了機器人的留言，並不等於漏洞抓出率，兩者不能混為一談。
放進同類工具裡比較
AI程式碼審查這條賽道今年相當擁擠。Anthropic在2025年為Claude Code加入/security-review指令，並搭配對應的GitHub Action，讓每個PR都能自動做一次安全檢查；GitHub Security Lab本週才公開一套由大型語言模型驅動的模糊測試流程，從尋找入口一路做到寫出漏洞報告。Cursor自家的Bugbot在6月也發布過一次更新，宣稱速度提升逾3倍、成本降低22%，多抓出10%的錯誤。
幾家的切入點各不相同。Claude Code的安全審查與Bugbot都停在「合併之前」；GitHub那套流程偏向安全研究，鎖定成熟的開源專案深挖問題。Cursor這次多走了一步，把Rollouts延伸到部署之後，踩進了SRE與維運團隊的地盤。這塊領域長期有Datadog的Watchdog、各家APM的異常偵測在做，Cursor的差異在於它已經讀過這次變更的程式碼，知道該盯哪幾個指標。
對團隊來說，打開開關只是第一步。Rollouts需要拿到部署系統與監控平台的權限，所謂「恢復健康狀態」，落到實際操作上可能就是直接觸發回滾。大企業的變更管理流程能不能接受一個機器人握有這類權限，比功能本身更難落地。Cursor目前尚未公布具體的權限模型與稽核紀錄設計。
參考來源：CocoLoop、Cursor官方部落格、GitHub部落格、Anthropic Claude Code文件；已核實Security Reviewer的審查時長與留言採用率、適用方案及偵測範圍。