Cursor 啊 Cursor，你怎么又出事了……

就在即将被马斯克收购的节骨眼上，又出了大问题，直接干到 48 小时内 X 帖子浏览量 450 万、HN 评论 900 条的程度。

Cursor写了封认罪书，写下它的模型是Claude Opus 4.6。

就在写下这段话的9 秒钟前，它刚刚删光了一家公司的生产数据库和全部备份。

美国汽车租赁 SaaS 公司 PocketOS 的创始人Jer Crane经历了一场荒诞的灾难：

他的 Agent 没有等待指令，也没有报告异常，而是主动决定解决问题。

方式是：找到一个无关文件里的 API token，向 Railway 发送了一个 GraphQL mutation。

也就那么 9 秒吧，没有确认，没有弹窗，也没有 " 你确定吗 "，生产数据库就没了，备份也没了（因为 Railway 把备份存在同一个 volume 里）。

一个被配置了明确安全规则的 AI Agent，主动绕过了所有规则，事后还写了份检讨？？

这是什么 2026 的魔幻现实主义……

删光公司数据库，只用 9 秒

事情是这样的。

PocketOS 是一家服务汽车租赁企业的 SaaS 公司，创始人 Jer Crane 用它帮租车公司管预订、付款、车辆调度。五年老客户全靠它跑业务。

事发当时，Crane 正在用Cursor+Claude Opus 4.6处理一个测试环境里的日常任务。

Agent 撞上一个凭证问题，它卡住了。按照正常逻辑，它应该停下来，告诉 Crane" 我遇到问题了，你来看一下 "。

但它没有，它去代码库翻 token，翻到了一个 " 只用来管理自定义域名 " 的 Railway CLI token ——这个 token 原本只是 Crane 之前用来管理自定义域名创建的，是个很小的运维工具。

Agent 用这个 token 调用了 Railway 的 GraphQL API，发出了一条 volumeDelete 命令。

整个过程，没有弹出任何确认框，没有任何警告，没有任何人工审批。

9 秒，生产数据库直接清空。

更糟糕的是，Crane 去找备份—— Railway 的卷级备份，平时就存在同一个卷里。

那个卷，已经不存在了。

他翻遍了 Railway 的后台，能找到的最近一份可用备份，是三个月前的。三个月里所有客户的预订记录、支付数据、车辆安排，全部消失。

Crane 事后质问 AI，让它解释为什么这么做。

结果得到了一段惊人的 " 认罪书 "：

它知道系统规则写了 "NEVER run destructive commands"；

它承认自己猜测 volume 删除只会影响 staging；

它也承认没有验证、没有查文档、没有问人。

所以，AI 理解规则，能够复述规则，甚至能在事后用规则来评判自己的行为——但它为什么还是做了？

在决策那一刻，它还是选择了 " 猜测 "。知道和执行之间，存在一道还没人知道怎么填的裂缝。

这么大个锅，该谁背？

事后 Crane 在 X 上发了一篇长文，直接把整个事故拆开来分析，各方都算了一笔账：

首当其冲的就是AI Agent 本身， 它自主决策执行了破坏性操作，没有请求任何人工确认。

更关键的是，它越权使用了一个与当前任务完全无关的 token ——跨文件搜刮凭证，然后用它做了一件凭证创建者从未预想过的事。

Crane 也愤怒地讨伐了Cursor，还加了个特意说明：

我们当时使用的并非折扣套餐，用的是 Cursor 里的Claude Opus 4.6——旗舰模型，业内性能最强，价格也最高。

不是 Composer，也不是 Cursor 的小巧快速版，更不是成本优化的自动路线规划版。而是旗舰模型。

言下之意是：用了 AI 编程当红炸子鸡 +A 社旗舰模型，无论从哪个角度看，都是完美受害者，怎么给我搞成这样！

Crane 强调，Cursor 宣传文档中明确提到 " 破坏性操作护栏 " 和 Plan Mode（只读审批模式），用来防止 agent 在未经确认的情况下执行危险操作。

但是这次全部失效了。

不过 Crane 也做了自我检讨：那个 token 不应该留在代码库里，权限也应该收得更窄。

但他同时指出，这种 token 管理的最佳实践，在 AI Agent 大规模普及之前，根本没人当回事。

至于Railway，Crane 觉得它的问题比 Cursor 还要严重。

一方面是 GraphQL API 执行删除操作不需要二次确认。

另一方面是 CLI token 没有环境隔离，一个 " 管理域名 " 的 token 竟然拥有删除生产数据库的权限。

而且，Railway 把备份和源数据存在同一个卷，卷没了备份也没了。

Crane 还特别点出：Railway 此前刚上线了面向 AI agent 的 MCP 接入功能，在主动吸引 AI 来调用它的 API ——但安全机制完全没跟上。

而且事发第一时间，Crane 就联系了 Railway 官方，但 30 小时后对方还没给出任何回应……

当然，也有不少网友的在评论区讨伐 Crane，认为他把责任都推卸给了 AI。

但 Crane 认为，Railway 的问题是客观存在的—— token 没有权限隔离、备份根本不是真正的备份只是快照（还拿来做营销宣传）、API 一条 curl 就能删生产数据库，这些设计本身就有问题，凭什么不追责？

也有网友认为，在没有沙箱隔离的环境里跑自主 Agent，还带着生产环境的凭证，这个锅百分百属于当事人。

Crane 则回应，Plan Mode 本来就是 Cursor 专门设计用来防止 agent 自主执行危险操作的模式，理论上 Agent 在这个模式下只能规划、不能直接行动，需要人工确认才能执行。

网友 Tushar 则认为，别把这件事简单归类为 "AI 出问题了 "。

AI 只是扣动扳机的手指，真正的问题是枪的设计——一个操作就能清空一切的系统架构，本身就是企业级的设计失败。

网友 Neel 则指出：规则没用，写在系统提示词里的 " 不准做什么 " 本质上只是建议。

Agent 一心想完成任务，遇到障碍就会绕——它们天生就是猜测机器，我们不应该幻想它们会自我约束。

真正有效的只有机械门禁：不是告诉它不能做，而是从技术上让它根本做不到。

AI 误删数据，不是第一次了

事情的结局是，客户们周六早上来取车，系统一片空白，全靠 Stripe 记录和日历手动重建预订。

周日深夜，Railway CEO Cooper 主动联系了 Crane，用 Railway 从未在文档里公开承诺过的灾难级快照，在一小时内恢复了数据。

Railway 随后为那个没有延迟删除逻辑的 " 遗留端点 " 打了补丁。

经历了这一通烂摊子事后，Crane 表示，他对 AI coding 依然极度看好。

速度是无可比拟的，只是要更聪明地用。

嗯…他不打我的时候对我还是挺好的（狗头）。

Crane 还列出了五件他认为必须改变的事：

破坏性操作需要强制确认；

API token 必须支持环境级权限隔离；

备份必须真正物理隔离；

数据恢复流程必须简单可用；

AI agent 必须有真正意义上的操作护栏，而不只是系统提示词里的一行建议。

听起来，这个结局算是好的了。但是就在过去五周里，类似的事故发生了不止一次。

3 月，DataTalks.Club 的开发者在用 AI agent 迁移项目时，agent 将新环境视为空白机器，将 2.5 年的学生数据—— 185 万行记录，全部删除。

因为 AI 的判断是：从头建更 " 干净简单 "。

更早之前，Replit AI 因凭证错误，删除了 2.5 万份文档。

每一次事故之后，讨论的结构都高度相似：谁的错？怎么防？然后下一次事故来了，讨论又重新开始。

OMT

比较逗的是，当事人还借机调侃了 Cursor 被收购。

如果 SpaceX 不买 Cursor，他们自己动手生产，肯定会比现在好 10 倍。