Cursor在企业版里加了两个自动审查的机器人，一个管合并前的代码问题，一个管部署后的效果回看。两项能力都不在个人版里。
Security Reviewer在合并请求阶段介入，检查注入、越权、密钥硬编码、依赖漏洞这几类问题。审查结果以评论形式落在请求上，一条意见对应一处代码位置。它还能说出这段代码为什么可疑，而不是只报一个规则编号。
它的位置在人和合并按钮之间，输出是可以反驳的意见，不是一票否决。是否阻断合并由仓库规则决定，这条边界让误报可以被人推翻，也让漏报不必由它承担全部责任。审查范围只覆盖本次改动。历史代码里的问题不会被顺带翻出来。
与静态扫描的区别在于上下文，它读的是这次改动涉及的业务代码，而不只是模式匹配。数据流从哪个参数进来、经过哪些分支、最终落到哪个查询或哪次写文件，这些要靠读代码才能连起来。规则引擎需要事先写好规则才认得出来。这类审查不依赖规则库。
第一次误报会认真看，第十次就开始批量忽略，到那时真问题也一起被忽略，这类工具能不能长期开着，取决于误报率，也取决于意见写得够不够具体。
规则固定的扫描器误报高，团队会逐渐忽略它的提示。基于模型判断的审查有同样的风险，只是表现不同，它倾向于报告看起来可疑但没有实际影响的改动，比如日志里出现的疑似密钥、测试代码里的硬编码凭证、示例配置里的占位密码。审查意见如果长期停留在这一类，价值会被消耗掉。可用的做法是把这些噪音源在配置里逐条排除，让审查只看生产代码路径，别把示例文件当成业务代码来读。
Rollouts管的是另一半，合并之后。它跟着一次发布从合并请求一直跟到部署，中途的每一步都能对上，把谁改的和线上变差连了起来，此前这两件事靠人工在发布记录和监控面板之间对照，跨两个系统。
部署完成后把线上指标与基线对比，异常时给出暂停灰度或开回滚单的操作。指标是现成的，难点在归因，发布窗口内同时有流量波动、第三方接口抖动，都给不出干净的对照。
代价是它需要一个可对比的基线，基线要靠时间积累，新项目头两个月基本用不上。基线一旦被一次带问题的发布污染，后面几次对比都会失真，回滚之后要重新取一段干净窗口。
基线怎么取、取多长的时间窗口、哪些指标算异常，这些配置决定报警的准确度。配置得松，问题漏过去；配置得紧，正常的发布波动都会被拦下，小流量站点的指标噪声大，同一段代码在不同时段跑出来的数字差得远，灵敏度上不去。
两个机器人覆盖发布流程的两端，中间的人工评审没有被替代，企业版的门槛也在提示同一件事，这套能力面向有明确发布流程、有灰度机制、有监控基线的团队。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
