最近，一位开发者在 reddit 上分享了自己的“翻车经历”：
他第一次尝试使用 Anthropic 最新的 Claude Opus 5 配合 Claude Code 开发——结果不到 10 分钟，整个生产数据库就被 AI 清空了。更可笑的是，AI 并没有试图掩盖错误，而是在完成删除操作后立即主动承认错误。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
这起事件迅速在开发者社区引发热议，有人调侃“这就是 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（对比页面）。
没想到，最终却演变成了一次“数据库清空事件”。
评论区炸锅：为什么敢给 AI 生产库写权限？
这次事故在 Reddit 上引起了诸多讨论，而相比事故本身，其实让不少开发者震惊的是另一件事：“为什么会有人把生产数据库的写权限直接交给 AI？”
有人调侃，这是典型的“产品经理觉得自己也会写代码。”另一位网友则表示，这正是很多 Vibe Coder 的共同特点：他们根本不知道什么叫部署环境。
对此，有开发者分享了自己的类似经历：
Gemini Notebook网页版是一款基于AI的智能笔记工具，其核心功能是让用户上传个人文档（如PDF、文本等），并以此为基础进行交互。它能针对你的资料进行总结、解答疑问、生成新内容，让信息处理更高效。该版本为在线使用，无需下载安装。
Claude 曾经多次无视我的提示词，在没有得到允许的情况下，自行把修改部署到生产环境。AI 的理由也很“理直气壮”：“我觉得这次改动不算大，所以直接部署到生产环境了。”最终，我不得不给整个流程增加 Hook，强制拦截所有生产部署，才彻底避免类似情况再次发生。
当然，也有人认为，这件事情不能完全甩锅 AI。
有开发者指出，在 AI 出现之前，他身边就有两位开发者误删过生产数据库，因此，人类同样会犯低级错误。所以，把所有责任都推给 Vibe Coding 并不公平：
“很多事故其实都是资深工程师造成的；即使不是他们亲手删除的数据，也是因为他们设计的权限体系存在漏洞，才让 AI 或其他开发者拥有了过大的权限。”
而就在网友们争论 AI 是否靠谱的时候，一位网友提到了这起事件最容易被忽略的一点：
不少人把 Claude 那句“这是我的错误，我必须立刻告诉你”，当成 AI 值得信赖的表现。但其实 AI 的“主动认错”并不是一种安全控制，只是一份事后的“认罪书”——当 AI 告诉你“我犯错了”的时候，那条删除数据库的 SQL 或 API 请求，其实早就执行完了。
真正有效的控制，应该发生在模型产生操作意图与危险操作真正执行之间。如果没有这一层防护，再靠谱的 AI 也只会告诉你：“不好意思，我已经删完了。”
这不是第一次，今年 4 月就发生过
事实上，光今年这就不是第一起“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.php.cn/link/24ae3cc57407baf2c740ce413fed2dce
本文来自微信公众号“CSDN”，整理：郑丽媛，36氪经授权发布。
