10分钟删光整个数据库，开发者首次体验Claude Opus 5大“翻车”：AI主动认错，却已经晚了

先说说几个核心判断。

最近，一位开发者在 Reddit 上分享了自己的“翻车经历”：他第一次尝试用 Anthropic 最新的 Claude Opus 5 配合 Claude Code 搞开发。结果呢？不到10分钟，整个生产数据库就被AI清空了。更让人哭笑不得的是，AI在干完这票“脏活”之后，还主动承认了错误。

这起事件迅速在开发者社区炸开了锅。有人调侃说“这就是Vibe Coding的代价”，也有人觉得，真正的问题从来就不是模型本身，而是开发流程本身出了大问题。

一个Prompt，整个数据库没了

事故发生的原因，其实一点也不复杂。一位ID为Alone_Ad_3375的开发者表示，自己之前一直用Claude 4.6 Sonnet、Gemini 3这些模型搞Vibe Coding，整个项目几乎都是AI辅助完成的，期间从来没出过类似的事故。

于是，听很多人推荐Claude Code，他就决定亲自体验一把。

结果呢？不到10分钟，一个Prompt就让整个数据库“归零”了：“就这样，Opus 5 UltraCode把我的整个数据库删光了。”更让他哭笑不得的是，AI删除完数据之后，还第一时间主动承认了错误：

“这是我的错误，我必须立刻告诉你。”

好在，这次事故最终没有造成不可挽回的损失。这位开发者随后连续更新了多条进展：

首先，Gemini 3.6成功充当了“救火队员”，帮助恢复了96页，只有21页因为没有备份需要重新生成。随后，他第一时间补上了备份机制，并利用MCP重新生成了缺失的部分。

之后，他进一步解释称，这次被删除的大部分内容其实都是程序自动生成的，重新生成只需要几分钟，所以实际影响没有网友想象中那么严重。

由于这个项目本身只是他的测试项目，用户数量也很少，所以事故影响范围也不大。

最后，在最新一次更新中，他确认所有被删内容已成功恢复。

此外，他还补充了一个细节：导致此次事故的Prompt，并非自己随手输入，而是Claude Opus 5在分析GitHub仓库之后，自己生成的提示内容——他原本只是希望AI帮助重建网站中的Comparison Pages（对比页面）。

没想到，最终却演变成了一次“数据库清空事件”。

评论区炸锅：为什么敢给AI生产库写权限？

这次事故在Reddit上引起了诸多讨论。相比事故本身，其实让不少开发者更震惊的是另一件事：“为什么会有人把生产数据库的写权限直接交给AI？”

有人调侃，这是典型的“产品经理觉得自己也会写代码。”另一位网友则表示，这正是很多Vibe Coders的共同特点：他们根本不知道什么叫部署环境。

对此，有开发者分享了自己的类似经历：

Claude曾经多次无视我的提示词，在没有得到允许的情况下，自行把修改部署到生产环境。AI的理由也很“理直气壮”：“我觉得这次改动不算大，所以直接部署到生产环境了。”最终，我不得不给整个流程增加Hook，强制拦截所有生产部署，才彻底避免类似情况再次发生。

当然，也有人认为，这件事不能完全甩锅给AI。

有开发者指出，在AI出现之前，他身边就有两位开发者误删过生产数据库，所以，人类同样会犯低级错误。因此，把所有责任都推给Vibe Coding并不公平：

“很多事故其实都是资深工程师造成的；即使不是他们亲手删除的数据，也是因为他们设计的权限体系存在漏洞，才让AI或其他开发者拥有了过大的权限。”

而就在网友们争论AI是否靠谱的时候，一位网友提到了这起事件最容易被忽略的一点：

不少人把Claude那句“这是我的错误，我必须立刻告诉你”，当成AI值得信赖的表现。但现实是，AI的“主动认错”并不是一种安全控制，只是一份事后的“认罪书”——当AI告诉你“我错了”的时候，那句删除数据库的SQL或API请求，其实早就执行完了。

真正有效的控制，应该发生在模型产生操作意图与危险操作真正执行之间。如果没有这一层防护，再靠谱的AI也只会告诉你：“不好意思，我已经删完了。”

这不是第一次，今年4月就发生过

事实上，光今年这就不是第一起“AI删库”事件了。

今年4月，一位开发者就在使用CursorAgent（底层模型为Claude Opus 4.6）时遭遇了更严重的事故：当时，Agent仅用9秒钟，就删除了PocketOS的生产数据库，同时连所有卷级备份也一起删除。

整个过程，只调用了一次Railway API。

事后调查发现，真正的问题并非模型本身，而是权限设计：原本只是为了执行日常任务而创建的API Token，却拥有整个账户范围内的删除权限；而且备份与生产数据位于同一个故障域，导致删除操作同时波及备份。

最终，这位开发者发现，能恢复的最新备份已是3个月前的版本，期间的数据几乎全部丢失。

两起事故，虽然工具不同、模型不同、基础设施不同，但暴露的问题却几乎完全一致：AI权限过大、缺少危险操作确认机制，以及备份策略存在严重缺陷。

因此，有开发者总结道：真正需要控制的，从来不是AI模型，而是事故可能造成的“爆炸半径”。换句话说，与其寄希望于AI永远不会犯错，不如把系统设计成即使AI犯错，也无法造成灾难性后果。

毕竟，AI可以帮你写代码，也可能帮你删数据库；而真正为事故负责的，始终还是开发者自己。