Cursor 把上线后的回归，也放回 PR 里了

一个 PR 合进去，预发布绿了，生产也顺利发完。然后过了二十分钟，错误率开始往上爬。

这大概是很多做后端、平台和业务服务的同学最熟悉的一种安静。CI 已经没声了，PR 也被点了合并，问题却刚刚开始。AI 把写代码这段路跑得越来越快，最后那一截反而更显眼，谁来证明这次改动真的没把线上带沟里去。

Cursor 昨天发布了两个 bot，Rollouts 与 Security Review。一个盯着变更从 PR 走到部署后的状态，一个盯着 PR 里有没有可被利用的安全缺陷。好家伙，它们不再只盯着「代码写得像不像样」，开始盯「这次上线到底有没有活着回来」。

我觉得这个方向比再多一个会补全、会改文件的 Agent 更值得聊。不是 Cursor 多了两个按钮，而是 AI 编码把团队推到了一个更现实的问题，代码可以更快地产出，验证链条不能还靠谁有空去看一眼 Datadog。

一张 PR 不是交付的终点

以前我们常把 PR 当成一张交接单。有人写，有人审，CI 跑过，合并。干净利落。

可一段代码真正开始碰见用户，是在部署之后。它在预发布环境里可能很乖，到了生产却撞上了不同的流量、缓存、权限配置和老数据。你改了一个查询，也许页面正常，延迟却突然变长。你收紧了一道鉴权，也许接口测试全绿，线上某条很少走的路径却再也进不去。

这不是谁不够小心。软件的麻烦就在这里，diff 只告诉你改了什么，没告诉你它在真实运行环境里会和谁打架。

Rollouts 想补的就是这段空白。按 Cursor 的官方说明，它会在 PR 打开时读取 diff 和涉及的系统，先把一份监控规划写成 PR 评论。里面不是泛泛地说「注意线上」，而是列出这次改动的风险、它本来要产生的效果、要检查的信号，还有哪些埋点缺失会让判断变得困难。

这个设计有个很朴素的好处，监控计划可以直接在 PR 里被人改掉。发布前，写代码的人、Reviewer 和懂业务的人可以把「我希望它变好什么」讲清楚，而不是等告警响了才开始猜该看哪块面板。

部署事件来了，它再拿着这张计划去读日志、指标和链路追踪，并且把预发布和生产分开判断。结果只有三种，已验证健康、检测到回归、无法确定。

第三种尤其重要。很多自动化系统最爱装懂，仪表盘一片绿就给你一颗勋章。Rollouts 至少把「证据不够」当成一个正经结论。厉害了，AI 没有硬凹万能裁判，承认看不清也是工程能力的一部分。

图里最该被保留的不是绿勾，而是最后那只手。自动化负责把证据送到桌上，暂停和回滚仍然应该由知道业务代价的人来按。

安全审查终于不该只看代码风格

另一个 bot 叫 Security Review。它会结合整个代码库的上下文读每个 PR，只留一条聚焦可被利用缺陷的评论。代码风格和一般质量问题仍交给 Bugbot，这个分工挺克制。

它关注的东西也很具体，SQL、命令和模板注入，鉴权和授权绕过，重构之后某个检查悄悄不再执行，误提交的密钥和凭证，SSRF、未经验证的跳转、不安全反序列化，以及引进已知漏洞的依赖变更。它还会追用户输入从哪里进来，又经过了哪些地方。

这是 Cursor 官方给出的审查评论示例。它的价值不在于多了一条评论，而是把「漏洞」具体到输入怎样抵达危险调用点，后面的人才能知道该修哪里。

很多安全事故并不是有人手写了一段电影里那种黑客代码。更常见的是一个参数一路传下去，某处校验漏了，一次重构把旧的权限判断绕开了。PR 本身看起来没毛病，甚至测试也在跑。可如果没人顺着输入路径走一遍，问题会躲得很舒服。

Cursor 给每个发现附上严重程度、攻击路径和修复建议。团队还能补自己的规则，例如外部调用必须经过哪个客户端，或者哪些表不该在请求处理器里查询。这个部分我很买账。通用安全扫描能发现公共漏洞，真正让团队睡不踏实的，往往是那条只有你们自己知道的规矩。

当然，别把它当成安全签字机。官方明确说草稿 PR 会跳过，Security Review 做的是报告可被利用的问题，不是替团队决定风险能不能接受。它也不会替你理解业务的例外，更不能替你背一次错误的权限设计。

先把四个问题塞进 PR

Cursor 这次真正可抄的，不是某个 bot 的名字，而是把验证提前写进交付过程。

下一次要发一个有风险的改动，可以先在 PR 里留下面这张小卡片。没有 Cursor 也照样能用。

这次改动想改善什么
上线后最先看哪两个信号
预发布和生产各自怎样算通过
信号变坏时谁判断，谁有权暂停或回滚

这四句看上去很基础，很多时候却没人写。大家把注意力都投给了生成代码、挑模型、压 token，真正进入生产后，回答「它现在好吗」还得翻好几个页面，临时拉群，顺便祈祷告警不要在吃饭时响。

Rollouts 提醒我们，监控不是上线后的保安，而是 PR 的一部分。Security Review 也提醒我们，安全不是合并前点一下的待办，而是每一次改动都该带着的上下文。

Cursor 目前把这两个 bot 放在 Teams 和 Enterprise 计划里，Rollouts 还需要接入源代码管理、部署系统和遥测供应商。它不是装上就能让交付自动变聪明的魔法棒。你的日志、指标和部署事件如果本来就是散的，它只会更诚实地告诉你哪里看不清。

但我还是喜欢这个诚实。

AI 写代码跑得再快，最后总要落到一次真实的部署。回滚的按钮继续留在人手里，验证的证据早点放回 PR 里。这样等异常真的出现，团队看到的就不只是红灯，而是一条能顺着走回去的路。

你们团队现在的 PR 里，会写上线后要验证的信号吗？还是依旧等告警响了才开追悼会？