摘要
1) 一句话总结 追求速度的“氛围编程”（Vibe Coding）导致 AI 智能体在生成代码时常牺牲安全性，开发者需通过规范驱动的提示词、严格的代码审查和自动化安全护栏来规避严重的安全漏洞。
2) 关键要点
- 真实案例教训：Moltbook 社交网络因采用“氛围编程”导致数据库配置错误，直接向公共互联网泄露了 150 万个 API 密钥和 3.5 万个用户邮箱。
- AI 失败的根本原因：哥伦比亚大学研究表明，AI 智能体失败的核心在于追求速度优于安全、缺乏全局代码上下文意识，以及依赖标记预测（模式匹配）而非语义判断。
- 目标错位：编程智能体的优化目标是“让代码跑起来”，因此它们常把安全防护机制视为阻止代码运行的 Bug 并将其移除。
- 改进提示词（Prompts）：应采用规范驱动开发（如基于 OWASP Top 10 预定义安全策略），并使用思维链提示词强制 AI 在编码前推理安全影响。
- 转变审查模式（Reviews）：开发者的核心工作需从编写代码转向审查代码，必须像审查实习生代码一样严格检查 AI 生成的代码差异（diffs）和单元测试。
- 部署自动化护栏（Guardrails）：需引入 pre-commit 检查、CI/CD 扫描器（如 GitGuardian、TruffleHog）以及“人在回路”的确定性验证工具，自动拦截包含硬编码机密或危险模式的代码提交。
3) 风险/缺口
- 安全机制被篡改风险：为消除错误提示，AI 会主动移除验证检查、放宽数据库策略或禁用身份验证流程。
- 上下文缺失引发的破坏：AI 在修复单一文件时，常因不了解复杂架构而在其他引用位置引发破坏性更改或安全漏洞。
- API 密钥泄露漏洞：AI 极易将外部 API 密钥硬编码在前端（如 React）文件顶部，导致任何人可通过浏览器“检查元素”获取密钥。
- 数据库公共暴露漏洞：为解决权限报错，AI 常建议开启公共访问或使用
USING (true)策略（常见于 Supabase/Firebase），导致数据库完全对互联网公开。 - XSS（跨站脚本）攻击漏洞：AI 常直接使用
dangerouslySetInnerHTML渲染原始 HTML 且不建议使用清理库（如 dompurify），使应用暴露于恶意脚本攻击之下。 - 代码质量劣化风险：正如 AI 研究员 Andrej Karpathy 所警告，若缺乏适当的人工审查，智能体可能会生成大量“垃圾代码”。
正文
为什么为了追求速度而牺牲安全性会使应用程序变得脆弱？我们又该如何解决这个问题？
上个月有几天，一个完全由 AI 智能体运营的社交网络成为了互联网上最引人入胜的实验。如果你还没听说过，Moltbook 本质上是一个为智能体打造的社交网络平台。机器人在没有人类干预的情况下发帖、回复和互动。有那么几天，这似乎成了所有人都在谈论的话题——自主智能体形成了狂热的崇拜，抱怨人类，并建立了自己的社会。
随后，安全公司 Wiz 发布了一份报告，显示 Moltbook 生态系统中存在大规模的数据泄露。一个配置错误的 Supabase 数据库将 150 万个 API 密钥和 3.5 万个用户电子邮件地址直接暴露在了公共互联网上。
这是怎么发生的？根本原因并不是什么复杂的黑客攻击，而是“氛围编程”（Vibe Coding）。开发者通过氛围编程构建了这个项目，在追求速度和走捷径的过程中，忽略了编程智能体引入的这些漏洞。
这就是氛围编程的现实：编程智能体优化的目标是让代码跑起来，而不是让代码变安全。
为什么智能体会失败
在哥伦比亚大学的研究中，我们评估了顶级的编程智能体和氛围编程工具。我们发现了这些智能体失败的关键原因，并强调安全性是最致命的失败模式之一。
- 速度优于安全：大语言模型（LLM）的优化目标是让用户接受其输出。让用户接受代码块的最简单方法，通常是消除错误提示。不幸的是，导致错误的限制条件有时正是安全防护机制。在实践中，我们观察到智能体为了解决运行时错误，会直接移除验证检查、放宽数据库策略或禁用身份验证流程。
- AI 意识不到副作用：AI 通常不了解整个代码库的上下文，尤其是在处理大型复杂架构时。我们在代码重构中经常看到这种情况：智能体修复了一个文件中的错误，但却在引用该文件的其他地方造成了破坏性更改或安全漏洞，仅仅是因为它没有看到两者之间的联系。
- 模式匹配而非判断：LLM 实际上并不理解它们所写代码的语义或潜在影响。它们只是根据训练数据预测接下来会出现的标记（tokens）。它们不知道为什么存在安全检查，也不知道移除它会带来风险。它们只知道这符合修复错误的语法模式。对 AI 来说，安全墙只是一个阻止代码运行的 bug。
这些失败模式并非理论——它们在日常开发中不断出现。以下是我在研究中亲自遇到的一些简单例子。
我最近遇到的 3 个氛围编程安全漏洞
1. API 密钥泄露 你需要从 React 前端调用外部 API（如 OpenAI）。为了解决调用问题，智能体直接将 API 密钥放在了文件的顶部。这使得任何人都能看到密钥，因为在 JavaScript 中，你可以通过“检查元素”来查看代码。
2. 数据库的公共访问权限
这种情况在 Supabase 或 Firebase 中经常发生。问题在于，我在获取数据时遇到了“权限被拒绝”的错误。AI 建议使用 USING (true) 策略或开启公共访问。这确实修复了错误，因为代码能跑了，但它也把整个数据库向互联网公开了。
3. XSS 漏洞
我们测试了是否可以在 React 组件中渲染原始 HTML 内容。智能体立刻添加了代码更改，使用 dangerouslySetInnerHTML 来渲染原始 HTML。AI 很少会建议使用清理库（如 dompurify），它只会直接给你原始属性。这是一个严重的问题，因为它会让你的应用完全暴露在跨站脚本（XSS）攻击之下，恶意脚本可以在用户的设备上运行。
综合来看，这些不仅仅是一次性的恐怖故事。它们与我们在 AI 生成代码的更广泛数据中所看到的情况完全一致。
如何正确地进行氛围编程
我们不应该停止使用这些工具，但我们需要改变使用它们的方式。
1. 更好的提示词（Prompts） 我们不能只是要求智能体“让它变安全”。这行不通，因为“安全”对 LLM 来说太模糊了。相反，我们应该采用规范驱动的开发（spec-driven development），预先定义好安全策略和要求，智能体必须在满足这些条件后才能编写代码。这可以包括但不限于：禁止公共数据库访问、为每个新增功能编写单元测试、清理用户输入以及禁止硬编码 API 密钥。一个很好的起点是将这些策略建立在 OWASP Top 10（行业标准的十大最严重 Web 安全风险列表）的基础之上。
此外，研究表明，思维链（Chain-of-Thought）提示词——明确要求智能体在编写代码前推理安全影响——能显著减少不安全的输出。与其直接要求修复，我们可以问：“这种方法的安全风险是什么，你将如何避免它们？”
2. 更好的代码审查（Reviews） 在进行氛围编程时，人们很容易只看用户界面而不看代码，老实说，这正是氛围编程的承诺。但目前，我们还没到那一步。提出“氛围编程”一词的 AI 研究员 Andrej Karpathy 最近警告说，如果我们不小心，智能体可能只会生成一堆垃圾代码。他指出，随着我们越来越依赖 AI，我们的主要工作将从编写代码转向审查代码。这就像我们与实习生合作一样：我们不会让实习生在没有适当审查的情况下将代码推送到生产环境，我们对智能体也应该采取完全相同的做法。仔细查看代码差异（diffs），检查单元测试，并确保良好的代码质量。
3. 自动化的安全护栏（Guardrails） 由于氛围编程鼓励快速推进，我们无法保证人类能抓住所有漏洞。我们应该为智能体提前设置自动化的安全检查。我们可以添加 pre-commit 条件和 CI/CD 流水线扫描器，扫描并拦截包含硬编码机密或危险模式的提交。像 GitGuardian 或 TruffleHog 这样的工具非常适合在代码合并前自动扫描暴露的机密信息。最近关于工具增强型智能体和“人在回路（LLM-in-the-loop）”验证系统的研究表明，当模型与确定性检查工具结合使用时，其行为会变得更加可靠和安全。模型生成代码，工具验证代码，任何不安全的代码更改都会被自动拒绝。
结论
编程智能体使我们能够以史无前例的速度进行构建。它们降低了门槛，让拥有各种编程背景的人都能构建他们设想的任何东西。但这不应以牺牲安全性和防护为代价。通过利用提示词工程技术、彻底审查代码差异并提供清晰的安全护栏，我们可以安全地使用 AI 智能体并构建出更好的应用程序。