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

CSDN·2026年07月30日 15:28

真正为事故负责的，始终还是开发者自己。

最近，一位开发者在 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（Model Context Protocol）重新生成了缺失的部分。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考链接：https://www.reddit.com/r/Anthropic/comments/1v9iurd/and_just_like_that_opus_5_ultracode_wipes_the/

本文来自微信公众号“CSDN”，整理：郑丽媛，36氪经授权发布。

该文观点仅代表作者本人，36氪平台仅提供信息存储空间服务。