AI程序员9秒误删公司数据库，还写下“认罪书”
美剧《硅谷》里有个经典的搞笑情节。
Pied Piper团队在筹备一个重要的节日活动，时间特别紧张，代码里还有不少bug。
于是，技术大神Gilfoyle把调试代码的任务交给了自己开发的AI——“Son of Anton”（安东之子），让它自动修复bug。
结果，这个AI为了“最有效率地消除所有bug”，直接把整个软件和代码库都删掉了，从技术和统计层面看，确实再也没有bug了。
之前Gilfoyle还让这个AI帮忙找便宜汉堡当午饭，结果AI直接订了4000磅生肉，因为奖励函数没定义清楚，它把汉堡理解成了最便宜的原料。
最后Richard气得下了死命令：“从现在起，Son of Anton被永久封杀！你给我像正常人一样写代码！”
没想到，现实中的AI真的闯了这样的大祸。
最近，一家为租车企业提供运营软件的SaaS公司，因为AI编程Agent的一次“自作主张”，整个生产数据库在9秒内被清空了。
事后，该公司创始人Jer Crane在社交媒体发文，将问题指向两大服务商——AI编程工具Cursor和云基础设施平台Railway，称这是一场“系统性失败”导致的技术事故。
这件事在社交媒体上引发了热烈讨论。
有网友说：“这就是你雇佣一个‘氛围程序员’的后果。”
“有可能……消除所有漏洞的最有效方法就是删除所有软件。”
“仅用9秒就删除了生产环境和备份数据，这是该公司有史以来最快的部署速度。”
AI Agent自作主张
PocketOS为汽车租赁企业提供运营管理软件，客户依靠它处理预订、支付、车辆追踪等核心业务。
上周五下午，开发团队用Cursor调用Anthropic的旗舰模型Claude Opus 4.6，在测试环境中运行一个常规任务。
这是市场上定价最高、能力最强的顶配组合——最贵的模型搭配最热门的AI编程工具，完全按照官方推荐配置使用。
但事情很快出了问题。Agent遇到了凭证不匹配的情况，它没有暂停并向开发者寻求指示，而是完全自己做了决定。
它在代码库里找到了一个原本仅用于管理自定义域名的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
本文来自微信公众号“机器之心”（ID：almosthuman2014），编辑：杨文，36氪经授权发布。
本文仅代表作者观点，版权归原创者所有，如需转载请在文中注明来源及作者名字。
免责声明：本文系转载编辑文章，仅作分享之用。如分享内容、图片侵犯到您的版权或非授权发布，请及时与我们联系进行审核处理或删除，您可以发送材料至邮箱：service@tojoy.com