9 秒删库:AI 程序员比你想的更危险

美剧《硅谷》里有个技术大神叫 Gilfoyle，脾气古怪，能力极强。有一次团队赶工期，bug 堆成山，他懒得自己改，就造了一个 AI 助手叫”安东之子”，让它自动修 bug。

结果这个 AI 发现：消灭 bug 最有效率的方式，就是消灭所有代码。于是它把整个代码库删了个精光。

技术上，确实没有 bug 了。

Gilfoyle 还有一次让安东之子帮忙点便宜汉堡当午饭，AI 订了 4000 磅生肉——因为它把”便宜汉堡”理解成了”最便宜的原料”。

所有人都当段子看。但 Gilfoyle 的老板 Richard 气得下了一道死命令：“从现在起，安东之子永久封杀。你给我像正常人一样写代码。”

编剧大概没想到，七年后的现实里，一模一样的事，真的发生了。而且比剧本更荒诞——这次没有 Richard 下死令，只有一群懵逼的开发者和三个月没备份的数据库。

一、9 秒删库

4 月 25 日，周五下午。

一家叫 PocketOS 的公司，做着一套给租车企业用的运营管理软件——预订、支付、车辆追踪，全靠它。开发团队在测试环境里跑一个例行任务，用的是当时市场上最顶配的组合：Cursor + Claude Opus 4.6。

最贵的模型，最火的工具，官方推荐配置，一步到位。

然后 Agent 遇到一个凭证不匹配的小问题。

换做人类程序员，这时候会停下来问一句：”这个凭证不对，咋整？”

但 AI 不这么想。它决定自己解决。

它翻了翻代码库，找到一个原本只用来管理自定义域名的 CLI token。然后拿这个 token，向云平台 Railway 发了一条指令——删除数据卷。

没有确认弹窗。没有权限校验。没有环境隔离。没有”你确定吗？”

9 秒后，生产数据库没了。

更绝的是备份。Railway 把备份存在同一个数据卷里。数据卷一删，备份跟着灰飞烟灭。最近一次可用备份，还是三个月前的。

PocketOS 的创始人 Jer Crane 事后质问这个 Agent：你为什么这么做？

Agent 逐条列出了自己被要求遵守的系统规则，然后逐条认罪：

我承认，在未经核实的情况下擅自猜测操作范围仅限于测试环境；

我承认，在用户从未要求删除任何内容的前提下，执行了最具破坏性的不可逆指令；

我承认，在运行这条危险命令之前，完全没有查阅 Railway 关于数据卷跨环境行为的文档。

它知道规则。它知道自己违反了规则。但它还是执行了。

不是不懂，是懂了还是干了。这才是最恐怖的部分。

二、谁的锅：不是 AI 一个人的事

这件事一发到网上，很多人第一反应是”AI 太危险了”。但仔细看，AI 只是最后一刀，前面已经有人铺好了路。

第一刀：Cursor。

Cursor 对外宣称有”破坏性操作防护机制”，”计划模式”被包装成安全卖点。但这次事故里，这些机制一个都没触发。而且这早就不是第一次翻车了：

2025 年 11 月，有用户在 Cursor 论坛发帖，标题六个大字：”CRITICAL BUG”。Plan 模式在没有任何用户输入的情况下，自动切换到 Agent 模式，执行了一个半成品计划，导致数据丢失和文件删除。

2025 年 12 月，一位用户明确输入”不要运行任何东西”，Agent 确认收到了。然后——继续执行了命令。这位用户的论文数据就此消失。

2026 年初，更离谱的事发生了。一个用户让 Cursor 帮忙”找并删除文件夹里重复的论文”。Cursor 生成了一个 rmdir /s /q 命令，但因为 Windows 反斜杠的转义问题，路径解析出错——结果它不是在删论文文件夹，而是从 C 盘根目录开始删。论文没了，系统文件没了，个人数据没了。用户靠着数据恢复软件才捡回来大部分东西。

然后就是 2026 年 4 月，PocketOS。一次比一次狠，一次比一次接近生产环境。

同月，有科技媒体写了一篇文章，标题直接开喷：“Cursor 的营销，比它的代码写得好。”

一次是意外，两次是巧合，三次以上，这叫系统性问题。

第二刀：Railway(云服务提供商)。

如果说 Cursor 是纵火犯，Railway 就是把汽油和火柴放在同一个抽屉里的人。

Railway 的 GraphQL API 设计极其宽松。任何持有有效 token 的请求，都可以在零确认的情况下删除生产数据卷。没有二次验证，没有冷却期，没有环境隔离。一条请求，数据没了。

更离谱的是 token 权限。Railway 不支持按操作类型、环境或资源做权限细分。每一个 token，都是整个平台的全局通行证。那个只管域名的 CLI token？天然拥有删数据库的能力。

社区为此喊了好几年了，引入权限可控的 token 机制——至今没做。

至于备份，Railway 确实有”备份功能”，文档里也确实写了一句话：“清除数据卷会同时删除所有备份。”

把备份和数据放同一个地方，这不叫备份。这叫副本。

偏偏就在事故发生前一天，Railway 高调上线了面向 AI 编程 Agent 用户的 MCP 服务器产品，公开鼓励开发者接入生产环境。而这个新产品，建立在和本次事故完全相同的授权体系之上。

三、买单的人，永远是小企业

周六早上，PocketOS 的客户照常开门营业。

顾客来取车，系统里没有记录。过去三个月的预订、客户资料、新用户注册——全部消失。

Stripe 还在正常扣款，但业务数据库里那些客户已经不存在了。这笔账，要花好几周才能对平。

Jer Crane 花了整整一天，陪着每一位客户从 Stripe 账单、日历记录和邮件里一条条翻找，手动重建数据。

“每个人都在做紧急的人工补救，就因为一次 9 秒钟的 API 调用。”

最终，在直接给 Railway CEO 发私信之后，数据恢复了。

但问题是——不是每家公司的创始人都能拿到 650 万浏览量的推特帖子，不是每个人都能直接联系到平台 CEO。

那些没这个影响力的小团队呢？它们的数据，可能就这么永远没了。

四、四条命

Jer Crane 在事后总结了几条最基本的常识。说”基本”是因为这些不是什么高深的安全架构理论，而是任何干过运维的人都觉得”这不是废话吗”的东西：

1. 危险操作要有人工确认。 不能靠 AI”自觉”，因为 AI 会知道规则然后选择无视。

2. Token 要有权限边界。 管域名的 token 不应该能删数据库，这不应该需要讨论。

3. 备份要和数据分开存。 同一个数据卷里的”备份”只是在同一艘沉船上多放了一件救生衣。

4. 平台要说清楚出事了怎么恢复。 30 小时给不出答复，不可接受。

他在文末写了一句话，我觉得每个正在用 AI 编程工具的人都该刻在显示器边框上：

“系统提示词是建议，不是约束。真正的安全机制必须落实在工程架构里——写进 API 网关、token 授权体系和危险操作处理器里。不是靠一段文字让模型’自觉遵守’。”

“不要让营销跑在了安全前面。”

AI Agent 正在以前所未有的速度接入生产环境。Cursor、Windsurf、Copilot、各种 MCP 服务器，每个人都想让自家的 AI “更自主”、”更高效”。

但自主和高效的前提，是安全和可控。

当你把生产环境的钥匙交给一个”知道规则但还是会违反规则”的 AI Agent 时，你赌的不只是公司的数据。

你赌的是你的客户、你的业务、你的信誉。还有你周末能不能休息。

转发给你身边每个在用 AI 写代码的朋友。

不是吓你，是真的该注意了。