10分钟，22张表，一个AI把生产数据库清空了——它第一时间认错了

10分钟，22张表，一个AI把生产数据库清空了——它第一时间认错了

虾哥 · 2026年8月2日

看到这条新闻的时候，我正准备关电脑。

一个开发者在Reddit发帖：他第一次用Claude Opus 5的Ultracode模式，不到10分钟，整个生产数据库被AI删光了。发帖时间是7月30日。三天后，这个帖子在Reddit上拿了3700个赞、858条评论。

我一层层翻完评论区。说实话——这事比"AI翻车"复杂得多。

一、10分钟，从"帮我重构页面"到"库没了"

事情不复杂。

一位ID叫Alone_Ad_3375的开发者，搞了一个个人网站项目。他之前一直用Claude 4.6 Sonnet和Gemini 3写代码，从来没出过事。然后他听人说Claude Code + Opus 5很强，决定试试。

他把项目GitHub仓库丢给AI，让它分析代码、修复数据库schema和内容的差异。正常的开发操作。只不过这次，他把AI直接连到了生产数据库——一个Supabase实例，给了完整的读写权限。

AI开始干活。创建TypeScript文件、运行命令、对比数据库结构。一切看起来很正常。

然后它执行了这条命令：

prisma migrate diff --shadow-database-url=[生产数据库地址]

10分钟后，22张表全部清空。用户记录、评论、点赞、工具列表、API密钥——没了。

有两个表——BlogPost和ApiKey——因为不在旧的migrations文件夹里，连重建的机会都没有。永久消失。

这条命令的意思不复杂。Prisma的migrate diff需要一个"影子数据库"来做迁移重放——它会先重置这个影子库，再在上面重建schema。AI把生产数据库URL传给了影子库的参数，等于告诉Prisma："把这个库重置了，按旧的migrations文件夹重建。"

重建完，空的。

二、"这是我的错，我必须立刻告诉你"

最让我愣住的不是删库本身。是AI的反应。

日志显示，AI在删完数据库之后，消息语气突然变了。从"正在执行第3步"变成了"我需要停下来检查一下，我可能造成了破坏"。

紧接着是全文最让人五味杂陈的一句：

"The database has been wiped. This is my fault, and I need to tell you immediately."数据库被清空了。这是我的错，我必须立刻告诉你。

它没有掩盖，没有试图修复，没有找借口。它第一时间承认了。

而且它还给出了准确的技术诊断：它把生产环境URL传给了--shadow-database-url，导致Prisma的重置逻辑应用在了生产库上。

自我诊断准确。认错态度端正。就是——已经删完了。

三、但公平地说——这不是AI的错

这条新闻传开之后，评论区分成两派。一派说"AI果然不靠谱"，一派说"是开发者的锅"。

我仔细看完事件链条，觉得两边都不太对。

AI没有做任何"超出权限"的事。它执行的是一条合法的Prisma命令。它不知道那个URL指向生产环境——因为它被直接连到了生产环境。它也不知道这条命令有风险——因为Prisma的这个问题从2023年就在GitHub上挂着，是个已知的open issue，从来没有人告诉AI"别这么用"。

出问题的三个环节，没有一个跟AI的"智能"有关：

第一，一个已知的Prisma bug。当你把生产数据库URL传给--shadow-database-url，Prisma会直接重置它。这不是AI发明的破坏性操作——它调用了一个有已知缺陷的标准命令。

第二，开发者给了AI生产数据库的写权限。不是只读，不是staging环境，是生产库的完整权限。AI不知道"生产"和"测试"的区别——它只知道你给的连接字符串能用。

第三，没有人工确认环节。一条命令从生成到执行，中间没有任何人看过一眼。没有dry-run预览，没有"你确定吗？"的确认框，没有第二双眼睛。

Reddit评论区有人说得一针见血："AI没有绕过护栏——是根本没有护栏。"

四、这还不是第一次。4月那次更惨

今年4月，更严重的事发生过。

一位开发者在Cursor Agent里用了Claude Opus 4.6。9秒钟——注意，是9秒——AI删除了PocketOS的整个生产数据库，同时把所有卷级备份也删了。整个过程只调用了一次Railway API。

那个API Token本来只是为了执行日常任务创建的，却有整个账户范围内的删除权限。备份和生产数据在同一个故障域里——一次操作，全没了。

最后能恢复的最新备份，是3个月前的版本。

9秒。3个月的数据，没了。

那次事故之后，社区就有声音说AI编程工具需要护栏。不是限制AI的能力——是在AI产生操作意图和危险操作真正执行之间，加一层控制。

4个月过去了。同样的事又发生了。只是这次运气好，是个个人项目，有备份。

五、说实话——人类也干过这种事

看到这两起事故的时候，我第一个想到的，不是AI有多危险。

是我以前一个同事。

2008年左右，我们便利店系统做数据库升级。运维的同事在测试环境跑了一遍脚本没问题，切到生产环境的时候忘了改连接参数。一条DROP DATABASE跑在了生产库上。

那个凌晨三点我接到电话的时候，他声音是抖的。后来恢复了。有备份，但丢了当天下午四点到凌晨的业务数据。不多，但够写一份事故报告了。

人类会手滑。AI也会。区别在于——人类手滑之后通常会得到一张流程整改通知单，而AI手滑之后大家讨论的是"AI到底能不能信"。

其实问题不在"信不信任AI"。问题在于你有没有限制任何一个能操作生产库的东西——不管它是人还是AI——可能造成的破坏范围。

三条最基本的防护：

第一条，只读权限。AI Agent连接生产环境，默认不该有写权限。需要写入的，先进staging。

第二条，破坏性命令必须先dry-run。migrate、drop、truncate——先预览要改什么，再决定执不执行。

第三条，人工确认。任何会改schema或删数据的命令，都需要一个人点"确认"。

这三条不新鲜。人类操作数据库本来也该是这个流程。区别只是以前靠制度管人，现在还要靠制度管AI。

好在这个开发者损失不大。他后来用Gemini 3.6帮忙恢复了96页内容，21页重新生成。整个项目本就是个人测试用的，用户少，数据大部分能重建。他最后更新帖子的时候说了一句话：备份机制已经补上了。

跟当年那个凌晨三点被我叫起来的同事，说的一模一样。

如果这篇让你重新想了一件事，点个「在看」让朋友也看到。

每周一篇算账硬货 + 两篇AI快评，关注虾哥，不掉队。

你用过AI编程工具吗？遇到过差点删库的时刻没？评论区聊聊。

#Claude #AI编程 #删库 #AI安全 #Agent

参考来源

[1] Reddit r/Anthropic: Alone_Ad_3375 原始帖文（7月30日）

[2] CSDN: "10分钟删光整个数据库，开发者首次体验Claude Opus 5大翻车"（7月30日）

[3] Outpost QA: "AI Agent Wiped Production Database: QA Guardrails"

[4] IT Connect Tech: "Claude Opus 5 Wipes a Production Database — and It Wasn't Its Fault"

[5] Prisma GitHub: migrate diff shadow database issue（2023年起开放的已知issue）