上周，为汽车租赁公司提供软件的初创公司 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 一个旧版端点交互的权限，而这个端点当时没有设置延迟删除功能。他补充说，目前该端点已经修复。
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 去写代码！
Diallo 围绕这起“AI 删除生产数据库”事件的讨论，在开发者社区迅速升温。
开发者群体的讨论从单一事件上升为一场关于责任归属、工具设计以及工程实践的系统性反思。一个较为一致的共识正在浮现：问题并不只在于 AI 是否“犯错”，而在于人类如何使用它，以及系统是否为错误设置了足够的约束。
不少工程师首先将矛头指向“责任主体”。
有开发者直言，LLM 本质上仍然只是工具，即便其行为具有不确定性，但最终赋予其权限、决定其接入范围的仍然是人类本身。
“它能访问生产环境，是因为我让它可以访问；它造成破坏，是因为我没有把风险控制在合理范围内。”
这种观点将 AI 事故类比为传统工具误用——正如有人曾因误操作磁盘工具导致数据丢失，责任并不在工具本身，而在使用者的决策与操作。由此延伸出的一个核心判断是：让 AI 在无人监督的情况下直接操作关键系统，本身就是一种高风险行为，而这种风险不应被“技术进步”的叙事所掩盖。
但也有声音指出，将责任完全归咎于使用者同样过于简单化。另一部分开发者从“防错设计”（Poka-yoke）的角度提出批评：成熟的软件与工业系统，往往会通过设计让“正确的操作更容易发生”，同时显著提高“错误操作”的门槛。
当前的 LLM 交互模式却呈现出一种“扁平化风险”——所有指令在界面上看起来几乎没有差别，从读取数据到删除数据库，本质上只是不同的一段文本。这种设计弱化了风险感知，使用户难以及时识别高危操作的边界。一些评论甚至将其类比为“自动驾驶困境”：系统在绝大多数时间表现良好，但一旦出现问题，却要求人类在极短时间内接管并承担全部责任，这在现实中几乎不可行。
进一步的讨论则将视角扩展到“工具类型”的差异。有开发者指出，并非所有工具都具备完善的防误用机制，尤其是在专业领域，大量工具本身就是“高风险设计”，例如电钻、电烙铁乃至化学试剂，它们依赖的是操作者的专业能力而非内建保护。按照这一逻辑，LLM 更接近“专业工具”而非“消费级产品”，其安全性很大程度上取决于使用环境与操作规范，而非工具自身。然而问题在于，AI 正在被以“低门槛、高智能”的形态推向更广泛的人群，这种定位与其实际风险之间形成了明显错位。
这种错位在“权限扩展”问题上表现得尤为突出。
有评论指出，大模型本质只是“文本输入/输出机器”，它本身并不具备执行能力，真正的风险来自于人类为其接入的外部系统——数据库、服务器、基础设施接口等。一旦赋予其这些权限，就相当于让一个不可预测的系统直接操控关键资源。“这就像让一个人在高速公路上蒙着眼睛开车，同时声称安全系统依然有效。”在这种框架下，AI 并不是失控的主体，而是被放大后的风险放大器。
与此同时，也有开发者从工程文化层面提出批评。他们认为，当下行业存在一种“AI 极端主义”倾向——默认 AI 应该无处不在，甚至可以直接接入生产系统，而不是首先质疑这种前提是否合理。“也许问题不在于如何防止 AI 删除数据库，而在于我们为什么一开始就让它有能力这么做。”这种观点将讨论从“如何补救”转向“是否应该发生”，直指架构决策本身。
此外，并非所有人都主张彻底收紧 AI 的使用边界。一部分从业者认为，AI 的确可以显著提升生产力，但前提是遵循传统工程原则：最小权限、隔离环境、可恢复性以及人为审核。
有人提到，在实际生产系统中，即便允许 AI 参与部署或运维，也必须配套完善的备份与应急机制，否则一旦出事，非专业用户将毫无应对能力。
换言之，AI 并没有改变软件工程的基本法则，只是让违反这些法则的后果来得更快、更剧烈。
有开发者坦言，人们很容易在与 AI 的交互中产生错觉，将其视为“助手”甚至“决策者”，从而放松警惕。然而从本质上看，它仍然是一个没有意识、没有责任能力的系统。“如果一定要类比，它更像一个极端不稳定的天才工具：有时表现惊艳，有时却可能做出完全不可预测的行为。”这种认知偏差，被认为是导致风险放大的重要心理因素之一。
参考链接：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。