租了个AI程序员，9秒把公司数据库当bug修掉了，还写下认罪书
编辑｜杨文
美剧《硅谷》中，有个经典搞笑片段。
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 发送私信后得到回复，目前已经恢复了数据。