Cursor 在 9 月 23 日的 changelog 里上线了两个面向 PR 末段的机器人。Rollouts 跟着每个 PR 一路走到部署，按环境回报健康状态；Security Reviewer 逐个 PR 扫描可被利用的漏洞，在 PR 上只留一条审查评论。两者都面向 Teams 和 Enterprise 档位，通过自动化的标签页启用，并附带一段 10 天的试用额度——Teams 约 50 次变更，Enterprise 约 500 次。
AI 编码工具已经把「写代码」这一段压得很短，但代码合进主干的最后一段反而更堵了：改动是一个人加 agent 一起产出的，评审者要判断的不只是逻辑对不对，还有这次上线会不会把生产环境拖垮。这两个机器人瞄准的正是这一段，而且分工划得很清楚——Rollouts 管「上线之后会怎样」，Security Reviewer 管「这段代码能不能被攻击」。风格和质量问题仍然归 Bugbot。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
Rollouts：把「这次上线会不会翻车」变成一条 PR 评论
Rollouts 的形态是给每个 PR 挂一个监控器。配置路径是先在仪表盘里打开它，然后把三样东西接上：源代码管理、部署系统、遥测数据源。接好之后，从下一个 PR 开始监控。官方文档把它描述为对 Firetiger Change Monitors 的一次再实现，用 Cursor 自己的 Bot Development Kit 重写。
它的工作分三步。第一步是出计划：Rollouts 读取 diff 和受影响的系统，把计划作为 PR 评论贴出来，内容包含识别到的风险、这次改动预期的效果、需要观察的信号，以及埋点缺失的地方。这份计划是可以编辑的，而且它会跟着你改过的版本走——这一点比较关键，意味着人不只是接受或拒绝，而是可以修正它的判断。
第二步是盯部署。部署事件与提交绑定后触发，Rollouts 拿着这份计划去比对日志、指标和链路追踪。它按环境分别跟踪，所以完全可能出现「staging 通过、生产被标记」这种结果。它校验的是预期效果，加上错误率和延迟这类信号，然后把结论作为评论回写到 PR 上。
第三步是判断结论。每个环境的状态是三种之一：verified healthy（确认健康）、regression detected（检测到回归）、inconclusive（无法判定）。如果发现回归，它会指出疑似相关的改动并通知作者；在配置允许的前提下，它可能开一个 revert PR 交给人工审查，或者把结论交给一个 cloud agent 去做修复。
Security Reviewer：只报可被利用的漏洞，一个 PR 一条评论
Security Reviewer 的定位比 Rollouts 窄得多。它拿每个 PR 对照整个代码库读一遍，只就「可被利用的 bug」发一条审查评论。风格问题、代码质量问题明确划给 Bugbot，不抢活。它在仓库维度从仪表盘启用，草稿 PR 会被跳过。
覆盖的漏洞类型列得比较具体：SQL、命令和模板面的注入；认证与授权的绕过，包括重构之后悄悄不再执行的检查；提交进仓库的密钥和凭据；SSRF 和未校验的跳转；不安全的反序列化；以及引入已知漏洞的依赖变更。它的分析方式是从入口开始追踪用户输入往下走，而不是只做模式匹配。
每条发现会给出严重度、攻击路径和一个建议修复。如果你带理由驳回某条发现，它不会再在这个 PR 上重复提出——这是控制噪音最实用的一处设计。除此之外还有团队规则：你可以把代码库层面的约定写成规则，比如「哪些客户端的外部调用必须走统一出口」「哪些表不允许在请求处理器里查询」，这些规则会在每个 PR 上强制执行。
一个完整场景：一次带依赖升级的接口改动
假设你改了一个对外接口，顺带升级了一个依赖包。
PR 打开后，Security Reviewer 先给出一次审查。它可能指出新的依赖版本引入了已知漏洞，也可能指出你在重构鉴权中间件时，某个分支上的检查不再执行了——后者正是「重构后静默失效」这类问题最典型的形态。你带理由驳回其中一条误报，它不再纠缠。
同时 Rollouts 在读 diff 和受影响系统之后，把监控计划贴成 PR 评论。你发现它漏掉了你们自己的一条业务指标，直接在评论里补上，它会按你改过的版本执行。合并、部署之后，staging 先跑通，它把状态标成确认健康；生产环境因为延迟指标抖动，被标成检测到回归并通知你，同时给出疑似相关的改动。你在 PR 上就能看到这条结论，而不必自己去翻监控面板。
限制与需要人接管的地方
最需要知道的一条是：Rollouts 今天不会自己合并、也不会自己回滚。它的 revert PR 是开出来给人审的，修复是交给 cloud agent 去做的，合并这个动作始终留给人和既有的分支保护规则。把这两个机器人当成「帮你盯着的助手」而不是「自动守门人」，预期才对得上。
第二个限制在集成面上。Rollouts 依赖源代码管理（Origin 或 GitHub）、一个能产生部署事件的持续交付系统、以及 Datadog 等遥测提供方。功能开关的集成官方标注为「即将到来」。这意味着如果你的部署链路或者监控栈不在它支持的范围内，Rollouts 拿不到足够的信号，结论很可能大量落在 inconclusive 上。埋点缺失也会被它自己列为计划的一部分，但补埋点这件事仍然要人来做。
第三点是人必须接管的判断：驳回带理由这件事，本身就是一次人工判断。规则里的「哪些表不允许在请求处理器里查询」同样需要人来写，写得越具体，机器人在每个 PR 上的判断才越有用。另外，changelog 里这个机器人的名字前后不太一致——标题用的是 Security Reviewer，正文里也出现过 Security Review，实际以仪表盘里的命名为准。
如何试用
两者都在 Teams 和 Enterprise 档位，从仪表盘的自动化的标签页启用。Rollouts 需要先接好源代码管理、部署系统和遥测源，监控从下一个 PR 开始；Security Reviewer 按仓库启用即可。试用额度是 10 天：Teams 约 50 次变更，Enterprise 约 500 次。建议先在一个部署链路清晰的仓库上试 Rollouts，在埋点和遥测齐全的前提下判断它的结论质量，再决定要不要铺开。
信息来源
- Cursor Changelog，2026-09-23：Rollouts and Security Reviewer（https://cursor.com/changelog/rollouts-and-security-reviewer）
开发必备：API 全流程管理神器 Apifox
介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。
如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。
值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。
获取专属报价与部署方案
详细的私有化部署系统架构与安全白皮书
针对您公司规模的专属报价单
免费的 1v1 专属产品演示 (Demo) 机会
