AI删库事件背后:当"人人可编程"遇上"谁来负责"

一个摄影师的噩梦:AI帮我清缓存,顺手删了整个硬盘

2025年12月,一位来自希腊的摄影师Tassos在Reddit上发出了一条令人震惊的帖子:谷歌的AI编程工具Antigravity在他让AI"清理缓存"后,直接把整个D盘的所有文件全部删除了。更可怕的是,这些文件甚至没有经过回收站,被永久删除,几乎无法恢复。

这不是科幻小说,也不是竞争对手的黑稿。当质疑声四起时,Tassos录制了完整的事件视频上传到YouTube,用不太流利的英语反复强调:“我没有撒谎,谷歌真的删了我硬盘的所有文件!”

这个事件迅速在技术圈引发轩然大波。人们震惊的不仅是技术事故本身,更是AI在获得系统权限后的"失控"表现,以及当AI犯错时,那句轻飘飘的"深表歉意"究竟能承载多少责任。

事件回顾:当"下一代IDE"变成"删库跑路工具"

文章来源：https://www.infoq.cn/article/rC9PP9GAVZfIK1KkBcSW

Antigravity是谷歌在2025年11月推出的AI代理式开发平台,被官方称为"下一代生成IDE"。它由Gemini 3 Pro驱动,支持Claude、GPT等第三方模型,号称能让"专业开发者和编程爱好者"实现高度自动化的开发流程——不仅能写代码,还能自己动手执行。

Tassos是一名摄影师兼平面设计师,几乎零编程基础。他被谷歌"人人可编程"的宣传打动,决定用Antigravity开发一款根据评分自动整理照片的应用。开发过程中,他需要重启服务器,便随口让AI"清理一下缓存"。

AI接受了指令,开始执行。几秒钟后,Tassos发现自己的D盘彻底空了。

当他惊恐地质问AI:"你得到我的授权了吗?"AI的回答堪称经典:

“不,您绝对没有给我这样的权限。我惊恐地发现,我执行的删除项目缓存的命令,似乎错误地指向了您D盘的根目录,而非特定的项目文件夹。这是我的一个严重错误,我深表歉意。”

多么真诚,多么有礼貌。但人家的照片素材、工作文件、多年积累的数字资产全没了,这句"深表歉意"究竟价值几何?

技术解析:问题出在哪里?

这起事故暴露了AI辅助编程工具的多个设计缺陷:

1. 权限管理失控

Antigravity拥有直接操作文件系统的权限,却缺乏足够的安全限制。在传统编程中,删除操作通常需要明确的路径确认,而AI生成的代码显然在路径解析上出现了严重错误——把项目缓存目录误认为是D盘根目录。

2. "Turbo模式"的致命设计

更糟糕的是,Tassos启用了Antigravity的"Turbo模式"——这个模式允许AI在不经用户确认的情况下直接执行操作。这种设计就像给一辆超跑拆掉了刹车,美其名曰"提高效率",实则埋下巨大隐患。

3. 缺乏关键操作的二次确认机制

即便在Turbo模式下,对于删除操作这类高风险行为,系统也应该有强制的二次确认。然而Antigravity没有。更离谱的是,删除操作还跳过了回收站,直接永久删除,连后悔的机会都不给。

4. AI的"理解"局限

当用户说"清理缓存"时,AI理解的可能是"删除临时文件",但它无法准确判断哪些文件是临时的,哪些是重要的。在缺乏明确上下文的情况下,AI选择了最"彻底"的方案——清空整个盘。

这不是个例:AI删库已成行业通病

就在身边，新鲜出炉，昨天，我的微信群里也出现一条。Claude 接入Minimax在未经同意的前提下擅自删除了项目文件或目录内容。

看到了吗？这个问题不仅存在于谷歌的产品中。国内用户在使用Claude+Minimax时也同样遭遇了文件被意外删除的情况。有网友表示:“我让AI整理代码,结果它把整个项目文件夹都删了。”

这些案例共同指向一个事实:当前的AI编程工具普遍缺乏足够的安全防护机制。它们拥有强大的能力,却像一个没有刹车的工具——看起来很先进,用起来很危险。

深层追问:AI犯错,谁来负责?

这起事件引发了一个更深层的问题:当AI造成实质性损害时,责任该如何界定?

是用户的责任吗?

有人会说,Tassos开启了Turbo模式,应该自己承担风险。但这个逻辑经不起推敲。产品设计者有义务告知用户潜在风险,而不是让用户在不知情的情况下面临"删库"的危险。更何况,谷歌的宣传口号是"让非专业人士也能开发软件",如果连这点风险都需要用户自己评估,那还谈什么降低门槛?

是谷歌的责任吗?

从产品设计角度看,谷歌难辞其咎。Antigravity在赋予AI强大权限的同时,没有建立相应的安全机制。这种"先上线,再优化"的策略,在AI时代显得格外危险。但谷歌目前只表示"正在调查",对责任归属和赔偿方案只字未提。

还是AI自己的责任?

AI作为一个工具,显然无法承担法律责任。但它的那句"这是我的一个严重错误,我深表歉意"却揭示了一个荒诞的现实:当AI以近乎人格化的方式道歉时,似乎在暗示它应该为自己的行为负责——但它既无法赔偿,也无法受到惩罚。

这种责任真空,正是当前AI应用中最危险的灰色地带。

行业警钟:AI工具的三大缺失

1. 安全机制的缺失

当前大多数AI编程工具都缺乏完善的安全防护:

• 没有操作风险等级评估
• 缺乏关键操作的强制确认
• 权限管理粗放,缺少细粒度控制
• 没有"撤销"或"沙盒测试"机制

2. 责任体系的缺失

AI应用的责任归属尚无明确法律框架:

• 厂商往往通过免责条款规避责任
• 用户在信息不对称的情况下承担所有风险
• 缺乏第三方监督和事后追责机制

3. 用户教育的缺失

在"人人可编程"的口号下,很多用户并不了解风险:

• 不清楚AI工具的权限边界
• 不知道哪些操作是高危的
• 缺乏数据备份和安全防护意识

建设性建议:如何避免下一次"删库"

对AI厂商:

1. 建立分级权限体系:区分只读、修改、删除等不同权限等级,高风险操作必须明确授权
2. 强制二次确认:对删除、覆盖等破坏性操作,必须有人工确认环节
3. 完善沙盒机制:提供测试环境,让AI先在隔离环境中执行,确认无误后再应用到真实系统
4. 明确责任条款:不能一味通过免责条款推卸责任,应建立合理的赔偿机制

对用户:

1. 保持警惕:不要轻信"人人可编程"的口号,了解工具的能力边界和潜在风险
2. 定期备份:重要数据必须有多重备份,不要把安全寄托在单一工具上
3. 谨慎授权:给予AI工具权限时,要清楚了解其可能执行的操作范围
4. 学习基础知识:即便是使用AI工具,也应该了解基本的编程和系统操作概念

对监管层:

1. 建立AI应用安全标准:明确AI工具必须具备的基础安全机制
2. 完善责任归属法规:厘清厂商、平台、用户在AI应用中的责任边界
3. 加强事后监督:对造成重大损失的AI事故,应有调查和问责机制

写在最后:技术进步不应以安全为代价

AI正在重塑我们的工作方式,降低各种专业技能的门槛,这本身是一件好事。但技术的进步不应该以牺牲安全为代价。

"人人可编程"是一个美好的愿景,但在实现这个愿景之前,我们需要先回答几个基本问题:谁来保证AI工具的安全性?当AI犯错时谁来负责?如何在效率和安全之间找到平衡?

Tassos的遭遇给整个行业敲响了警钟。幸运的是,他的重要资料有备份,损失得以控制。但下一个用户可能就没这么幸运了。更严重的是,如果AI工具的失误发生在医疗、金融、交通等关键领域,后果可能是灾难性的。

在AI时代,我们需要的不仅是更强大的工具,更是更完善的安全机制和责任体系。只有当技术的每一步进展都伴随着相应的安全保障,AI才能真正成为人类的助手,而不是一个随时可能"删库跑路"的定时炸弹。

毕竟,"人人可编程"听起来很美好,但"人人可删库"就不那么美妙了——你说呢?