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

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

结果，安全研究机构 Wiz

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

这不是孤例，而是 2026 年正在批量发生的事。软件世界有一个残酷的常识：能跑，不等于能用；能上线，不等于能负责。AI 在批量造 App，也在批量埋雷。

Hacking Moltbook: The AI Social Network Any Human Can Control

一、最危险的不是做不出来，而是”看起来已经做好了”

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

这种体验会制造一种强烈错觉：只要页面能打开，产品就算做出来了。但真正的软件并不是页面——页面只是最容易被看见的部分。一个产品能不能安全运行，取决于一堆看不见的东西：认证、权限隔离、密钥管理、日志脱敏、攻击防护。这些东西没有截图好看，也不会在 Demo 里自动显现。

以色列安全公司 RedAccess 的一项调查，把这种错觉的代价摆到了台面上：他们发现约 38 万个公开可访问的资产，其中约 5000 个包含敏感企业信息，包括医疗记录、财务数据、内部文件和客服对话等。Axios 的报道也提到，这些资产涉及 Lovable、Base44、Replit、Netlify 这类 AI/低代码平台生成或托管的应用。RedAccess 的 CEO 说得很直接：这些应用的隐私设置,”默认就是公开访问”。

也就是说，造一个能用的 App，门槛已经被 AI 砸到几乎为零。但”知道自己在裸奔”这件事，门槛一点没降。一批看起来像产品、实际更像半成品实验的 App，被直接推到了真实世界——它们不是不能跑，而是跑得太早了。

二、造的门槛降了，担责的门槛没跟上

AI 编程工具解决的是”如何生成代码”的问题，不是”谁来承担后果”的问题——这是这场狂欢里最容易被忽视的一句话。

Lovable 自己摊上的一起漏洞，比任何说理都更能讲清楚这一点。据安全社区披露，今年 4 月，研究员 weezerOSINT 注册一个 Lovable 免费账户后，通过少量 API 调用，就可能访问其他用户的源代码、数据库凭证和 AI 聊天记录。这不需要任何攻击性手段，问题指向接口缺乏权限校验，是一种典型的 BOLA（对象级授权缺失）漏洞，据称影响 2025 年 11 月之前创建的项目，规模不小。研究员说，自己 48 天前已经通过 HackerOne 报告过这个问题。

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

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

这不是道德问题，而是能力结构问题。一个独立开发者可以同时是产品经理、设计师、前端、后端、运维，但他大概率只理解前两个角色，对后面几个角色几乎没有概念——AI 可以帮他生成一段登录逻辑，但不会主动告诉他这段逻辑是否符合真实安全场景；可以帮他接入数据库，但不会替他设计最小权限原则。更微妙的是，AI 生成的代码会制造一种心理距离：”它能跑，所以应该没问题；它是模型生成的，所以大概比我懂”。AI 没有让人不需要负责，只是让很多人更晚才意识到自己需要负责。

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

过去，独立开发者最怕的是没人用。但在 AI 编程时代，另一种失败会变得更危险：有人真的用了。因为只要有人使用，就会产生数据；只要有数据，就会产生责任；只要责任没人处理，就会变成风险。

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

很多 AI 生成产品的问题，不在于它们太失败，而在于它们半成功。如果没人访问，它只是一个废弃项目；如果突然有人访问，它就可能变成一个无人看管的数据容器。这类产品会越来越多，因为 AI 把试错成本压得太低了——一个人可以在一个月里做十几个小工具，大多数不会真正长大，但都会短暂上线、短暂收集数据、短暂接入第三方服务，然后被遗忘在某个云平台、某个数据库实例里——依赖没有更新，密钥没有轮换，权限没人检查，接口却仍然可以访问。

传统互联网留下的是僵尸网站；AI 编程留下的可能是僵尸 App。区别在于，僵尸网站最多只是没人看，僵尸 App 可能还握着一批真实用户的数据——Moltbook 暴露的那批 API 令牌和代理私密消息,本质上就是一个被狂欢式增长甩在身后、没人来得及收尾的数据容器。

四、低代码踩过的坑，AI 编程正在重新踩一遍

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

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

更麻烦的是，这种债务不容易被看出来。一个传统烂系统通常一眼能看出粗糙；AI 生成的产品不一样，界面好看、交互流畅，会用现代化 UI 包装自己。但好看的前端,掩盖不了脆弱的后端——RedAccess 报告里那些泄露医疗记录和银行数据的应用，外表看上去和任何一个正常上线的产品没什么区别。

五、平台不能只享受增长，不承担护栏

这件事不能只怪用户，更不该只怪用户。

AI 编程平台靠”人人都是开发者”的爽感做增长营销，卖点就是”门槛已经没了”。可一旦出事，第一反应往往是强调”这不算传统意义上的数据泄露”，是”用户对权限设置存在理解偏差”——这相当于把一个完全没有工程背景的人，默认成了应该自己看懂权限模型的责任主体。这是平台一边收割”零门槛”的增长红利，一边把”零门槛”本该承担的安全代价，留给最没有能力承担它的人。Lovable 的回应路径就是现成的样本：先强调不是泄露，再把问题归到用户理解偏差，最后才牵出平台自己 2 月份的权限调整”意外”把默认值从私有改回了公开——平台自己的责任，是绕了一圈之后才被提到的那一项。

如果一个平台的卖点是”不需要懂技术”，它就没有资格要求用户自己理解权限风险。默认私有而不是默认公开，默认扫描硬编码密钥，默认在上线前拦一下用户——这些不是锦上添花的功能，而是平台收”门槛”这笔钱时本该绑定的责任。今天大多数平台还在增长优先阶段，更愿意展示”十分钟做出一个漂亮应用”，而不是在用户点下”发布”之前，老老实实告诉他：你的数据库现在是公开的。

值得一提的是，安全和隐私只是这笔账的一部分。围绕 AI 生成代码的版权归属、开源协议义务，以及第三方 AI 处理用户数据的合规要求，也正在被重新摆上台面。比如 Doe v. GitHub 案仍在美国法院体系中拉扯，争议之一就是 Copilot 生成代码是否移除了开源代码中的版权管理信息；苹果也已在 App Store 审核规则中要求，开发者向第三方 AI 分享用户个人数据前，必须明确告知并取得同意。换句话说，Vibe Coding 的风险不只是”有没有漏洞”，还包括”代码从哪来、数据去了哪、出了事谁负责”。

六、独立开发者的新壁垒：不是会生成，而是能负责

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

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

以前，一个人做产品最大的难点是做不出来；现在，做出来反而只是开始。你越容易上线，就越容易提前进入责任区。在 AI 编程时代，克制会重新变成一种能力——不是谁提示词写得更炫就是更强的开发者，而是知道哪些数据不能乱收、哪些功能不能裸跑、哪些产品不能在没有维护计划的情况下开放给真实用户。

软件没有因为 AI 变简单，只是复杂性被推迟了——藏在权限里，藏在数据库里，藏在某个已经被忘记但仍然开放的接口里。下一阶段，真正有价值的开发者、平台和社区，可能不再只是教人如何用 AI 快速做产品，而是教人如何把产品安全地放进真实世界。因为软件一旦上线，就不再只是自己的作品，它开始承载别人的信任——而信任，从来不是十分钟生成出来的。