Cursor 上线 Rollouts：先写监控计划再盯部署，官方称回归可在用户受影响前拦截

AI 编程工具 Cursor 于北京时间 9 月 24 日凌晨 4 时 45 分（美国时间 9 月 23 日 20 时 45 分）在官方 X 账号 @cursor_ai 宣布推出 Rollouts：该功能先为一次变更写一份监控计划（monitoring plan），再在变更部署时持续观察；官方称部署会得到验证（verified），回归（regressions）能在用户看到之前被拦截。同一组推文还宣布了 Security Reviewer 的更新：官方称其完成速度加快 21%，平均耗时从 4.8 分钟降到 3.8 分钟。

两项功能即日起面向 Teams 与 Enterprise 计划开放，未来 10 天内附带 Rollouts 用量额度，供用户在真实变更上试用（见推文）。上述能力描述与性能数字均为 Cursor 官方单方发布口径，目前没有独立核实。

合并前先交监控计划，部署后对照基线

官方博客在同日发布的文章《Bots for the last mile》里解释了 Rollouts 的工作方式，出发点是：写代码不再是慢的部分，慢的是 PR（pull request，合并请求）提交之后的事——确认代码安全、盯部署、判断一次延迟升高是不是真的、从十一个变更里找出是哪一个弄坏了结账流程。

Rollouts 的前提是接上三类系统：源代码托管、部署系统，以及遥测数据——官方点名的选项包括 Datadog、Grafana、Honeycomb，或指标与链路追踪所在的其他平台。合并之前，它会读取 diff（代码差异）并写出一份监控计划，内容有三件：它看到的风险、这次变更预期产生的效果，以及现有插桩（instrumentation）无法判断变更是否生效的位置。Cursor 提示用户，计划缺了什么可以直接修改。

部署之后，Rollouts 把计划里的信号与部署前基线对比。发现回归时，它会指出怀疑哪个变更、打算怎么处理；按用户的配置，动作可以是提醒作者、暂停渐进式发布（progressive rollout），或生成一份等待批准的回滚 PR。

官方点名的三项当前能力

博客列出了 Rollouts「今天就能做好的三件事」：发现局限于一个区域、一个端点的回归，赶在全局告警触发之前；把预期效果和回归区分开，让刻意为之的指标波动不惊动任何人；在合并前标记缺失的插桩——官方称这是坏变更无人察觉的最常见原因。

两个渠道的口径有细微差别：推文说回归「在用户看到之前」被拦截，博客的细化说法则是「早于全局告警」发现单区域、单端点的回归。路线图上还有两项「即将推出」：与 feature flag（功能开关）集成，让 Rollouts 直接增减流量；以及识别 release trains（发布列车）和 deploy freezes（部署冻结期）。

Security Reviewer：逐个 PR 读代码的安全审查

Security Reviewer 在每个 PR 上运行，把变更放进整个代码库的上下文里读，报告漏洞时附带解释和修复建议。博客把它与静态分析对比：静态分析按模式匹配，会把 SQL 调用附近的字符串拼接全部标出，却漏掉重构之后已经停用的授权检查；Security Reviewer 按安全工程师的思路读代码——用户输入从哪里进来、最终到哪里去、中途经过了什么。

开箱即用检查六类问题：SQL、命令、模板和 LDAP 注入；新增或改动路由上缺失、失效的认证与授权；提交进代码库的密钥和凭证；不安全反序列化与未校验重定向；拉入已知漏洞的依赖变更；基础设施与配置里的不安全默认值。每条发现标注严重级别和攻击路径，并附一键修复。博客随文发布的图表还给出另一项指标：评论采纳率从 45%～50% 升到 60%～70%。

从 automations 标签页开通，Pro 与免费计划不在名单

推文串的第三条写明开放范围：Rollouts 和 Security Reviewer 当天起在 Teams 与 Enterprise 计划可用，官方博客给出的开通入口是 automations 标签页，用户可从这里开启其中任一机器人。公告没有把 Pro、Pro+ 或免费计划列入名单；一位 Pro+ 用户在 Security Reviewer 那条推文下留言：“Security Reviewer 在 Pro+ 上用不了，我本来很想试试。不明白为什么这是 Teams 专属功能。”（dimayvr）

第一批反馈：认可盯部署，追问自查自证

截至发稿，主推文获得约 15 万次浏览、2,300 多个赞（X 平台页面数据）。有开发者认可这个方向：“在这里拦下回归，比等用户报告来发现要好得多。”（FlorinIluta）也有用户不买账：“代理把代码写了，监控计划也写了，再自己验证自己的部署——我们重新发明了给自己批作业，还给配了个仪表盘。”（ryanndngg）

对提速数字本身，一条中文回复提醒别只看均值：“4.8→3.8 分钟（-21%）对高频 PR 很实在。别只看均值：尾部延迟和误报率，才决定团队敢不敢默认开 Security Reviewer。”（binbinyiyilili）

21%、3.8 分钟、60%～70% 这些数字目前只有 Cursor 自己的口径，官方博客正文没有给出统计样本或计算方式；部署「验证」如何判定，公告和博客也都没有说明。

参考链接

• Cursor 官方推文：Introducing Rollouts
• Cursor 官方推文：Security Reviewer 提速 21%
• Cursor 官方推文：开放范围与 10 天用量额度
• Cursor 官方博客：Bots for the last mile: Rollouts, Security Review
• dimayvr 的回复
• FlorinIluta 的回复
• ryanndngg 的回复
• binbinyiyilili 的回复