这并非是单独的例子, 而是在2026年正处于批量发生状况的事情。软件领域存在着一个残酷的常理, 能够运行, 并不等同于可以使用；能够上线, 并不等同于能够承担责任。人工智能在批量制造应用程序, 同时也在批量埋下隐患。

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

Vibe Coding 最令人欲罢不能之处, 在于其把软件开发转变为一种即时反馈游戏，你提出需求, AI 便生成代码, 你称按钮不好看, 它就改样式, 你讲部署报错, 它就给你一段命令, 以往开发过程中的那些数量颇多的挫败感, 被一幕幕自然语言对话给消除了。

这种体验会营造出一种极为强烈的错觉, 也就是只要页面能够被打开, 产品便算是制作完成了。然而实际上真正的软件可不是单纯的页面, 页面仅仅属于在最轻易的就能被看到的那一部分而已。一款产品能否安全稳定地运行, 是由诸多肉眼看不见的部分所决定的, 像是认证、权限隔离、密钥管理、日志脱敏以及攻击防护等方面。这些部分呀, 既没有截图看起来那么美观, 同时也不会在演示版本当中自动呈现出来。

由以色列安全公司RedAccess展开的一项调查, 揭露了这种错觉所带来的代价, 将其呈现于众人面前: 他们在调查里发现大量公开可访问的资产, 数量约达38万个, 其中约5000个资产含有敏感企业信息, 这些信息涵盖了医疗记录、财务数据、内部文件以及客服对话等等。Axios的报道中也提及了这些资产, 指出它们涉及由Lovable、Base44、Replit、Netlify这类AI/低代码平台生成或者托管的应用。RedAccess的首席执行官讲得颇为直白, 这些应用的隐私设定, “默认的是可供公开去访问”。

这就是说, 去打造一个能够投入使用的App, 其门槛经由AI的冲击已然降低到几乎等同于零的程度。然而, “清楚自身处于毫无保护状态”这样的情况, 其门槛丝毫没有下降。有一批看上去似乎像是产品, 实际上却更近似于半成品实验的 App, 被径直推向了现实世界——它们并非无法运行, 而是运行得太过提前了。

Vibe-Coded

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

这场狂欢之中, 最容易被忽视的一句话是, AI编程工具所解决的是“怎样生成代码”的问题, 而非“谁来承担后果”的问题。

Lovable给自身招惹来的那一揽子漏洞, 相较于任何的说理而言, 都更能够说得明白这一要点。依据安全社区所透露的内容, 在今年4月份的时候, 研究员weezerOSINT在注册了一个Lovable免费账户以后, 只因经过了数量不多的API调用, 便极有能够去访问其他用户的源代码, 以及数据库凭证和AI聊天记录。这并不需要采用任何具备攻击性的手段, 并且这一问题所指向的是接口方面缺乏权限校验, 它属于一种典型的 BOLA（对象级授权缺失）漏洞, 据说会对在 2025 年 11 月之前创建的项目产生影响, 而且规模不算小。有研究员表示, 自己在 48 天之前就已经通过 HackerOne 将这个问题报告上去了。

首先, Lovable 一开始着重表明平台并没有碰到传统概念里的数据被泄露这种情况, 还把一部分问题诠释成是用户对于公开项目以及权限设置存在理解上的偏差。接着呢, 事件又引出了平台后端权限调整、漏洞报告流转等方面的问题。然后, 公司承认在今年 2 月统一后端权限设置的时候, “意外地重新开启”了对公开项目聊天记录的访问权限。最后, 研究员也提及, HackerOne 曾经将这份报告标记为“重复提交”。

一个原本存在的安全漏洞, 经历了一番周折, 最终演变成了这样一种状况, 即平台、用户以及漏洞响应流程之间, 形成了一种彼此互相牵扯、互相推诿的责任链条。而在这整个过程当中, 偏偏没有任何人提及, 这个产品从设计伊始, 压根就没将“用户的代码以及数据必须要得到保护”这一点, 当作首要的考量优先级。

这并非是道德方面的问题, 而是属于能力结构范畴的问题。有这样一名独立开发者的情形, 他能够同时身兼产品经理、设计师、前端、后端以及运维这些角色, 然而, 他大概率仅仅也就了解前两个角色而已, 对后面的那几个角色差不多是没什么概念的——人工智能能够帮他生成一段登录逻辑, 可却不会主动去告知他这段逻辑是不是契合真实安全场景；能够帮他接入数据库, 又不会替他去设计最小权限原则咧。更为微妙的情况是, 人工智能所生成的代码会营造出一种心理距离咧: “它能够运行, 所以按理来说应该没毛病；它乃是模型生成的, 所以大概比我懂得多咧”。AI 并未使得人无需承担责任, 只是致使众多人在更晚的时候才察觉到自身得负起责任。

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

以往, 独立开发者最为惧怕的情形是无人使用。然而在AI编程时代, 另外一种失败将会变得更为危险: 存在他人真正进行了使用。缘由在于只要存在他人使用, 便会生成数据；只要有了数据，就会产生责任；只要责任无人予以处理, 就会演变为风险。

有一个被The Verge报道的朴素事例: 那是名为Bob Starr的开发者借助AI拼凑而成的网站, 在上线数月后才发觉存在一个SQL注入漏洞。文章所做出的判断精准无误——于业余项目跟处理真实财务、医疗数据的软件之间, 存在着一条界限, 然而编写代码的人, 常常并不清楚自己在何时已然跨越了这条界限。

不少 AI 生成产品存在的问题, 并非在于它们太过失败, 而是在于它们处于那种半成功的状态。要是没有人去访问, 那它仅仅只是一个被废弃掉的项目；要是突然间有了人来访问, 那它就有可能转变成为一个无人进行看管的数据容器。这类产品会越发增多, 缘由是AI将试错成本压低至极低程度——一个人能够在一个月内制作十几个小型工具, 多数无法真正发展壮大, 然而都会短暂上线, 短暂收集数据, 短暂接入第三方服务, 随后被遗落在某个云平台、某个数据库实例当中——依赖未作更新, 密钥未进行轮换, 权限无人检查, 接口却依旧能够访问。

传统互联网所遗留下来的是那种僵尸网站, AI编程所留存下的有可能是僵尸 App。其中存在区别之处在于, 僵尸网站顶多仅仅是无人去看, 而僵尸 App 说不定还掌控着一批真实用户的数据, Moltbook 所败露出来的那批 API 令牌以及代理私密消息, 从本质上来说就是一个被狂欢式增长甩在后面、没人有时间去妥善完成收尾工作的数据容器。

Moltbook

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

"并非专业开发者去做软件"这种情况并非新鲜之事, 有低代码, 有无代码, 还有Excel宏, 它们都曾承诺过类似的事物, 可确实也制造了隐患, 在众多企业里面, 存在着一批"没人敢去动"的系统。原作者已经离职多年, 文档不存在, 权限处于混乱状态, 然而却依旧支撑着某个关键流程。

AI编程仅仅是将此事从企业内网推至公网, 以往业务人员弄坏内部表单的时候, 所影响的是一个部门, 而如今不懂安全配置的人搭建一个AI工具, 使其开放注册并挂上域名后, 所影响的则是所有上传过数据的陌生人。

更麻烦之处在于, 这种债务并非轻易就能被察觉, 一个常见的糟糕系统往往一眼便可看出其粗糙, 而由 AI 生成的产品则有所不同, 其界面美观、交互流畅, 还会运用现代化 UI 来包装自身。然而, 美观的前端无法掩饰脆弱的后端, RedAccess 报告中那些致使医疗记录与银行数据泄露的应用, 从外表看来与任何一个正常上线的产品毫无差异。

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

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

凭“人人都是开发者”带来的那般舒畅感觉来开展增长营销的人工智能编程平台, 它所说很有吸引力、可作为卖点的是“门槛已然不存在了”。可一旦出现问题, 通常的第一反应常常是着重表明“这并非传统概念范畴的数据泄露情况”, 是“用户于权限设置方面存在理解上的偏差”——这种情形差不多是将一个分明丝毫不具备工程背景的人, 认定为理应自行弄明白权限模型的责任主体。这就是该平台一边收获着“零门槛”所带来的增长红利, 一边却把“零门槛”原本应当承担的安全方面的代价, 丢给最没能力承受它其的人。有亲和力的那种回应途径便是已然存在的示例样子: 先是着重说明并非是进行了泄露, 接着将问题归结于用户在领会方面产生了偏差, 最终才引出平台自身在2月份的权限作出调整这个“意外”情况就是把默认值从私密状态改回到了公开状态——而平台自身所应承担的责任, 是在经历了一番周折之后才被提及的那一项内容。

倘若有个平台, 其卖点为“无需懂得技术”, 那它便没资格去要求用户自行领会权限风险。默认是私有而非公开, 默认扫描那些硬编码密钥, 默认在上线之前阻拦一下用户, 这些并非是起到锦上添花作用的功能, 而是平台收取“门槛”这笔费用时原本就应当绑定的责任。现今多数平台尚处于增长优先的阶段, 更倾向于展示“十分钟就能做出一个漂亮应用”, 而非在用户点击“发布”之前, 老老实实地告知他: 你的数据库此刻是公开的。

这里要特别指出的是, 安全以及隐私仅仅是这算盘算所得清单中的一部分而已。围绕着人工智能所生成代码的版权归属层面的问题, 还有开源协议所规定的各项义务, 另外还有第三方人工智能处理用户数据时需达成的合规要求等, 如今也都正再次被放置到明面上来加以讨论了。诸如 Doe 诉 GitHub 这一案件, 依旧在美国的法院体系之中处于一种相互拉扯的状态, 其中存在的争议之一便是, Copilot 所生成的代码, 究竟有没有将开源代码里的版权管理信息给移除掉；苹果方面呢也于 App Store 的审核规则里做出要求, 就是在开发者向第三方 AI 去分享用户个人数据之前, 务必要明确地告知并且获得同意才行。也就是说, Vibe Coding 所具有的风险可不是仅仅局限于“有没有漏洞”这一方面, 还涵盖了“代码是从哪里来的、数据又去到了哪里、出了事情之后到底该由谁来负责”这些方面。

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

这并非表明AI编程不值得怀揣期待, 它切实开启了一个庞大的空间, 往昔诸多小需求因开发成本太过高昂, 向来不会得到满足, 现今一个人能够迅速验证想法, 为小众人群提供服务。

不过正是由于门槛有所降低, 故而新的分化会更快速地展现出来。在将来那时候, 大家都会运用AI去编写代码, ——是否能够生成页面、是否能够接入API, 其本身会愈发不再属于稀缺能力。而真正稀缺的在于: 究竟是谁能够把一个Demo转化成为可持续运行的产品。介于这两者之间所存在的差别并非是灵感方面的, 而是涉及到工程责任的, ——能不能领会用户数据的敏感性, 能不能设计出权限边界, 能不能在产品废弃时做到删除数据、关闭接口以及通知用户。

以往, 身为个体去打造产品时, 最为棘手的难题在于无法将其制作完成；当下, 成功做出产品反倒仅仅是开端而已。你越是能够轻松顺利地实现上线, 便越是容易较早地踏入责任范畴。处于AI编程这一时代背景下, 克制会再度转变成为一种能力——并非是谁撰写提示词更为炫酷就是更为出色的开发者, 而是要清晰知晓哪些数据不可随意收纳, 哪些功能不能毫无防护地运行, 哪些产品在没有制定维护规划的状况下不能交付给真实的用户。

软件并未因AI而变得简易, 只是复杂性被延缓了, 它藏于权限之中，藏于数据库之中, 藏于某个已被遗忘却依旧开放的接口之中。下一阶段, 真正具价值的开发者、平台以及社区, 或许不再仅教人怎样借助AI快速打造产品, 而是教人怎样将产品安全地置于真实世界。因为软件一旦上线, 便不再只是自身的作品, 它开始承载他人的信任, 而信任绝不是十分钟就能生成的。

（本文作者为 wiwi，钛媒体经授权发布）