Cursor 发布的 Rollouts 与 Security Reviewer 针对软件交付中“代码写完之后”的工作：前者观察一次改动从 Pull Request 到生产环境的表现，后者结合整个代码库审查 PR 中的安全问题。它们希望减少工程师追踪回归、检查监控覆盖和整理漏洞修复的重复劳动。功能面向 Teams 和 Enterprise 团队。查看 Cursor 官方说明。
Rollouts 怎样跟踪一次部署
团队连接代码托管、部署系统和指标/追踪工具后，Rollouts 会在合并前读取代码差异，拟定监控计划：改动希望带来什么效果、可能影响哪些服务，以及现有监控能否证明它正常工作。团队可以先修改计划，再部署。部署后，它把相关信号与变更前的基线比较，尝试区分预期变化与异常回归，并指出可能相关的改动。异常出现后的动作按团队设置执行，可以只是通知作者，也可以暂停渐进式发布，或生成等待批准的回退 PR。
Security Reviewer 检查什么
Security Reviewer 可在每个 PR 上运行，在整个代码库的上下文中理解修改，再报告漏洞、可能的攻击路径和建议修复。Cursor 将这种检查与只匹配固定模式的静态规则作了区分：代码片段单独看似乎危险，但项目其他位置可能已有权限校验；反过来，一个局部看起来无害的改动也可能破坏跨文件的安全假设。它的报告可用于决定哪些问题需要人工复现和修补，并不等于完整渗透测试或正式安全认证。
试点前准备
- 先选一个低风险服务和一类可观察指标，例如错误率或请求延迟，建立发布前基线。
- 检查每个关键业务路径是否有足够监控；没有埋点时，机器人也无法凭空判断部署效果。
- 先把异常动作设置为通知或等待批准，收集一段时间的误报和漏报，再讨论自动暂停或回退。
- 把 Security Reviewer 的发现纳入现有代码审查，要求维护者检查上下文、复现步骤和修复副作用。
范围与限制
Cursor 公告表示两项功能向 Teams 与 Enterprise 开放；直接控制功能开关调整流量、识别发布冻结等能力当时列为后续开发。实际效果依赖代码托管、部署记录、指标和追踪数据的完整度，也受团队对自动回退的授权方式影响。不能只因机器人给出“安全”或“回归”结论就跳过原有审批。