Cursor Rollouts + Security Reviewer：盯 PR 到生产
原文链接: https://cursor.com/blog/rollouts-and-security-reviewer
作者: Rustam Lalkaka（Cursor）
发布: 2026-09-23
Cursor 把写代码之后那段没人盯的时间交给两个 bot：Rollouts 和 Security Reviewer。
Rollouts 跟着一个变更从 PR 一直走到生产。要做的事是：连接代码托管 / 部署 / 遥测（Datadog、Grafana、Honeycomb 或自托管），合并前它读 diff 起一份「监控规划」——列它认为的风险、这次变更预期会动到的指标、目前埋点覆盖不到的盲区；规划里漏的可以手工补。合并后 Rollouts 把规划里那条信号曲线跟部署前 baseline 比，发现回归会告诉你「它怀疑是哪个变更搞的」，并按配置处理（通知作者、暂停 staged rollout、或开一个回滚 PR 等审批）。当前它擅长三件事：在全局告警之前抓到只出现在某 region / 某 endpoint 的回归；区分预期信号 vs 真正回归，有意为之的指标激增不会惊动人；合并前提示缺埋点（这正是变更出问题时不被发现的最常见原因）。Roadmap 上是 feature flag 直连（自动放量 / 回退）以及对 release train / 部署冻结期的感知。
Security Reviewer 在每个 PR 跑，结合全库上下文读 diff。它跟静态分析不是一回事：静态分析按模式匹配，会标 SQL 拼接字符串却漏「重构后失效的授权检查」；Security Reviewer 像安全工程师那样看代码——用户输入从哪进、流到哪、中间过哪些层。默认能查：SQL / 命令 / 模板 / LDAP 等注入；新加路由缺失或失效的认证与授权；提交进代码库的密钥和凭证；不安全反序列化与未验证重定向；引入已知漏洞的依赖变更；infra 与配置的不安全默认。每条发现带严重级别 + 攻击路径，并支持一键修复。官方数据：把平均审查时间从 4.8 分钟降到 3.8 分钟，把评论接受率从 45–50% 抬到 60–70%。
判断：与「agent 写码后谁盯发布」缺口直接对齐，跟 Android staged rollout 的回滚链同构；目前只对 Teams / Enterprise 开放。
备注：摘要基于 Cursor 官方博客原文（中文版翻译稿）。