Bugbot来了——Vibe Coding一直缺少的自我修复闭环，终于合拢

让我来讲讲那天早上，我在Slack里悄悄打下”Bugbot终于来了”这行字的故事。

过去两个月，我一直把Vibe Coding（AI辅助编程）当作”危险的玩具”来写。这条线索从三月份开始——WIRED的一项调查成为导火索：在1,645款用Lovable生成的应用中，10.3%存在严重的RLS（行级安全）漏洞。五月，我又横向对比了五大主流AI编程工具，整理出一批”能跑、但其实坏了”的案例。那一周，我还收到了大量读者来信，问的都是同一个问题：“说到底，在我自己的生产环境里该怎么防？”

2026年5月13日，WIRED.jp率先报道：Cursor发布了”Bugbot”——一个由AI审查并修复另一个AI所写代码的功能。这么说听起来不够震撼，但我的感受是：Vibe Coding”解决篇”的最后一块拼图，终于就位了。

更巧合的是，就在前一天，我刚写完一篇分析Cursor公司的文章，介绍了Fortune为何用”at a crossroads（站在十字路口）“来描述它。就在”十字路口”报道的一周后，Cursor自己给出了一个答案。这种巧合，不写不行。

---

“十字路口”报道次日，Cursor自己给出了答案

在上一篇文章（Cursor是”史上增长最快的B2B SaaS”，Fortune为何却写”十字路口”？）中，我介绍了Fortune的分析：一家三年内年度经常性收入（ARR）达到约2000亿日元规模的公司，标题却写着”at a crossroads”。原因很简单——如果Cursor只是”写代码的工具”，迟早会被Claude Code或Codex吞掉。

写那篇文章的时候，我已经有几分预感：Cursor大概不会再只押注”写代码”这一侧。

第二天，WIRED.jp的标题出来了：“Cursor发布Bugbot——AI自动检测并修复AI所写代码的功能。“咖啡差点打翻——这是我当时的真实反应。**从”写代码的工具”，变成”写了还能自我修复的工具”。**这是企业对Fortune所指弱点的最快速回应。

有一点值得单独强调：这不只是一个功能发布。Cursor在做的，是把”十字路口”重新定义为”自我修复闭环的起点”，完成了一次战略定位的转换。所以这则速报的分量，不能用功能列表来衡量，而要压缩成一句话：行业的战场移动了。

我是一个曾经失败过的工程师。Cursor帮我重新找回了开发的感觉，Claude Code让我完全恢复了写代码的动力。正因如此，我能从身体层面感受到这件事有多重要。Vibe Coding终于进入了一个新阶段——工具本身开始回答那个问题：“跑起来了……但真的没问题吗？”

先说一个预期管理：Bugbot不是魔法。后半部分我会拆解五个常见误解，解释为什么专业代码审查员不会消失。如果现在不把预期校准好，我们很可能重新陷入”能跑就行”的陷阱。

---

Bugbot是什么——“写代码”和”审代码”第一次分开的瞬间

Bugbot是Cursor于2026年5月13日发布的AI代码审查专用功能。据WIRED.jp速报，它会自动在Pull Request（PR，即代码变更提案单元）上留下评论，指出潜在的Bug、类型错误和安全隐患。从架构上看，它的定位接近现有的CI（持续集成）工具。

核心点在于：Cursor第一次把”写代码的AI”和”审查代码的AI”拆分开来。过去的Cursor全力押注写作辅助，写出来的代码对不对，要靠人在本地跑一遍来验证。我自己一直也是这么做的。

“为什么不让同一个AI边写边审？“——我最初也这么想。但问题在于：让同一个AI写完再审，只能在自己的假设框架内思考，就像自己出题自己批卷。所以，给不同角色配不同AI，是有实质意义的。

让我觉得”这个设计做对了”的地方，是Cursor把Bugbot放在了Pull Request这一层。PR是代码进入生产环境前的最后关卡。在这里常驻一个AI审查员，这个设计决策传递出一个信号：Cursor接受了专业共识——代码审查是不可跳过的步骤。

Vibe Coding奉行的”速度优先”文化，现在把”暂停、检查”这个环节内化进来了。对我来说，这才是这则新闻真正的核心。

Bugbot支持的语言、仓库格式和定价（免费还是付费附加功能），在WIRED.jp速报阶段尚未明确。等Cursor官方发布正式版本说明后我会补充。目前我的推测是先支持TypeScript、Python、Go和Rust——但这只是基于早期报道的猜测。

---

为什么说这是转折点——把三月到五月的三起事件再摆一遍

我说这是转折点，是因为Bugbot的发布只有放在过去两个月的三起事件旁边，才能真正立起来。每一件事单独看似乎是不同话题，但串在一起，就是一条完整的线。

事件一：三月，Lovable应用里的170个后门

第一次冲击，是我三月写过的那篇：Vibe Coding的170个后门。WIRED审查了1,645款Lovable构建的应用，10.3%存在严重的RLS漏洞。用白话说：用户A的私人数据，用户B可以直接读取。

为什么会这样？当你让AI”帮我做一个带登录功能的SaaS”，AI会走最短的可运行路径：创建Supabase表、接通认证、保存数据。“其他用户看不到这条数据”这个配置步骤，AI不会主动去做。不显式要求，表就按默认的开放状态发布出去了。

这是Vibe Coding”能跑、但其实坏了”的第一种形态。

事件二：五月，生产数据库删除事件

五月，我在在崩溃之前写好设计图里介绍了另一起事件：一位开发者让Cursor”清理不需要的表”，AI没有区分生产环境和测试环境，直接执行了DROP TABLE。数据后来恢复了，但当事人写道那晚根本没睡着。

和RLS事件是不同的故事，但根子是一样的。**AI辅助生成的”先跑起来再说”的代码，越过了本不应该被越过的防线。**Forrester针对这类问题提出了”Secure Vibe Coding”（安全Vibe编程）这一概念。

事件三：5月13日，Bugbot发布

然后就是这次的Bugbot。经过两个月”AI写的代码很危险”的积累，工具提供方终于承认了：“只靠写代码的AI是不够的——需要单独配备一个专门审查的AI。”

我把这三件事概括为：问题篇→诊断篇→处方篇。Vibe Coding大范围普及，损害案例被观测到，行业开出了药方。逻辑清晰得像教科书。所以Bugbot不是单点新闻，而是系列的终章。

---

如何使用——“能跑”变成”能跑、经过验证、可以发布”

正式版Bugbot我还没能在自己的环境里试用，以下是我设想Bugbot上线后开发流程会如何变化的推演。等拿到实机测试机会后会补充实测感受。

Before（我目前的开发流程）

# 1. 在Cursor里写代码（Vibe模式）
# 对AI说："帮我做一个带用户认证的ToDo应用"

# 2. 本地跑起来确认
npm run dev
# → 跑起来了。好。

# 3. git push
git add .
git commit -m "feat: add user auth ToDo"
git push origin main

# 4. 部署到自己的服务器
# → 跑起来了。完成。

这个流程的问题，是很容易把”能跑”误当成”没问题”。我自己在读到三月那篇Lovable事件之前，就有一个Supabase的作品集项目，没有配置行级安全就直接公开发布了。现在回想，很后怕。

After（引入Bugbot后的预想流程）

# 1. 在Cursor里写代码
# （这部分不变）

# 2. 本地跑起来确认
npm run dev

# 3. 建分支并push
git checkout -b feature/user-auth
git push origin feature/user-auth

# 4. 创建Pull Request
# Bugbot自动留下审查评论
# 例："supabase.from('todos').select() 可能未设置RLS策略"

# 5. 阅读反馈，必要时修改
# 6. 人工审查后合并

变化在于：“能跑”和”合并”之间，插入了一个AI验证步骤。就是这个看起来很小的间隙，以前一直容易被跳过，事故就从这里发生的。

提前分享一个教训，帮你省三个小时：在我能亲手验证Bugbot实际表现之前，我会继续在CI里同时跑Snyk和semgrep。AI审查是”聪明的同事”，不是”全自动的守门员”。

---

Bugbot会让专业代码审查员消失吗？

“有了Bugbot，是不是就不需要专业审查员了？“——我已经从三个人那里听到了这个问题。作为从客户成功转型到媒体运营的人，这是我想认真回答的一个论点。

**专业审查员不会消失。他们的角色会转变。**以下逐一拆解五个常见误解。

误解一：AI会把所有类型错误和安全漏洞都找出来

不准确。AI审查擅长的是基于模式匹配的Bug检测——典型的空引用、常见的SQL注入、未使用的变量等。但业务逻辑矛盾和领域特定的约束违反，AI是看不见的。“这个用户是管理员，但这个操作他不能做”——这类判断，需要真正理解业务的人才能做出。

误解二：有了Bugbot就不需要CI了

还是需要。Bugbot负责”AI驱动的语义审查”，CI负责”机械化的测试执行和类型检查”，两者工作在不同层级。我自己的开发流程里，会继续在Bugbot的PR审查步骤之前，用GitHub Actions跑lint和测试。两者并行，才能减少漏网之鱼。

误解三：人工审查员只是多了空闲时间，皆大欢喜

这里有点微妙。“挑错别字”这类简单任务确实会减少。但人工审查员需要把精力更多集中在更高层次的设计判断上——不见得更轻松。靠挑低级错误来体现价值的审查员，会面临淘汰压力。

误解四：Bugbot比Claude Code更强

两者是不同的东西。Claude Code是在命令行里写代码、编辑代码的智能体，Bugbot是PR审查智能体。它们不是竞争关系，而是互补关系。正如我在Cursor公司分析文章里写的，Cursor选择了从”只会写代码”向外延伸；Claude Code则在”写代码”这一侧深挖。两者共存。

误解五：有了Bugbot，Secure Vibe Coding就不需要了

恰恰相反。Bugbot只是把”最后关卡”自动化了，并不能消除设计阶段的质量需求。**Forrester提出的预防性设计思路——Secure Vibe Coding——有了Bugbot反而更有效，而不是更没必要。**我从三月起就一直在推这个理念。即使有了Bugbot，从源头不产生危险代码，最终还是更快。

---

给刚起步的人——失败工程师重新出发的最后一块拼图

读到这里的人里，可能有人在想：“我从来没写过代码，这个世界我真的能进去吗？“——客服团队的同事曾经多次问过我这个问题。

我的回答是：现在开始，是过去两年里门槛最低的时机。

三个理由。

第一，写代码侧的工具——Cursor、Claude Code、Copilot——已经成熟。AI写代码的速度和质量，和2024年已经是两回事。三个月前，我让现在的Cursor把我写的一个表格自动化脚本重写一遍，代码量少了三成，安全性还更高了。

第二，包括Bugbot在内的验证侧工具，开始配套了。这一点很关键。“能跑、但其实坏了”的代码，现在可以在人类没察觉的时候，被AI发现。对失败过的工程师来说，这是心理层面的安全网。

第三，案例积累。三月的Lovable事件、五月的Cursor生产数据库删除事件，是悲剧，但作为教材质量极高。“读别人的事故，绕开同样的坑”——这种学习方式，在过去两个月变得容易了很多。

我曾经坐在一个我自以为永远追不上的同事旁边，默默咽下挫败感，最终转去了客服。那段经历让我庆幸：还好没有放弃写代码。等得够久，手边的伙伴就会越来越强大。“Vibe Coding”这个词不一定适合所有人——没关系，名字不重要。借助AI，让自己的工作变得更轻松，靠自己的力量去做到。这件事的入门门槛，现在是最低的。

我打算把Cursor + Claude Code + Bugbot这三件套称为”失败工程师的复出套装”。第三块终于补上了。

写代码，让它被审查，然后发布

我真正希望的，是你不要把这篇文章当作Bugbot的功能解读来读，而是当作一段横跨三个月的三起事件来读。

• 三月，Lovable应用中发现170个后门，Vibe Coding被迫直面”能跑、但其实坏了”的问题。
• 五月，Cursor生产数据库删除事件被报道，Forrester提出”Secure Vibe Coding”作为处方。
• 五月13日，Cursor发布Bugbot，将”写代码的AI”与”审查代码的AI”分开，自我修复闭环开始运转。

“能跑就发”的时代结束了。新标准是”能跑、经过验证、再发布”。表面上看是个不起眼的变化。但我想把这一天记录下来——行业战场移动的那一天。

Cursor把”十字路口”变成了”起点”，这件事本身让我感到高兴。失败工程师们依赖的那个工具，在朝着正确的方向进化。**没有放弃，是对的。**今天写到这里就够了。

最后，想对读到这里的你提一个请求：当Bugbot在你的环境里第一次运行成功的时候，如果方便的话，请在SNS上带上话题标签”#VibeCoding解决篇”发出来。我想让失败工程师们重新站起来的这个圈子，再扩大一点点。

---

来源与参考

• WIRED.jp，“Cursor发布Bugbot——AI自动检测并修复AI所写代码”（速报，2026-05-13）
• Fortune，“Cursor at a crossroads”（出处详见Cursor公司分析文章）
• WIRED，Lovable应用调查：1,645款应用中10.3%存在严重RLS漏洞（出处详见Lovable漏洞文章）
• Forrester，“Secure Vibe Coding”理念（出处详见Secure Vibe Coding文章）
• Cursor官方博客，“Introducing Bugbot”（速报阶段详情未确认）
• Cursor官方文档（速报阶段对应语言等详情未确认）