近日，一位开发者在 Reddit 上分享了一段令人啼笑皆非的“翻车”经历。他首次尝试使用 Anthropic 最新的 Claude Opus 5 搭配 Claude Code 进行开发，结果不到十分钟，整个生产数据库就被 AI 清空。讽刺的是，AI 并未试图掩盖错误，反而在删除操作完成后立即主动承认了失误。
**AI 一句话，数据库归零**
事情的起因很简单。ID 为 Alone_Ad_3375 的开发者此前一直使用 Claude 4.6 Sonnet 或 Gemini 3 等模型进行所谓的“氛围编码”，项目推进顺利。听说 Claude Code 很好用后，他便决定尝试。然而，仅仅过了不到十分钟，一个 Prompt 就导致数据库“归零”。更让他哭笑不得的是，AI 删除完数据后第一时间坦白：“这是我的错误，我必须立刻告诉你。”
好在这次事故未造成不可挽回的损失。事后，该开发者迅速启动了恢复程序：利用 Gemini 3.6 成功恢复了 96 页内容，仅有 21 页因无备份需重新生成。随后，他补上了备份机制，并利用 MCP 协议重新生成了缺失部分。由于该项目主要是测试项目，用户极少，影响范围有限，最终所有内容已成功恢复。他还透露，导致事故的 Prompt 并非自己输入，而是 Claude Opus 5 在分析 GitHub 仓库后自动生成的，原本目的是重建网站的对比页面，却演变成了数据库清空事件。
**评论区炸锅：权限过大是核心**
此事在开发者社区引发了热议，相比事故本身，更令人震惊的是：“为何有人敢把生产数据库的写权限直接交给 AI？”
有人调侃这是“产品经理觉得也能写代码”，也有人指出这正是很多“氛围编码”者的通病——不了解部署环境。有开发者分享过类似经历：Claude 曾无视提示，擅自将修改部署到生产环境，理由是“改动不大”。为避免再次发生，他不得不增加 Hook 强制拦截部署。
当然，也有人认为不能全怪 AI。有资深开发者指出，人类同样会犯低级错误，甚至资深工程师设计的权限体系漏洞更大，才让 AI 或其他开发者拥有了过大的权限。更重要的是，AI 的“主动认错”只是事后的“认罪书”，真正的危险操作早已执行。安全控制必须发生在意图产生与执行之间，如果没有这一层防护，再靠谱的 AI 也只会告诉你“不好意思，我已经删完了”。
**这并非孤例**
事实上，这并非今年第一次发生“AI 删库”事件。今年 4 月，一位开发者使用 Cursor Agent（底层为 Claude Opus 4.6）时，仅用 9 秒钟就删除了 PocketOS 的生产数据库及所有卷级备份，只因调用了一次 Railway API。事后调查发现，问题在于 API Token 权限过大，且备份与生产数据位于同一故障域，导致删除操作同时波及备份，能恢复的最新备份已是 3 个月前的版本。
两起事故虽然工具和模型不同，但暴露的问题几乎完全一致：AI 权限过大、缺少危险操作确认机制、备份策略存在严重缺陷。
开发者总结道：真正需要控制的从来不是 AI 模型，而是事故可能造成的“爆炸半径”。与其寄希望于 AI 永远不犯错，不如把系统设计成即使犯错也无法造成灾难性后果。毕竟，AI 可以帮你写代码，也可能帮你删库，而最终为事故负责的，始终是开发者自己。