Vibe coding 能几小时上线应用，但安全门槛没一起降下来

Bob Starr 用 AI 做了一个网站 Boomberg，用来展示美国税款流向科技公司的情况。网站很快上线，页面能跑，功能也成立。

几个月后，他才发现里面藏着 SQL 注入风险。The Verge 的报道没有说 Boomberg 被实际攻破，也没有说造成了损失。它说的是另一件更常见的事：一个看起来已经完成的应用，可能根本没经过线上安全审查。

这正是 vibe coding 最反常的地方。它把开发门槛降得很低，但安全门槛没有跟着降。过去很多人只会把小工具停在本地，现在可以几小时把它推到公网，直接面对真实攻击者、真实数据库和真实责任。

Boomberg 的提醒：能上线，不等于能承受攻击

Boomberg 的问题是隐藏的 SQL 注入风险。攻击者如果利用这类漏洞，可能读取或篡改本不该访问的数据。

Starr 后来修复了问题。他也把这件事称为自己学习新技术过程中的“明显盲区”。这句话比单个漏洞更重要。

很多 vibe-coded 应用的问题不在界面，也不在功能是否可用。它们真正薄弱的地方，常常在输入校验、数据库权限、密钥管理、日志监控和异常处理。

这些东西不显眼。页面不会因为少了它们立刻崩掉。但应用一旦公开部署，它们就是攻击面。

对非专业开发者来说，这里最现实的动作不是停用 AI，而是延后公开部署。先让懂安全的人看一遍，或者至少用自动化扫描、权限检查和备份流程过一遍。

能访问，不等于能上线。

风险变大，不只是因为 AI 会写错代码

把锅全甩给“AI 写错代码”太简单了。更准确的说法是：AI 生成代码、agent 执行操作、用户直接部署到公网，这三件事叠在了一起。

过去的低代码、无代码工具也降低过门槛，但很多运行在相对封闭的平台里。模板、权限、托管规则会挡掉一部分风险。

vibe coding 更自由。用户可能让 AI 写前端、后端、数据库调用和部署脚本，再接到通用云服务上运行。自由度变高，出错面也变宽。

普通代码补全还停在“建议”。开发者通常要复制、确认、运行。AI coding agent 更进一步，可以改文件、跑命令、连数据库、部署应用。

从建议变成行动，风险就变了。

如果 agent 拿到了生产数据库权限，它不只是可能生成一段有问题的代码。它还可能真的执行危险操作。社交媒体上出现的生产数据库被清空案例，至少说明这种风险不是理论题。

这对小团队尤其麻烦。小团队最喜欢 vibe coding 的速度红利：少招人、快试错、早上线。但如果没有安全闸门，省下来的开发时间，可能会变成事故后的恢复成本。

更稳的做法是把 agent 权限切小。开发库和生产库分开，危险命令二次确认，部署前做 secret 扫描和数据库备份。要快，也不能把生产环境交给侥幸。

个人软件时代，安全清单要前置

受影响最直接的是两类人。

一类是用 AI 做个人网站、社区工具、数据看板的非专业开发者。他们最容易把“本地能跑”当成“线上可用”。

另一类是准备用 AI 生成代码试水产品的小团队。他们通常没有完整安全团队，但又会更快接触用户数据、支付、账号和生产数据库。

这两类人接下来都该调整动作：个人开发者不要把未经审查的项目直接公开；小团队要把安全检查写进发布流程，而不是出事后补流程。

最低限度可以从几件事做起：

• 数据库账号只给必要权限，不让开发脚本直接碰生产库。
• 用户输入使用参数化查询和校验，别手拼 SQL。
• API key、数据库密码不要放进前端代码或公开仓库。
• 上线前跑一次自动化扫描，再做一次人工代码审查。
• 重要数据要有备份，也要试过恢复。
• agent 执行删除、迁移、部署这类高风险操作时，必须二次确认。

接下来最该看的，不是哪一个 vibe-coded 应用又出了事故。更关键的是 AI 编程工具会不会把这些检查变成默认流程。

比如，生成数据库访问代码时默认使用参数化查询；发现密钥进入前端时直接拦截；agent 准备删除表、清空库、改生产配置时强制确认；应用部署到公网前提醒暴露端口、权限和日志问题。

如果这些仍主要依赖用户自觉，vibe coding 会继续带来更多个人软件，也会继续带来一批本可避免的安全事故。

工欲善其事，先利其器。但今天的问题是，很多人拿到了一把很快的工具，还没学会给刀上护手。