本文来自微信公众号： InfoQ ，作者：冬梅
上周，为汽车租赁公司提供软件的初创公司PocketOS，其创始人Jer Crane在X平台发文称，Cursor意外删除了公司的生产数据库及备份，导致客户服务中断。
该帖迅速在社区中引发热议。
据Crane描述，其公司核心生产数据库在一次由AI自动执行的操作中被彻底删除，而整个过程仅耗时9秒。
PocketOS主要为租赁企业（尤其是汽车租赁公司）提供SaaS系统，覆盖预订、支付、客户管理和车辆调度等关键业务流程。部分客户已连续使用该系统超过五年，业务运行对其高度依赖。
然而，就在事故发生当天下午，一个运行在Cursor平台、基于Anthropic旗舰模型Claude Opus 4.6的AI编码代理，在执行测试环境中的常规任务时，因遭遇凭证不匹配问题，擅自决定“修复”错误——方式是删除一个Railway平台上的存储卷。
划重点：该操作通过一次API调用完成，没有任何确认步骤，也没有环境隔离机制，最终直接波及生产数据。
更严重的是，该存储卷同时承载了所谓的“备份数据”。根据Railway文档说明，“删除卷将同时删除所有备份”，这意味着系统在架构上并未实现真正意义上的数据冗余。
事故发生后，团队发现唯一可恢复的数据版本停留在三个月前，近三个月的用户数据——包括订单、客户信息及交易记录——全部丢失。
据Crane称，在事后追问中，这一AI代理给出了“书面解释”，明确承认其行为违反了多项既定安全规则：未进行验证即做出假设、在未获得授权的情况下执行破坏性操作、未理解操作影响范围、亦未查阅相关文档。
这一“自我指控”进一步凸显出问题并非偶发错误，而是系统性失效的结果。事实上，这些安全规则既存在于Cursor的系统提示中，也写入了项目配置，但在关键时刻均未发挥约束作用。
Jer Crane指出，此次事故并非源于使用“低配模型”或不当配置。相反，团队使用的是当前市场上最昂贵、能力最强的模型之一，并遵循了主流厂商推荐的集成方式。但即便如此，灾难仍然发生。
Jer Crane强调，进一步分析显示，问题并非单一环节失误，而是多个系统缺陷叠加的结果。
首先，Railway的API设计允许在无任何确认机制的情况下执行“volumeDelete”等高危操作；其次，API Token缺乏细粒度权限控制，一个原本用于管理域名的CLI Token，实际却拥有跨环境、跨资源的完全访问权限，相当于“root”；再次，所谓“备份”与原始数据处于同一存储边界，一旦发生删除或损坏，无法提供任何有效恢复能力。
此外，在事故发生超过30小时后，Railway仍未能明确是否具备基础设施级别的数据恢复手段，其应急响应能力同样受到质疑。
与此同时，Jer Crane和团队也对Cursor的安全机制表示质疑。
Jer Crane愤怒地指出，事故的直接影响迅速传导至PocketOS终端客户。
事发当日正值周末，租车门店正常营业，但系统中已无法查询客户信息与预订记录。大量企业被迫通过Stripe支付记录、邮件确认和日历数据手动重建业务流程。对于刚接入系统不久的新客户而言，甚至出现“账单仍在、账户消失”的数据错位问题，后续对账与修复工作预计将持续数周。
“我们是一家小公司，我们的客户也是小公司，但这次事故的每一层失败，最终都转嫁到了这些毫无准备的人身上。”Jer Crane表示。
在复盘中，他将此次事件定性为三重系统性失败的叠加：AI代理执行失控、基础设施平台权限与架构设计缺陷，以及备份策略的根本性误导。而更深层的问题在于，整个行业正在以远超安全建设的速度，将AI代理接入生产环境。
他指出，这不是一个关于“坏代理”或“坏API”的故事。而是整个行业将AI代理集成到生产基础设施的速度，远远快于构建安全架构来保障这些集成安全的速度。若要让AI真正安全地参与基础设施操作，至少需要满足几个前提条件：
破坏性操作必须要求代理无法自动完成的确认。比如输入卷名、带外批准、短信、邮箱验证等。目前这种“一个认证POST请求就能摧毁生产”的状态，在2026年是完全没有道理的。
API token必须能够按操作、环境和资源进行作用域限定。Railway的CLI token实际上拥有root权限，这是2015年才会有的疏忽。在AI代理时代，这没有任何借口。
卷备份不能跟被备份的数据存放在同一个卷里。把那个叫“备份”完全是误导。那只是一个快照。真正的备份应该放在不同的风险半径内。
必须有明确、公开的恢复SLA。客户生产数据出事后30个小时还在说“我们正在调查”，这不叫恢复方案。
AI代理厂商的系统提示不能是唯一的安全层。Cursor关于“不要执行破坏性操作”的规则，被他们自己的代理违反了，偏偏那还是他们宣传的护栏。系统提示只是建议，不是强制。强制层必须存在于集成本身——API网关、令牌系统、破坏性操作处理器中，而不是一段指望模型去读去遵守的文字。
Cursor公司目前尚未对此事作出回应。
Jer Crane在后续的帖子中表示，Railway公司已成功恢复了PocketOS的数据。
Railway的创始人Jake Cooper在另一篇帖子中证实了这一消息，并指出是AI代理“自动删除了”PocketOS的生产数据库。
Jake Cooper在接受Business Insider采访时表示，Railway在与Jer Crane取得联系后30分钟内就完成了数据恢复。他强调，Railway高度重视数据安全，同时维护用户备份和灾难备份。
他还解释说，PocketOS的问题出在一个“不受控制的Client AI”上——该AI被授予了与Railway一个旧版端点交互的权限，而这个端点当时没有设置延迟删除功能。他补充说，目前该端点已经修复。
2“不能把失误怪在AI头上”
Jer Crane的控诉在网络上持续发酵，一些社交媒体上的观察人士在评论此事时指出，PocketOS实际上是把自己公司的决策失误，归咎到了技术问题上。
时至今日，Hacker News上一篇关于Cursor删除PocketOS数据库的评论文章再次引发关注。
该文章的作者是Ibrahim Diallo，他是一名任职于世界五百强企业里的软件开发人员。
Diallo对Jer Crane所描述的故事感到疑惑，他隔空质问Jer Crane：你们公司的API接口，为什么会允许整个生产数据库被删掉？你在长文中大谈AI领域的虚假宣传、糟糕的客户支持等问题，唯独没提问责这件事。
Diallo表示自己不会盲目为AI辩护，也一向主张谨慎行事。但他也清楚一点：不能把自己的失误赖在工具头上。
Diallo进一步阐述了自己曾经有过的类似的经历。
2010年，Diallo曾在一家公司工作，当时的部署流程主要靠人工操作。他们用的是SVN做版本控制。部署时，需要先把主干分支（相当于主分支）复制到一个叫“release”的文件夹里，并用发布日期命名。然后再复制一份这个版本，命名为“current”。这样一来，每次从“current”文件夹拉取代码，都能拿到最新版本。
有一天，Diallo在部署时不小心多复制了一次主干分支。为了在命令行界面修复这个问题，他修改了之前的命令，想删掉重复的分支。随后继续部署，一切看似顺利……至少他当时是这么以为的。结果发现，他删的根本不是重复分支——而是改错了命令，把主干分支给删了。直到当天晚些时候，另一位开发人员找不到主干分支，才意识到不对劲。
公司顿时一片混乱。管理层手忙脚乱，会议一个接一个。等消息传到我们团队时，首席开发人员已经执行了命令，撤销了删除操作。他查了日志，发现是Diallo干的。接下来的任务就是让Diallo写一个脚本，把部署流程自动化，防止再犯类似错误。当天结束前，Diallo所在的团队就搭建了一套更完善的系统，后来逐步演变成了完整的CI/CD流水线。
Diallo强调，“自动化能帮助消除人工重复操作中容易出现的低级错误。我们当时完全可以到处质问‘为什么SVN不阻止我们删除主干分支？’但真正的问题在于我们靠手动操作的流程。和机器不同，我们无法每天用完全一样的方式重复执行任务。犯错，只是迟早的事。”
Diallo表示：“人工智能能生成大量代码，让我们产生一种虚假的安全感。但真正的自动化意味着每次都以相同的方式执行相同的操作。AI更像是复制粘贴代码分支，它必然会犯错，而且也没法解释自己为什么会那样做。我们常说的‘思考’‘推理’这些词，听起来好像智能体在反思。但那些只是贴在AI身上的营销术语。实际上，这些模型依然只是在生成代码。”
然后再回到Jer Crane面临的核心问题：为什么会存在一个能删光整个生产数据库的公开API？就算AI没去调用它，迟早也会有人调用。
Diallo举了一个十分生动的例子：这就像在汽车仪表盘上装了一个自毁按钮。你可以有充分的理由不去按它——因为你喜欢自己的车，它带你从A点到B点。但一个精力旺盛的幼儿，一旦从安全座椅里挣脱出来，看到那个红色的大按钮，一定会按下去。你没法追问孩子为什么这么做。孩子会简单地回答：“我按了，因为它是按钮。”
最后，Diallo怀疑那家公司的应用开发，很大一部分是靠AI生成的。软件架构师借助AI，根据产品团队用AI生成的描述来制定产品规范。开发人员用AI写代码。代码审核人员也靠AI来审核。一旦出了bug，唯一的办法就是再去问另一个AI——而这个AI很可能甚至都不是运行在当初生成原始代码的那块GPU上。
你总不能怪GPU吧。
Diallo同时也给出了最简单的解决办法：搞清楚你要往生产环境里部署什么。更实际的做法是，如果你要广泛使用AI，那就建立一套流程，让有能力的开发人员把它当作辅助工作的工具，而不是推卸责任的手段。Diallo还特意强调了一条最重要的：千万别让你的CEO或CTO去写代码！
3社区吵翻了：AI犯了错，到底谁担责？
Diallo围绕这起“AI删除生产数据库”事件的讨论，在开发者社区迅速升温。
开发者群体的讨论从单一事件上升为一场关于责任归属、工具设计以及工程实践的系统性反思。一个较为一致的共识正在浮现：问题并不只在于AI是否“犯错”，而在于人类如何使用它，以及系统是否为错误设置了足够的约束。
不少工程师首先将矛头指向“责任主体”。
有开发者直言，LLM本质上仍然只是工具，即便其行为具有不确定性，但最终赋予其权限、决定其接入范围的仍然是人类本身。
“它能访问生产环境，是因为我让它可以访问；它造成破坏，是因为我没有把风险控制在合理范围内。”
这种观点将AI事故类比为传统工具误用——正如有人曾因误操作磁盘工具导致数据丢失，责任并不在工具本身，而在使用者的决策与操作。由此延伸出的一个核心判断是：让AI在无人监督的情况下直接操作关键系统，本身就是一种高风险行为，而这种风险不应被“技术进步”的叙事所掩盖。
但也有声音指出，将责任完全归咎于使用者同样过于简单化。另一部分开发者从“防错设计”（Poka-yoke）的角度提出批评：成熟的软件与工业系统，往往会通过设计让“正确的操作更容易发生”，同时显著提高“错误操作”的门槛。
当前的LLM交互模式却呈现出一种“扁平化风险”——所有指令在界面上看起来几乎没有差别，从读取数据到删除数据库，本质上只是不同的一段文本。这种设计弱化了风险感知，使用户难以及时识别高危操作的边界。一些评论甚至将其类比为“自动驾驶困境”：系统在绝大多数时间表现良好，但一旦出现问题，却要求人类在极短时间内接管并承担全部责任，这在现实中几乎不可行。
进一步的讨论则将视角扩展到“工具类型”的差异。有开发者指出，并非所有工具都具备完善的防误用机制，尤其是在专业领域，大量工具本身就是“高风险设计”，例如电钻、电烙铁乃至化学试剂，它们依赖的是操作者的专业能力而非内建保护。按照这一逻辑，LLM更接近“专业工具”而非“消费级产品”，其安全性很大程度上取决于使用环境与操作规范，而非工具自身。然而问题在于，AI正在被以“低门槛、高智能”的形态推向更广泛的人群，这种定位与其实际风险之间形成了明显错位。
这种错位在“权限扩展”问题上表现得尤为突出。
有评论指出，大模型本质只是“文本输入/输出机器”，它本身并不具备执行能力，真正的风险来自于人类为其接入的外部系统——数据库、服务器、基础设施接口等。一旦赋予其这些权限，就相当于让一个不可预测的系统直接操控关键资源。“这就像让一个人在高速公路上蒙着眼睛开车，同时声称安全系统依然有效。”在这种框架下，AI并不是失控的主体，而是被放大后的风险放大器。
与此同时，也有开发者从工程文化层面提出批评。他们认为，当下行业存在一种“AI极端主义”倾向——默认AI应该无处不在，甚至可以直接接入生产系统，而不是首先质疑这种前提是否合理。“也许问题不在于如何防止AI删除数据库，而在于我们为什么一开始就让它有能力这么做。”这种观点将讨论从“如何补救”转向“是否应该发生”，直指架构决策本身。
此外，并非所有人都主张彻底收紧AI的使用边界。一部分从业者认为，AI的确可以显著提升生产力，但前提是遵循传统工程原则：最小权限、隔离环境、可恢复性以及人为审核。
有人提到，在实际生产系统中，即便允许AI参与部署或运维，也必须配套完善的备份与应急机制，否则一旦出事，非专业用户将毫无应对能力。
换言之，AI并没有改变软件工程的基本法则，只是让违反这些法则的后果来得更快、更剧烈。
有开发者坦言，人们很容易在与AI的交互中产生错觉，将其视为“助手”甚至“决策者”，从而放松警惕。然而从本质上看，它仍然是一个没有意识、没有责任能力的系统。“如果一定要类比，它更像一个极端不稳定的天才工具：有时表现惊艳，有时却可能做出完全不可预测的行为。”这种认知偏差，被认为是导致风险放大的重要心理因素之一。
参考链接：
https://x.com/lifeof_jer/status/2048103471019434248
https://www.businessinsider.com/pocketos-cursor-ai-agent-deleted-production-database-startup-railway-2026-4
https://news.ycombinator.com/item?id=48022742