Cursor Bugbot 会跟 PR 学：发现问题里约 78% 合并前已修好

很多人装 Cursor IDE 是为了补全和 Agent 改文件；另一块正在变重的是代码审查。Cursor 说他们的 code review agent 现在能从 PR 上的活动里学习，而且几乎是实时地自我改进。配的数字也很硬：发现的问题里，大约 78% 在 PR 合并前就已经被解决掉了。

这话听着像广告，但图比口号好懂。我们对着散点图拆一下，再讲你在仓库里怎么用，而不是干背百分比。

图在说什么：找得更多，修好的比例也在涨

封面图标题大意是：Bugbot 的 resolution rate 在上升，同时它每次能揪出的 bug 也更多。几根轴大致是这样：横轴是 Average number of bugs per run，也就是每次运行平均发现多少问题；纵轴是 Resolution rate，解决率；每个点是陆续上线的实验（experiments shipped）；时间从大约 Aug 2025 走到 Apr 2026，点整体往右上挪。

早期的点大概在「发现偏少、解决率不到一半」那一带；到 2026 年春，横轴和纵轴都抬上去了，解决率靠近官方说的 78%。关键不是「只刷解决率、少报 bug」，而是检出强度和解决率一起走高。这才像真在学，而不是把考核指标做漂亮。

78% 别理解成「审查完就绝对干净」

这句话的主语是 issues found，是它已经标出来的问题，不是「仓库里所有未知缺陷」。更直白的读法是：Bugbot 在 PR 上甩出一批问题，到合并那一刻，这批里大约八成已经关掉或修好，剩下的可能是误报、延后，或者合并时仍没处理。所以它更像「审查意见的消化率」，不是「上线零 bug 保证」。人审、CI、上线监控该在的还得在。

和 Cursor agent / 多 Agent 验证怎么串起来

写代码的 Cursor agent 负责改，审查 Agent 负责找茬，中间要是再有一个「跑测才算过」的 Verifier，形状就完整了。你可以这么记：改文件的 Agent 把 diff 做出来；Bugbot 这类审查 Agent 盯 PR 里的风险点，并跟着评论和修复动作更新自己的判断；Verifier 的思路是失败就打回再改（见 多 Agent + Verifier）。Rules、Skills 仍然有用：把团队反复踩的坑写成可复用约束，审查和生成都能少说废话，可对照 Agent / Rules / Skills / MCP。关键词表里 cursor skills、cursor agent 的搜索量也不低，说明不少人已经在找「怎么把 Agent 用稳」，而不只是下载安装。

你在 PR 上能立刻改的三件事

不必等自己做出一张 78% 的图。第一件，让审查意见可关闭：每条问题对应一个可验证的动作（补测试、改边界、回滚某个文件），别留「建议优化一下」这种空话。第二件，合并前扫一遍未关闭项：官方指标盯的是「合并时还剩多少」，你团队也可以每周看一眼，审查找出的问题有多少进了主干还红着。第三件，把误报反馈回去：「实时自学」吃的是 PR 上的真实互动，乱点 resolve 或从不反驳误报，模型学到的就是噪声。

怎么确认自己没读飞

拿最近合并的 10 个 PR 做个小统计就行：审查工具（或人工）提出的问题数、合并前真正修掉的数量、误报占比。要是「提出很多、合并前几乎不动」，你缺的是流程，不是再买一个更吵的 bot。要是「提出少、但合并前基本清完」，再考虑把检出灵敏度打高，这张散点图走的就是后半段路线。