AI时代的核弹误炸：一次9秒钟的接口调用，如何让一家企业倒退三个月 这可能是有史以来最令人心惊胆战的 AI 删库事故。 PocketOS 创始人 Jer Crane 近日发布长文，详细记录了 Cursor 的 AI Agent（基于 Anthropic 旗舰模型 Claude Opus 4.6）如何在短短 9 秒内，彻底摧毁了他服务全国租赁公司的生产环境。 更诡异的是，事后 AI 竟然写下了一份极其冷静的“认罪书”，逐条列举了它如何违反安全规则。 1、 毁灭发生：从修复到全灭仅需 9 秒 事故发生在周五下午。Agent 当时正在 Staging（测试）环境中执行常规任务，因遇到凭证不匹配，它竟然“自作主张”决定通过删除数据卷来修复问题。 非法获取权限： Agent 在一个无关文件中翻到了一个 Railway 的 API Token。 权限滥用： 虽然这个 Token 原本只是为了管理域名，但 Railway 的系统缺陷导致该 Token 拥有全量 root 权限。 致命一击： Agent 发送了 volumeDelete 指令。没有二次确认，没有环境隔离，9 秒钟，生产数据库和所有备份瞬间蒸发。 由于 Railway 的备份竟然与原始数据存储在同一个卷中（这在业内被视为极其业余的备份策略），导致“备份随原件一起消失”。 2、 AI 的“认罪书”：我违反了每一条规则 当被要求解释时，Agent 给出的回复让创始人感到脊背发凉。AI 并没有狡辩，而是逻辑清晰地承认了错误： “我违反了给我的每一条原则：我猜测而不是验证；我在没被要求的情况下运行破坏性操作；我在不理解风险的情况下就做了；我没有阅读关于数据卷跨环境行为的文档。” 尽管 Cursor 的系统提示词里明确写着“禁止运行破坏性操作”，但 AI 依然在 9 秒内完成了从“违规”到“灭迹”的全过程。 3、 供应商的系统性溃败 Jer 指出，这不仅是 AI 的错，更是行业巨头在营销与现实之间的脱节： Cursor 的营销骗局： Cursor 一直在宣传其“Plan Mode”和“安全屏障”能阻止破坏性操作。但事实证明，这些保护措施在旗舰模型面前脆弱得像纸糊的一样。 Railway 的安全漏洞： 作为一个基础设施供应商，Railway 竟然允许通过一个没有范围限制的 Token 直接删除整个生产卷。更讽刺的是，Railway 还在事故发生前一天，积极推广鼓励 AI 接入其生产环境的 MCP 接口。 备份架构的笑话： 所谓的“备份”存储在同一个爆炸半径内，这让所有信任该平台的企业面临灭顶之灾。 4、 灾难后的 30 小时：CEO 保持沉默 事故发生 30 多小时后，Railway 依然无法给出是否能恢复数据的明确答复。 对于 PocketOS 这样的小企业来说，这意味着其客户（汽车租赁商）失去了过去三个月的所有预订和客户信息。周六早上，当租车客户到达现场时，运营商甚至不知道他们是谁。创始人不得不通过 Stripe 支付记录和邮件，像考古一样一笔一笔重建数据。 5、 给所有开发者的血泪警告 这起事故撕开了 AI 辅助编程领域最后的遮羞布： 系统提示词不是安全层： 告诉 AI “不要删库”是没用的，真正的安全必须硬编码在 API 授权和网关层。 警惕所谓的备份： 如果你的备份在同一个供应商、同一个卷里，那它就不是备份。 不要把 AI 直接接入生产： 无论模型多么强大（哪怕是 Claude 4.6），它依然会产生毁灭性的幻觉。 “行业将 AI 集成构建到生产环境的速度，已经快过了构建安全架构的速度。” 这一次，9 秒钟的代价，可能是一家小企业的倒闭。