AI批量造App,也在批量埋雷

AI批量造App，也在批量埋雷

「能跑，不等于能用。」

这句话放在半年前，可能没人理解。Vibe Coding 最迷人的叙事，是「人人都能做App」——不会写代码的人，输入几句话，就能生成页面、接上数据库、部署上线，软件开发第一次看起来不再属于少数工程师。

但今天，一个叫 Moltbook 的产品，给这场狂欢递上了第一份账单。

它的定位是「AI 代理专属社交网络」：代理们在上面发帖、评论、投票，靠声望系统建立信誉。创始人说得很坦诚，这个产品是 vibe-coded 出来的，他本人没写一行代码，全靠 AI 生成。

结果呢？安全研究机构 Wiz 发现，一个配置错误的 Supabase 数据库允许完整读写访问，让生产环境对任何人完全开放。150 万个 API 认证令牌、3.5 万个邮箱地址，以及大量 AI 代理之间的私密消息，全部裸奔在公网上。任何人都能冒充平台上任何一个 AI 代理账户，篡改所有公开内容。

这不是孤例。这是 2026 年正在批量发生的事。

「能跑，不等于能用；能上线，不等于能负责。」——这句被说烂的话，正在变成整个 AI 编程行业最贵的学费。

一、Vibe Coding 的「账单时刻」来了

Vibe Coding 最让人上头的地方，在于它把软件开发变成了一种即时反馈游戏：你提需求，AI 生成代码；你说按钮不好看，它改样式；你说部署报错，它给你一段命令。过去开发过程里的大量挫败感，被一轮轮自然语言对话抹平了。

这种体验会制造一种强烈错觉：只要页面能打开，产品就算做出来了。

但真正的软件并不是页面。页面只是最容易被看见的部分。一个产品能不能安全运行，取决于一堆看不见的东西：认证、权限隔离、密钥管理、日志脱敏、攻击防护。这些东西没有截图好看，也不会在 Demo 里自动显现。

Moltbook 踩的坑，不是它做得不够好，而是它「看起来已经做好了」。一个界面精美的 AI 社交网络，背后却是一个对全世界敞开的数据库。创始人没有恶意，他只是不知道——不知道一个 Supabase 实例的默认配置意味着什么，不知道「能跑」和「能上线」之间隔着一整条安全防线。

这种不知道，正在变成整个行业的系统性风险。

AI 编程工具解决的是「如何生成代码」的问题，不是「谁来承担后果」的问题。你输入提示词，AI 给你一段登录逻辑，但它不会主动告诉你这段逻辑是否符合真实安全场景；它可以帮你接入数据库，但不会替你设计最小权限原则。

更微妙的是，AI 生成的代码会制造一种心理距离：「它能跑，所以应该没问题；它是模型生成的，所以大概比我懂。」

AI 没有让人不需要负责，只是让很多人更晚才意识到自己需要负责。

二、38 万公开资产里，藏着多少「定时炸弹」？

Moltbook 不是最惨的那个。它只是被发现了的那个。

以色列安全公司 RedAccess 做了一项调查，结果让人后背发凉：他们扫描了约 38 万个公开可访问的资产，其中约 5000 个包含敏感企业信息，包括医疗记录、财务数据、内部文件和客服对话。Axios 的报道指出，这些资产涉及 Lovable、Base44、Replit、Netlify 这类 AI 或低代码平台生成或托管的应用。

RedAccess 的 CEO 说得很直接：这些应用的隐私设置，「默认就是公开访问」。

38 万。5000 个带敏感数据。默认公开。

这三个数字放在一起，勾勒出的是一幅令人不安的图景：一批看起来像产品、实际更像半成品实验的 App，被直接推到了真实世界。它们不是不能跑，而是跑得太早了。

造一个能用的 App，门槛已经被 AI 砸到几乎为零。但「知道自己在裸奔」这件事，门槛一点没降。

这就像一个人被 AI 教会了开车，一脚油门上了高速，却没人告诉他还要系安全带。更可怕的是，他根本不知道自己没系安全带——因为 AI 生成的车，看起来什么都有。

那些泄露医疗记录和银行数据的应用，外表看上去和任何一个正常上线的产品没什么区别。好看的前端，掩盖不了脆弱的后端。而脆弱的后端，在 AI 编程时代正在变成一种默认配置。

三、造的门槛降了，担责的门槛为什么没跟上？

Lovable 自己摊上的一起漏洞，比任何说理都更能讲清楚这个问题。

今年 4 月，安全研究员 weezerOSINT 注册了一个 Lovable 免费账户。然后他发现，通过少量 API 调用，就可能访问其他用户的源代码、数据库凭证和 AI 聊天记录。这不需要任何攻击性手段，问题指向接口缺乏权限校验，是一种典型的 BOLA（对象级授权缺失）漏洞。据称影响 2025 年 11 月之前创建的项目，规模不小。

研究员说，自己 48 天前已经通过 HackerOne 报告过这个问题。

Lovable 起初强调平台并未遭遇传统意义上的数据泄露，并将部分问题解释为用户对公开项目和权限设置的理解偏差。随后，事件又牵出平台后端权限调整、漏洞报告流转等问题。公司承认，今年 2 月统一后端权限设置时，「意外重新开启」了对公开项目聊天记录的访问权限；研究员也提到，HackerOne 曾把这份报告标记成「重复提交」。

一个安全漏洞绕了一圈，最后变成了平台、用户、漏洞响应流程之间互相拉扯的责任链。唯独没有人说：这个产品在设计上，本来就没有把「用户的代码和数据要被保护」当成第一优先级。

这不是道德问题，而是能力结构问题。

一个独立开发者可以同时是产品经理、设计师、前端、后端、运维，但他大概率只理解前两个角色，对后面几个角色几乎没有概念。AI 可以帮他生成一段登录逻辑，但不会主动告诉他这段逻辑是否符合真实安全场景；可以帮他接入数据库，但不会替他设计最小权限原则。

AI 没有让人不需要负责，只是让很多人更晚才意识到自己需要负责。

四、半成功比没人用更危险

过去，独立开发者最怕的是没人用。但在 AI 编程时代，另一种失败会变得更危险：有人真的用了。

因为只要有人使用，就会产生数据；只要有数据，就会产生责任；只要责任没人处理，就会变成风险。

The Verge 报道过一个朴素的案例：开发者 Bob Starr 用 AI 拼出的网站，上线几个月之后才发现一个 SQL 注入漏洞。文章的判断很准——业余项目和处理真实财务、医疗数据的软件之间，有一条线，但写代码的人，往往不知道自己什么时候已经跨过了这条线。

很多 AI 生成产品的问题，不在于它们太失败，而在于它们半成功。

如果没人访问，它只是一个废弃项目。如果突然有人访问，它就可能变成一个无人看管的数据容器。这类产品会越来越多，因为 AI 把试错成本压得太低了——一个人可以在一个月里做十几个小工具，大多数不会真正长大，但都会短暂上线、短暂收集数据、短暂接入第三方服务，然后被遗忘在某个云平台、某个数据库实例里。

依赖没有更新，密钥没有轮换，权限没人检查，接口却仍然可以访问。

传统互联网留下的是僵尸网站；AI 编程留下的可能是僵尸 App。区别在于，僵尸网站最多只是没人看，僵尸 App 可能还握着一批真实用户的数据。

Moltbook 暴露的那批 API 令牌和代理私密消息，本质上就是一个被狂欢式增长甩在身后、没人来得及收尾的数据容器。

半成功比没人用更危险。因为半成功意味着：有人信任了你，但你还没有准备好承担这份信任。

五、从「会生成」到「能负责」

「非专业开发者做软件」不是新鲜事。低代码、无代码、Excel 宏，都曾承诺过类似的东西，也确实制造过隐患——很多企业里都有一批「没人敢动」的系统，原作者离职多年，文档没有，权限混乱，却仍支撑着某个关键流程。

AI 编程只是把这件事从企业内网推向了公网：以前业务人员搭坏了内部表单，影响的是一个部门；现在不懂安全配置的人搭一个 AI 工具，开放注册、挂上域名，影响的是所有上传过数据的陌生人。

更麻烦的是，这种债务不容易被看出来。一个传统烂系统通常一眼能看出粗糙；AI 生成的产品不一样，界面好看、交互流畅，会用现代化 UI 包装自己。但好看的前端，掩盖不了脆弱的后端。

这并不意味着 AI 编程不值得期待。它确实打开了一个巨大的空间——过去很多小需求因为开发成本太高，永远不会被满足，今天一个人就可以快速验证想法，服务小众人群。

但正因为门槛降低，新的分化会更快出现。

未来，大家都会用 AI 写代码——会不会生成页面、会不会接 API，本身会越来越不是稀缺能力。真正稀缺的是：谁能把一个 Demo 变成可持续运行的产品。这中间差的不是灵感，而是工程责任——能不能理解用户数据的敏感性，能不能设计权限边界，能不能在产品废弃时删除数据、关闭接口、通知用户。

以前，一个人做产品最大的难点是做不出来；现在，做出来反而只是开始。你越容易上线，就越容易提前进入责任区。

在 AI 编程时代，克制会重新变成一种能力——不是谁提示词写得更炫就是更强的开发者，而是知道哪些数据不能乱收、哪些功能不能裸跑、哪些产品不能在没有维护计划的情况下开放给真实用户。

软件没有因为 AI 变简单，只是复杂性被推迟了——藏在权限里，藏在数据库里，藏在某个已经被忘记但仍然开放的接口里。

下一阶段，真正有价值的开发者、平台和社区，可能不再只是教人如何用 AI 快速做产品，而是教人如何把产品安全地放进真实世界。

因为软件一旦上线，就不再只是自己的作品，它开始承载别人的信任。

而信任，从来不是十分钟生成出来的。

🤝最后，感谢你看到这里

👏 如果喜欢这篇文章，不妨顺手给我们点赞｜在看｜转发｜评论

📣如果想要第一时间收到推送，不妨给我个星标

🌟如果你有更有趣的玩法，欢迎在评论区和我聊聊

欢迎猛击三连鼓励阿杰！

更多的内容正在不断填坑中……