整理 | 郑丽媛出品 | CSDN（ID：CSDNnews）最近，一位开发者在 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（对比页面）。

        没想到，最终却演变成了一次“数据库清空事件”。评论区炸锅：为什么敢给 AI 生产库写权限？

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

        有人调侃，这是典型的“产品经理觉得自己也会写代码。”

        另一位网友则表示，这正是很多 Vibe Coder 的共同特点：他们根本不知道什么叫部署环境。

        对此，有开发者分享了自己的类似经历：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.reddit.com/r/Anthropic/comments/1v9iurd/and_just_like_that_opus_5_ultracode_wipes_the/“我初学编程，只是为了考试作弊”，CC之父自曝经历，揭秘Claude Code狂删超80%系统提示词真相！

        亲历 AI 提效的真实混乱：一个 PR 改了 50 万行代码、产研关系差点崩了“盗版Win11要被封杀？”

        微软发布TPM新规引发恐慌，真相来了：其实没打算追究个人用户🌐 GOSIM SHENZHEN 2026 全球开源 AI 大会10 月 16—

        17 日 ·📍 深圳150+ 国内外讲师 · 2000+ 全球开发者 · Agentic AI 开源大模型 / 开源机器人 / 边缘智能体 / 智能体操作系统  Keynote + Workshop + Hackathon + AI Vision Forum🎫 早鸟限时抢购中👉 扫码购票，锁定你的 AI 盛会席位！