Cursor Bugbot 从用户反馈中自动生成规则：代码审查解决率达 78%，超越所有竞品

从 52% 到 78%：自学习系统做了什么

Cursor 的 Bugbot 于 2025 年 7 月从 beta 正式发布，初始解决率约 52%。所谓"解决率"：Bugbot 提出的代码审查评论，在 PR 合并前被开发者采纳修改，由 LLM judge 判断该评论是否被处理。

一年内从 52% 提升到 78.13%，且在分析的 50,310 个 PR 中超越所有同类竞品。Greptile 是最接近的竞争对手，解决率 63.49%，差距约 15 个百分点。

这个提升来自一套自学习机制的引入——本质上是把用户的实时使用反馈，自动转化成影响未来审查行为的规则。

三个学习信号

信号一：Reaction 反馈（downvote）

当用户对 Bugbot 的评论点 downvote，系统记录这是一次"无用发现"的信号。这是最直接的负反馈渠道：用户明确表态这条审查意见没有价值。

信号二：开发者回复

当开发者在 Bugbot 评论下写回复，解释为什么这里不需要修改，或者提供背景上下文，这些文字成为学习素材。系统分析这些回复，了解当前代码库的特殊约定或者审查偏好，用于优化未来的审查。

信号三：人工审查员标注的遗漏

当人工代码审查员指出 Bugbot 本应发现但没有发现的问题，这些标注构成了能力边界信号——告诉系统自己在哪些类型的问题上存在盲区。

规则生成机制

这三类信号经过汇总后，系统将其转化为候选规则（candidate rules）。候选规则不会立即激活——它需要在真实 PR 上积累足够的支持证据才能获得"活跃状态"，开始影响后续审查。

反过来，已经激活的规则如果持续收到负面反馈，会被系统自动禁用。这是一个双向的规则生命周期：有用的规则被强化，无用的规则被淘汰。

用户也可以在 Cursor Dashboard 手动查看、编辑或删除规则，保留完整的人工控制权。

规模数据

自从推出学习规则 beta 功能，超过 11 万个代码仓库启用了学习能力，累计生成 4.4 万条规则。

这意味着平均每个仓库生成约 0.4 条规则——不多，但代表这些规则是经过足够多用户互动才产生的，而不是随机噪声。从规模来看，这是目前可见的最大规模实时 RLHF 部署之一，应用于代码审查领域。

竞品对比

数据基于 50,310 个公开仓库 PR 的分析，使用 LLM judge 判断评论是否在 PR 合并前被采纳。

实际意义

Bugbot 的这个设计解决了代码审查工具的一个老问题：通用 AI 审查工具总会产生大量"通用但不相关"的评论——检测到了业界常见 pattern，但完全不了解这个特定团队的代码规范和优先级。

通过团队级规则的自动生成，Bugbot 正在把"通用 AI 审查"转变为"了解这个团队习惯的 AI 审查"。这类定制化能力是代码审查工具从"有用"到"真正被采纳到 CI/CD 流程"的关键跨越。

用户可以通过 Cursor Dashboard 对历史 PR 进行 backfill，让系统从存量数据中提取规则，加速学习曲线的启动。