量子位 | 公众号 QbitAI
Cursor 啊 Cursor，你怎么又出事了……
就在即将被马斯克收购的节骨眼上，又出了大问题，直接干到 48 小时内 X 帖子浏览量 450 万、HN 评论 900 条的程度。
永远不要 xx 的瞎猜！而我恰恰就瞎猜了。我猜测删除 staging volume 只会影响 staging。我没有验证。我没有检查 volume ID 是否跨环境共享。我违反了每一条系统规则。
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，让它解释为什么这么做。
元股证券:ygzq.hk结果得到了一段惊人的"认罪书"：
它知道系统规则写了" 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 倍。
（马斯克看了直呼内行 .jpg）美股配资资讯门户
参考链接： [ 1 ] https://x.com/lifeof_jer/status/2048103471019434248 [ 2 ] https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-powered-ai-coding-agent-deletes-entire-company-database-in-9-seconds-backups-zapped-after-cursor-tool-powered-by-anthropics-claude-goes-rogue [ 3 ] https://news.ycombinator.com/item?id=47911524 [ 4 ] https://www.theregister.com/2026/04/27/cursoropus_agent_snuffs_out_pocketos/优配网提示：本文来自互联网，不代表本网站观点。
