Cursor Bugbot：填补AI生成代码的安全漏洞

4月调查Lovable漏洞事件时，老实说，我开始担心自己的代码了。

我构建内部工具的典型流程是四个步骤：「在Cursor中整理需求 → 生成代码 → 测试 → 部署」。我让AI生成SQL查询，只要测试通过就推送到生产环境。安全检查：零。

「能跑的代码可能存在漏洞」这种感觉，之后一直没有消散。

2026年6月3日，WIRED.jp报道了Cursor的新功能「Bugbot」——一套利用AI自动检测AI生成代码中的漏洞的系统。这是氛围编程（vibe coding）者长期面临的安全问题，终于有了具体的解决手段。

以下从氛围编程者的视角，梳理从4月Lovable漏洞到今天Bugbot的历程。这是关于「能跑」之后该做什么的话题。

4月Lovable漏洞揭示了「漏洞的本质」

2026年4月，安全研究公司Tenzai发布了一份令人震惊的报告。在分析约1,645个Lovable构建的应用后，他们发现其中10.3%存在某种安全缺陷。

换算成绝对数字：169个应用存在漏洞。

我看到这个数字时，第一反应是「这不只是Lovable的问题」。不管用的是Cursor、Claude Code还是别的什么工具，只要让AI生成代码却不认真阅读，同样的结构性问题就会发生。

在客户成功领域工作多年，我听过数千次用户反馈。「应该没问题的，但就是不对。」「一碰就坏了。」「数据乱了。」几乎每次，都是做的人「只确认了能跑就发布了产品」。氛围编程正是携带着这种结构。

你没有「写」代码，所以也没有「读」代码。逐行理解生成代码的习惯很薄弱。「跑通了」就成了终点。在这个循环中，安全问题被悄悄略过。

让我整理几个具体的风险模式。

SQL注入是一种通过表单或搜索框发送恶意SQL语句、非法操控数据库的攻击。AI生成的代码特别容易出现这种风险。

# 错误示范：用f-string将用户输入直接嵌入SQL查询
user_id = request.form['id']
query = f"SELECT * FROM users WHERE id = {user_id}"
cursor.execute(query)
# 若用户输入「1 OR 1=1」，所有用户数据都会被返回

# 正确示范：使用参数化查询隔离输入值
user_id = request.form['id']
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

AI可以把两种写法都作为「能跑的代码」生成出来。错误的写法确实能运行，但有漏洞。

**XSS（跨站脚本攻击）**是将恶意脚本嵌入网页、在浏览者浏览器中执行的攻击，发生在用户输入被直接输出到HTML的场景。

// 错误示范：通过innerHTML直接反映用户输入
document.getElementById('output').innerHTML = userInput;

// 正确示范：用textContent将其作为文本处理
document.getElementById('output').textContent = userInput;

不读代码很难注意到这两行的区别。因为行为看起来没有变化，测试也发现不了。

认证逻辑错误也是常见模式。管理员权限检查条件写反了。密码以明文存储。会话管理不足。这些都是AI容易作为「能跑的代码」输出的模式。

我以前做的一个用Slack查询数据库的Bot，4月报告出来后重新读了一遍。发现有些地方在用f-string拼接查询，而且完全没有验证来自Slack的输入值。现在想起来真是捏一把汗。

Tenzai的报告告诉我们的不是「Lovable特别差」，而是「整个氛围编程都携带着这种结构」的现实。

Cursor Bugbot是什么

2026年6月3日，WIRED.jp报道Cursor发布了「Bugbot」。

Bugbot的理念很简单。用AI从安全角度审查AI写的代码。通过将「生成」和「验证」分离，一个AI可以发现另一个AI遗漏的问题。

想象一下资深工程师的代码审查：「这个SQL查询没问题吗？」「这个输入值有在验证吗？」——AI来承担这个角色。就像有一位比自己更有经验的工程师坐在旁边。

作为客户成功出身的人，我深知「从第三方视角读代码」的价值。大多数作为用户反馈送来的Bug，都发生在制作者认为「代码没问题」的地方。由生成代码的同一个AI来验证是没有意义的。需要一个用不同视角读代码的机制。

传统的代码检查工具（linter）能检测语法错误，但不擅长「这个输入值在用于SQL查询前应该先验证」这样的上下文判断。基于AI的Bugbot能读懂代码的意图并指出风险。

根据报道，基本工作流程如下：写完代码后调用Bugbot，它扫描代码并列出疑似存在安全风险的位置，为每个问题展示问题内容和修复方向，然后在编辑器内发出修改指令并再次扫描。支持语言和详细规格请在Cursor官方页面确认最新信息。

这个「写 → 验证 → 修复」的循环在Cursor内部完结。无需将代码粘贴到外部安全扫描工具，也不需要切换工具。

Bugbot出现之前，氛围编程者在安全方面几乎没有什么现实可行的选项。「小心地读代码」——没有专业知识很难做到。「委托安全专家」——成本上不现实。「部署后发现问题再修」——太晚了。

Bugbot增加了「在编辑器内问AI」这个选项。

不过，它并非万能。源于复杂业务逻辑的安全问题，或者架构层面的设计失误，仅靠AI可能无法检测。把Bugbot当成「完全安全」来用是危险的。正确的定位：「比什么都不做好得多的安全网的第一层」。

Bugbot擅长的安全模式

整理一下AI代码审查容易检测的模式。

硬编码的认证信息是最容易发现的类别。检测代码中直接写有API密钥、密码、访问令牌的情况。

# 错误示范：在代码中直接写入API密钥
api_key = "sk-1234567890abcdef"
openai.api_key = api_key

# 正确示范：从环境变量读取
import os
api_key = os.environ.get("OPENAI_API_KEY")

代码一推送到GitHub，信息立即泄露。AI生成的示例代码中硬编码很多，直接使用就会有风险。我自己也踩过坑。「先让它跑起来」写的代码，往往就这样保留下来了。

未验证的用户输入也是检测对象。Bugbot指出从表单或外部API获取数据后未经验证就使用的位置——缺少类型检查、长度限制、输入值净化（sanitize，无害化处理）的代码。

不安全的文件操作也在检测范围内。直接使用用户指定文件路径的代码，存在目录穿越攻击风险。

# 错误示范：直接打开用户指定的路径
filename = request.form['file']
with open(f"/uploads/{filename}", 'r') as f:
    content = f.read()

# 发送「../../etc/passwd」就能读取系统文件

给内部工具加文件上传功能时，很容易写成这样。因为能用又方便，不知不觉就一直用下去了。

认证和授权逻辑检查也在范围内。管理员检查条件写反了、权限确认位置不当——这些正是不读代码的氛围编程者最难发现的问题。

关于依赖库的漏洞检测功能，等待Cursor官方信息。如果有相当于npm audit或pip-audit的功能，就能发现库层面的风险。我的内部工具中有几个版本管理比较粗放的库。如果这一层也被覆盖，Bugbot的价值将进一步提升。

将Bugbot融入氛围编程者的开发流程

具体思考如何将Bugbot融入实际开发流程。

我构建内部工具的流程是：在Cursor中将需求整理成提示词，生成代码，测试，部署。四步。加入Bugbot后变成：

步骤1：在Cursor中输入需求和规格作为提示词
步骤2：AI生成代码
步骤3：功能测试（确认是否按预期运行）
步骤4：调用Bugbot进行安全扫描
步骤5：确认指出的问题并发出修改指令
步骤6：再次扫描确认问题归零
步骤7：部署

在原来四步的基础上增加三步。额外工作大约5到10分钟。

Bugbot的调用方式和快捷键请查看Cursor官方文档。概念上的流程不变。

「调用Bugbot很麻烦」的感觉我理解，我一开始也会这么想。但生产部署后发现安全问题的代价——修复、应急响应、信任损失——加在一起是完全不同量级的。5分钟的确认是便宜的保险。

4月Lovable应用出现漏洞，我认为也是「只确认能跑就发布」不断积累的结果。

如果在团队中开发，把Bugbot扫描加入PR检查清单的流程也很有效。将「Bugbot扫描完成」作为合并条件，就能为团队所有人的代码铺开安全网。

给Claude Code用户补充一点：Bugbot是Cursor的功能，仅凭Claude Code无法使用。不过，在Claude Code中也可以用提示词请求同样的审查。示例提示词：「请检查这段代码的安全风险，重点检查SQL注入、XSS、认证逻辑错误、硬编码的认证信息。」体验没有Bugbot那么自动化，但能覆盖同样的检查维度。

关于Claude Code的基本使用方法，Claude Code入门：3个判断轴可作参考。

「能跑就行」之后

「安全风险」在对氛围编程的批评中反复出现。「AI生成的代码漏洞一堆」这个说法，在4月的Lovable事件中被数字证实了。

以前我对这种批评无言以对。即使知道可能有漏洞，也没有检查的手段。只能用「现在还能跑，应该没事」这种自我辩解来结束。

Bugbot的出现，给这个问题带来了真正的答案。生成代码、运行Bugbot、修复被指出的问题。这三步现在触手可及了。

只要这个循环能运转，「能跑」就能变成「能跑，且完成了安全确认」。当然并非万能，Bugbot也有检测不到的局限。架构层面的问题在很多情况下超出AI的判断范围。即便如此，也和「什么都不做」是截然不同的。

安全对策曾经是「只能交给专业人士」的事情。Bugbot把其中一部分带到了氛围编程者伸手可及的地方。

作为重新找回对代码热情的人，我认为这个变化意义重大。「能做出来」→「能安全地做出来」。氛围编程向真正的开发又迈进了一步。

总结

Cursor Bugbot是一项利用AI自动检测AI生成代码中安全风险的功能。WIRED.jp于2026年6月3日报道。

整理氛围编程者从今天起可以改变的事情。

今天开始的3个行动

• 将Cursor更新到最新版本，确认Bugbot是否可用
• 对一个现有内部工具试用Bugbot，看看会指出什么问题
• 养成习惯：代码生成 → 功能测试 → Bugbot扫描 → 部署

需要掌握的安全基本原则

• SQL查询用参数化查询编写。f-string直接拼接虽然能跑，但有漏洞
• 不要在代码中硬编码API密钥或密码，养成提取到环境变量的习惯
• 始终验证用户输入，将类型、长度、格式检查设为默认
• 不要过度信任Bugbot，设计层面的安全仍然需要人工判断

4月Lovable漏洞报告出来后感到「我的代码没问题吗？」的人，我相信不只是我一个。Bugbot给这个问题提供了具体的答案。

对一直在「能跑就行」上构建的氛围编程者，下一步已经到来。先更新Cursor，试一试Bugbot吧。