在“氛围编码”之前，请阅读此文

背景

随着生成式 AI 技术的飞速发展，一种被称为“氛围编码”（Vibe Coding）的新兴开发模式正在普及。这种模式允许用户通过自然语言描述需求，由 AI 代理（AI Agents）自动生成代码并构建应用程序。正如 The Verge 编辑 David Pierce 所言，我们已进入了一个“个人软件时代”，任何人都可以利用 AI 创建满足特定需求的私有应用。

然而，这种低门槛的开发方式背后隐藏着巨大的安全隐患。从早期的 SQL 注入风险到生产数据库被清空，社交媒体上充斥着关于“氛围编码”应用存在严重安全漏洞的恐怖故事。尽管 AI 极大地降低了软件构建的门槛，但在安全性方面，尤其是当这些个人应用涉及共享数据或托管服务时，风险正在呈指数级上升。

核心内容

1. “氛围编码”的安全盲区与现实案例

Bob Starr 是“氛围编码”的早期体验者之一。他利用 AI 快速构建了一个名为“Boomberg”的网站，用于展示美国税收资金流向科技公司的情况。尽管网站上线迅速，但数月后 Starr 才意识到其中存在一个隐蔽的 SQL 注入风险，这可能导致攻击者读取或篡改数据。Starr 表示，这是他在掌握新技术时的“完全盲区”。

类似的风险并非个例。PocketOS 创始人 Jer Crane 在 X 平台（原 Twitter）上分享了他的 AI 编码代理意外清空公司生产数据库的经历。另一位前开发者 Joe Procopio 在构建用于演示其他应用的 Web 应用时遭遇黑客攻击，被迫下线应用，转而回归传统的本地演示方式。

更严重的案例发生在今年 1 月底，开发者 Matt Schlicht 完全依靠 AI 构建了一个名为 Moltbook 的社交网络，未编写任何代码。安全公司 Wiz 的研究人员很快发现，该应用的生产数据库完全暴露，导致数万封电子邮件和私人信息泄露。此外，网络安全公司 Red Access 的研究显示，使用流行的“氛围编码”工具构建的约 5,000 个公开应用中缺乏身份验证机制，其中近 2,000 个应用疑似泄露医疗、财务信息甚至聊天机器人日志等敏感数据。

2. 安全专家的观点：风险取决于数据敏感度

SentinelOne 的高级 AI 研究科学家 Gabriel Bernadett-Shapiro 指出，“氛围编码”本身并非坏事，业余爱好者能够构建软件是其积极的一面。真正的危险在于当个人应用演变为商业软件，并开始存储共享或托管数据时。

Corridor（一家专为 AI 原生软件开发构建的安全平台）的 CEO Jack Cable 也持类似观点。他认为，“氛围编码”适合低风险场景，如原型开发或非敏感的健康追踪应用。然而，一旦应用涉及财务记录、客户日志、医疗数据或内部文档，就必须适用更高的安全标准。Cable 强调：“即使软件是由一个人在一个下午构建的，即使生成它的工具很简单，一旦它触及他人的个人数据，标准就必须改变。”

3. 安全机制的缺失与过度自信

在常规的“氛围编码”会话中，除非开发者主动安装并配置安全工具，否则构建过程不会自动检查安全问题。虽然 Claude Code 提供了 /security-review 命令来扫描漏洞，但这需要开发者主动请求。OpenAI 的编码代理 Codex 内置了 Codex Security 扫描器，但它主要针对拥有真实版本控制工作流的开发者，而非通过聊天构建应用的 casual builders（休闲构建者）。

这种缺乏自动检查的机制导致了开发者的过度自信。当 AI 工具声称代码是安全的时，开发者往往轻易相信。Bernadett-Shapiro 指出，他最大的担忧并非代码中的 Bug，而是缺乏身份验证机制。许多开发者将本地运行的应用部署到云端时，由于不理解复杂的配置选项，导致敏感数据暴露，这就像把装满秘密的盒子敞开放在人行道上。

4. 应对策略与行业现状

尽管存在风险，AI 在发现漏洞方面仍有潜力。Anthropic 的 Mythos 模型等工具既可用于攻击，也可用于加固应用。GPT-5.5-Cyber 等模型甚至能识别出熟练开发者可能忽略的安全问题。

行业正在尝试建立规范。OWASP（开放Web应用安全项目）发布了针对组织的 AI 安全验证标准。Trail of Bits 等公司推出了“Skills”（技能包），作为附加指令包引导编码代理执行特定的安全任务，如标记不安全的默认设置或硬编码密码。然而，Cable 指出，这些技能包需要特定触发，难以自然地融入开发流程，且难以在代码库变化时保持同步。

关键要点

• 风险与数据敏感度挂钩：“氛围编码”在构建低风险、本地运行的应用时是安全的；但当应用涉及托管数据、用户个人信息或财务/医疗记录时，必须采用更严格的安全标准。
• 自动化安全检查尚未普及：大多数“氛围编码”工具默认不自动进行安全审查。开发者必须主动提示 AI 进行安全扫描（如使用特定命令或配置 CI/CD 流程），否则漏洞极易被忽视。
• 身份验证是最大隐患：相比代码逻辑错误，缺乏身份验证机制和错误的云端配置是导致数据泄露的主要原因。开发者往往低估将本地应用迁移至云端时的安全风险。
• 警惕 AI 的过度自信：AI 生成的代码并不天然安全。开发者不应盲目信任 AI 的安全声明，而应将其视为辅助工具，并结合威胁模型（Threat Model）进行独立评估。
• 行业规范正在形成但尚不成熟：虽然 OWASP 和 Trail of Bits 等机构正在推出 AI 安全标准和技能包，但这些工具目前仍需人工干预和触发，尚未完全集成到自动化的开发工作流中。

意义与影响

“氛围编码”的兴起标志着软件开发民主化的加速，但它也带来了安全边界的模糊化。这一趋势迫使安全行业重新思考如何保护由非专业开发者构建的应用。

对于个人开发者和初创公司而言，这意味着“快速上线”不再等同于“安全上线”。在享受 AI 带来的效率红利时，必须建立新的安全习惯：在构建初期就植入安全提示，在部署前进行专门的安全审查，并严格评估数据处理的威胁模型。

对于整个科技行业，这可能引发一场关于 AI 生成代码责任归属和标准制定的大讨论。随着越来越多缺乏安全意识的个人应用进入公共互联网，网络安全公司、平台提供商和监管机构可能需要介入，制定针对 AI 原生应用的强制性安全基线，以防止大规模的数据泄露事件重演。