代码审查工具正在从“提示补全”走向“主动调查”。OpenAI 披露的案例显示，CodeRabbit 正用 GPT-6.1 Sol 在复杂代码库中排查安全风险。
发生了什么
根据 OpenAI 发布的客户案例，CodeRabbit 使用 GPT-6.1 Sol 来调查复杂代码库中的安全隐患。其安全智能体面向开发者，负责审查发现的问题并给出修复建议，让开发者在此基础上判断和处置，而不是直接接受机器结论。
公开信息有限，没有披露模型调用规模、检出率或具体客户数据。可以确认的是两点：一是 CodeRabbit 把模型能力封装成了“安全智能体”这一产品形态；二是它的输出被设计成供人复核的工作流，而非自动化补丁。
为什么重要
代码审查是 LLM 落地最成熟的场景之一，但此前的形态大多是行级建议：看到可疑写法就提示。这类能力在单文件、局部上下文里表现不错，一旦进入跨模块、跨依赖的大型代码库，就容易失效——真正的安全风险往往藏在调用链、配置、权限边界和第三方依赖的交汇处，需要多步追踪才能定位。
“智能体”在这里的意义不是营销词，而是任务结构的变化：先提出假设，再去代码库里取证，然后汇总成可读的结论。这恰好是安全审查的天然形态，也是纯补全式工具难以覆盖的部分。CodeRabbit 选择在这一层叠加模型能力，说明代码审查的竞争重心正从“提示质量”转向“调查能力”。
另一个值得注意的信号是产品定位。案例强调智能体帮助开发者“审查发现与修复建议”，意味着厂商清楚安全场景的容错率极低，把最终判断权留给人。这种人在环的设计，是当前代码安全类 AI 产品比较务实的路径。
影响与看点
对开发者而言，短期变化是安全类告警的质量和可解释性可能提升：结论附带调查路径，比孤立的一行警告更容易判断真伪。对 CodeRabbit 这类代码审查平台，安全智能体是向更高价值环节延伸的抓手——审查本身客单价有限，安全与合规才是企业愿意付费的地方。
需要观察的点有三个：一是误报控制，安全告警的噪音一旦过高，开发者会迅速关闭该功能；二是复杂代码库中的上下文获取方式，检索策略和索引质量往往比模型本身更决定效果；三是与现有 SAST 工具的关系，是替代还是编排，将影响这类产品的长期位置。
一个独立判断：代码审查的下一阶段竞争，不在于谁能写出更好的建议，而在于谁能把“调查—取证—解释”这条链路做得足够稳定，让开发者愿意把安全判断的一部分工作交出去。
