Cursor 这次没去卷补全准确率，而是把两个机器人塞进了软件交付最不体面的那一段：从 PR 合入到真正上线之间的灰区，以及每次都被拖延的安全审查。新产品叫 Rollouts 和 Security Reviewer，一个负责放出去会不会炸，一个负责放出去会不会被人打。
Rollouts：把"能不能发"从人的直觉里拆出来
灰度发布早就不新鲜，新鲜的是执行者换了
渐进式发布、金丝雀、分批放量——这些词在 SRE 圈子里讲了十几年。可真落到大多数团队的工作流里，它往往退化成一个工程师在深夜手动改配置，然后盯着监控面板看十分钟，靠经验判断"应该没事"。
Rollouts 想接管的就是这个动作。它按预设阶段推进发布，观察过程中的信号，在条件不满足时停下来。关键在于"阶段"这两个字：谁先拿到新版本、放多少流量、停留多久、什么时候进入下一档，全部被写成可执行的配置，而不是留在某个人脑子里的手感。
可配置动作，才是这款产品真正的重量
每推进一步，Rollouts 可以触发一个动作：继续放量、暂停、回滚、通知值班频道、开一张工单。单看这份清单平平无奇，价值在于团队终于能把"什么算异常"提前写成规则，而不是等值班的人在凌晨两点凭直觉拍板。
但也得承认边界在哪。它管的是发布节奏，不负责替你找 bug。埋点一塌糊涂、指标口径每周打架的团队，给机器人再多的动作权限，也只是让混乱跑得更自动一点。
当 agent 成了代码的提交者，回滚必须更快
过去一年多，代码的产出速度被 agent 拉高了一个量级，审查和发布的吞吐却没跟上。这个落差本身就是风险：写得越多、推得越慢，积压的变更就越大，单次上线的爆炸半径也跟着膨胀。
所以 Rollouts 真正值钱的地方不是"自动部署"，而是让一次发布变得更容易被拆小、更容易被打断、更容易被撤销。回滚够快，团队才敢放量；放量敢了，交付周期才会真的缩短。
Security Reviewer：带着审查权上场的那个机器人
它盯的是可利用性，不是代码审美
安全审查最容易死在两件事上：一是没人愿意做，二是做了也没人信。传统静态扫描工具的困境大家都熟悉——告警数量惊人，真正的漏洞埋在噪声里，最后团队学会了批量忽略。
Security Reviewer 的切入点是让模型读懂上下文：这段代码在做什么、输入从哪来、外部能不能构造出恶意请求。它给出的判断不该是"这里有个危险函数"，而更接近"沿着这条调用链往下走三步可以被利用"。这个差别决定了工程师愿不愿意看第二眼。
一票否决权，是很贵的东西
把审查意见写进 PR 评论，和让机器人直接卡住合并，是性质完全不同的两件事。前者你最多损失一点注意力，后者会实实在在堵住一整条流水线。
Cursor 把动作做成可配置，正是为了让团队自己挑档位：只在评论区说话，还是要求修改，还是直接阻断合并。这个梯度很务实。安全工具的可信度从来不是一次性发放的，是一点点攒出来的。
Cursor 真正想占的，是流水线的入口
编辑器和 CI 之间那堵墙
Cursor 起家于编辑器，但编辑器有个天花板：它只能影响单个工程师的工作瞬间，够不到团队级流程。而团队级流程才是预算所在。
Rollouts 和 Security Reviewer 都长在 PR 与部署之间的位置，恰好是 CI/CD 厂商经营多年的地盘。Cursor 从这个方向切进去，逻辑上顺理成章——代码已经在它的环境里产生，让同一个上下文继续往后走一步，比让另一个工具从零重新理解一遍要便宜得多。
接入之前，先问自己三个问题
第一，部署是不是已经做到了可观测？没有像样的指标，Rollouts 就是一辆蒙着眼开的车。第二，安全基线清不清晰？如果团队连"什么算高危"都没有共识，把判断权交给模型只会制造新一轮争论。第三，谁来处理机器人的输出？审查意见如果没有明确的归属人，再准确也会烂在通知列表里。
成本、误报，和一条慢慢爬升的信任曲线
token 账本上的那笔账
让 agent 参与每一次发布和每一次 PR 审查，token 消耗是持续性的，不是一次性的。Cursor 此前已经在优化长时运行的 token 效率，说明他们清楚这笔账的分量。
更该算的是误报成本。安全审查里，一次错误拦截换来的是工程师半小时的排查；一天拦三次，这个工具就会被关掉。评估这类产品时，准确率远不如"误报时团队要付多少代价"来得实在。
信任要分阶段给，和发布一样
有意思的是，这两款产品自己也需要一次灰度。
先让 Security Reviewer 只提意见，观察几周它对你们代码库的判断准不准；再让 Rollouts 接手一个不痛不痒的服务，看它停下的时机合不合理。等行为可预测了，再交权限。给机器人授权和给新人授权，本质上是一回事——先看表现，再给钥匙。
