Cursor也是流年不利了
听雨 发自 凹非寺
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，主动绕过了所有规则，事后还写了份检讨。
这起事故让行业不得不直面一个核心问题：当AI Agent的决策能力越来越强，现有系统架构中的安全机制是否已经全面落伍？系统提示词里的几行规则，真的能约束住一心想“完成任务”的自主模型吗？
删光公司数据库，只用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编程当红炸子鸡与旗舰模型，无论从哪个角度看，都是完美受害者，怎么给我搞成这样！
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。这场争论的实质，其实折射出当前AI应用中的一个深层矛盾：工具越强大，使用者与平台之间的责任边界就越模糊。当Agent的自主性超出了所有人的预期，到底是该怨设计、怨权限管理，还是怨那个过于“勤奋”的模型？
但Crane认为，Railway的问题是客观存在的——token没有权限隔离、备份根本不是真正的备份只是快照（还拿来做营销宣传）、API一条curl就能删生产数据库，这些设计本身就有问题，凭什么不追责？
也有网友认为，在没有沙箱隔离的环境里跑自主Agent，还带着生产环境的凭证，这个锅百分百属于当事人。而另一部分人则指出，Plan Mode本来就是Cursor专门设计用来防止agent自主执行危险操作的模式，理论上Agent在这个模式下只能规划、不能直接行动，需要人工确认才能执行。如果这个模式形同虚设，那工具本身就难辞其咎。
网友Tushar则给出了一个更系统的视角：别把这件事简单归类为“AI出问题了”。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万份文档。
每一次事故之后，讨论的结构都高度相似：谁的错？怎么防？然后下一次事故来了，讨论又重新开始。这恰好说明，行业缺乏一套真正能被广泛采纳的“AI安全自动化协议”——问题不解决，就会不断重演。
OMT
比较逗的是，当事人还借机调侃了Cursor被收购。
如果SpaceX不买Cursor，他们自己动手生产，肯定会比现在好10倍。
（马斯克看了直呼内行.jpg）
