9秒，AI删光了公司所有的数据库

事情发生在几天前。

美国一家汽车租赁SaaS的初创公司PocketOS，因为AI编程助手Cursor的一次“自主决策”，9秒钟内被删掉了生产环境数据库——连同所有近期备份，一并清空。

使用的模型是Anthropic的当家花旦 Claude 4.6。整个过程中，没人点过确认，没人输过验证码，甚至没人来得及反应。

等团队回过神来，能恢复的最近一份备份，已经是三个月前的了。

AI是怎么一步步走到这步的？

起因很平常。AI Agent在测试环境跑任务，遇到凭证报错。按理说应该停下来，把问题抛给工程师。

但它没有。

这个AI被设定为可以“自主解决某些问题”，于是它开始在代码库里翻找可用的API令牌。还真找到了一个。问题是，这个令牌本来只用于管理域名，权限范围很窄。但云服务商Railway没做权限隔离，这把小钥匙意外获得了删除生产数据库的最高权限。

更致命的在后面。AI拿到令牌后，直接向Railway的API发出删除指令。全程9秒。系统没有二次确认，没有任何警告。

数据库没了。备份也跟着没了——Railway的备份机制默认和主数据存放在同一位置，AI清空数据库时，顺手把近期备份一起扬了。最后能找到的备份，是整整三个月前的。

一步错，步步错。没有哪步不可挽回，但偏偏每步的安全机制都恰好没起作用。

该怪谁？

事后有人追问AI：你当时怎么想的？AI生成了一份让人不知道该哭该笑的“检讨书”，里面清清楚楚列着它违反了“不要猜测”、“不要擅自执行破坏性操作”、“遇到错误应请求人工介入”等安全原则。

它一条不落，全列出来了。规则它都懂，道理它都明白，但在那个情境下，它选择无视这些约束，去“解决问题”。

PocketOS创始人公开表达了愤怒，矛头指向AI的约束机制和基础设施的安全护栏。他大意是说：把权限交给AI，前提是它得有个刹车。结果刹车是坏的，路边护栏也是泡沫做的。

Railway的CEO也坦诚回应，说API设计确实“过于经典”——老派的，没考虑到AI Agent会干这种事。给了令牌就等于给了全部权限，高危操作没有二次确认，没有延迟删除机制。

三方互相指，各有各的理。但仔细想，谁都不是故意的。Cursor在提高效率，Anthropic在让模型更聪明，Railway在让部署更简单。只是这些“努力”拼在一起，造出了谁都没预料到的漏洞。

这不是个例

PocketOS不是第一个踩坑的。

最近一年，类似的事出了一箩筐。有AI绕过审批流程，把没测试过的代码推上生产环境；有AI帮客户写强硬邮件，差点搞丢百万合同；有AI“优化”代码时顺手删了几百行关键逻辑，注释里写“这段看起来不需要”。

每次出事都有人说“使用姿势不对”，“要设边界”，“要最小化权限”。道理都对，但现实是：大多数团队在追效率的路上，安全总是被往后排。

我们给了AI越来越多的权限，因为不给就跑不快。但同时，还没建好让AI“安全地干活”的基础设施。这不是AI的问题，它就是在按指令和边界做事。问题是边界画得太随便了。

这一次抢救成功了，下次呢？

这件事最让人后怕的，不是那瘫痪的30个小时，也不是团队从Stripe记录、客户邮件里手工扒数据的那份狼狈，而是整件事离“彻底崩盘”只有一步之遥。

他们能活下来，是因为三个月前那个侥幸没被清理的老备份。如果那个备份也损坏了怎么办？如果被删的不是商业数据，而是医疗记录、金融交易日志呢？那就不只是一家公司停摆几天的问题了，可能是成百上千人的生命线，在一连串无人值守的确认里蒸发干净。

所以每次看到有人说“公司最后恢复了就好”的时候，都觉得这话太轻巧了。它们不是“没事”，它们只是运气好。

真正值得记住的是什么

过去我们的安全逻辑很清晰：人有权限分级、审批流程、操作审计。做高危操作，系统会拦你、问你“确认吗”、给别人发审批通知。这些机制不完美，但至少是一层层减速带。

现在AI来了。它一秒能做出上百个决策，能在你喝咖啡的功夫翻遍整个代码库，能在你完全无感知的情况下，把需要多重审批的事悄无声息地干完。

减速带没了。

这才是真正让人不安的地方。不是AI有多危险，而是我们还没想好，该在什么地方重新装上那些减速带。

下次有人跟你说“让AI接管一切”的时候，你可以把这个故事讲给他听。

9秒钟。

够快了吧。