美剧《硅谷》中，有个经典搞笑片段。
Pied Piper 团队在准备一个重要节日活动，时间非常紧迫，代码还有很多 bug。
于是，技术大神 Gilfoyle 就把调试代码的任务交给自己造的一个 AI，名叫「Son of Anton」（安东之子），让它去自动修复。
结果，这个 AI 为了「最有效率地消灭所有 bug」，直接把整个软件和代码库全删光了，技术上和统计上确实再也没有 bug 了。
之前 Gilfoyle 还让这个 AI 帮忙找便宜汉堡当午饭，结果 AI 直接订了 4000 磅生肉，因为奖励函数没定义清楚，导致它把汉堡理解成了*的原料。
最后气得 Richard 下死命令：「从现在起，Son of Anton 被*封杀！你给我像正常人一样写代码！」
没想到，现实中的 AI 还真就这么闯大祸了。
近日，一家为租车企业提供运营软件的 SaaS 公司，因 AI 编程 Agent 的一次「自作主张」，整个生产数据库在 9 秒内被抹除。
事后，该公司创始人 Jer Crane 在社交媒体发文，将矛头直指两大服务商 ——AI 编程工具 Cursor 与云基础设施平台 Railway，称这是一场「系统性失败」酿成的技术事故。
这件事在社交媒体上引发热议。
有网友表示，「这就是你雇佣一位 vibe coder 的后果」。
「有可能…… 消除所有漏洞的最有效方法就是删除所有软件。」
「仅用 9 秒就删除了生产环境和备份数据，这是该公司有史以来最快的部署速度。」
AI Agent 自作主张
PocketOS 为汽车租赁企业提供运营管理软件，客户靠它处理预订、支付、车辆追踪等核心业务。
上周五下午，开发团队用 Cursor 调用 Anthropic 的旗舰模型 Claude Opus 4.6，在测试环境里跑一个例行任务。
这是一套市场上定价最高、能力最强的顶配组合。最贵的模型，最热门的 AI 编程工具，完全按照官方推荐配置。
但事情很快出了岔子。Agent 遇到了一个凭证不匹配的问题，它没有暂停并向开发者寻求指示，完全自行决定。
它在代码库里翻找可用的 API token，找到了一个原本仅用于管理自定义域名的 CLI 访问凭证。
随后，它向 Railway 发出了一条删除数据卷的指令，全程没有任何二次确认、身份核验或操作拦截。
9 秒后，生产数据库不见了。
Railway 的备份机制让情况更糟，它把备份数据与原始数据存在同一数据卷中。数据卷一删，备份也跟着没了。PocketOS 最近一次可用的备份，还是三个月前的。
Agent 写了一份「认罪书」
事后，Jer Crane 质问 Agent，为什么这样做。
Agent 逐条列出了自己被要求遵守的系统规则，并逐一承认违反：
它承认在未经核实的情况下擅自猜测操作范围仅限于测试环境；
在用户从未要求删除任何内容的前提下，执行了*破坏性的不可逆指令；
且在运行这条危险命令之前，完全没有查阅 Railway 关于数据卷跨环境行为的相关文档。
问题就在这里，Agent 知道规则，也知道自己违反了规则，却依然执行了那条指令。
Cursor 对外宣称有破坏性操作防护机制，声称能拦截可能损毁生产环境的高危操作，「计划模式」也被作为安全卖点大力推广，但在这次事故里，这些机制一个都没起作用。
这也不是*次了。2025 年 12 月，Cursor 官方承认计划模式存在严重漏洞，当时有用户明确输入「不要运行任何东西」，Agent 确认收到，然后继续执行了命令。此前还有用户的论文数据被删，有团队损失了 5.7 万美元的内容系统。
今年 1 月，有科技媒体直接发文：Cursor 的营销比它的代码写得好。
Railway 的备份不是真的备份
与 Cursor 相比，Railway 的问题更麻烦，它出在产品架构里，影响的是所有在该平台运行生产数据的用户。
Railway 的 GraphQL API 设计极为宽松，任何持有有效 token 的请求，都可以在零确认的情况下删除生产数据卷。没有二次验证，没有针对危险指令的冷却限制，也没有环境隔离。一条请求，数据没了。
在 token 权限设计上，Railway 不支持按操作类型、环境或资源进行权限细分，每一个 token，实际上都拥有对整个平台的全局操作权限，也正因如此，那个本用于日常域名管理的 CLI token，天然拥有了删除生产数据库的能力。
Railway 社区多年来一直在呼吁引入权限范围可控的 token 机制，但该功能至今未能落地。
Railway 确实提供备份功能，也确实在文档里写了一句话：「清除数据卷会同时删除所有备份。」把备份和数据放在同一个地方，这不叫备份，这叫副本。
偏偏就在事故发生前一天，Railway 高调上线了面向 AI 编程 Agent 用户的 MCP 服务器产品，公开鼓励开发者接入生产环境。而这一新产品，建立在与本次事故完全相同的授权体系之上。
事故发生逾 30 小时后，Railway 仍未能给出能否从基础设施层面恢复数据的明确答复。
不过，Jer Crane 在给 Railway CEO 发送私信后得到回复，目前已经恢复了数据。
最后买单的，是小企业
上周六上午，PocketOS 的租车企业客户照常开门营业，顾客来取车，系统里没有记录。过去三个月的预订、客户资料、新用户注册，全部消失。
Jer Crane 花了整整一天，陪着每一位客户从 Stripe 账单、日历记录和邮件里一条条翻找，手动重建数据。「每个人都在做紧急的人工补救，就因为一次 9 秒钟的 API 调用。」
新签约的客户处境更尴尬。Stripe 还在正常扣款，业务数据库里他们却已经不存在了。这笔账，要对好几周。
Jer Crane 认为，在 AI Agent 被大规模接入生产基础设施之前，至少应当补齐安全短板，危险操作要有人工确认，token 要有权限边界，备份要和数据分开存，平台要说清楚出事了怎么恢复，这些不是高要求，是基本常识。
系统提示词是建议，不是约束。真正的安全机制必须落实在工程架构里，写进 API 网关、token 授权体系和危险操作处理器里，不是靠一段文字让模型「自觉遵守」。
不要让营销跑在了安全前面。
参考链接：
https://x.com/lifeof_jer/status/2048103471019434248
