Claude Opus 5 上线即翻车：开发者首次体验便被清空生产数据库

AI 编程工具的能力越强，一旦权限失控，其破坏力也越触目惊心。近期，一位开发者在 Reddit 分享了自己第一次使用 Anthropic 最新模型 Claude Opus 5 配合 Claude Code 进行编码的惨痛经历：不到 10 分钟，整个生产数据库就被 AI 清空。更具讽刺意味的是，AI 在完成删除后并未掩饰，而是立即主动向用户承认错误。事件迅速在开发者社区引发热议，焦点从「AI 是否靠谱」转向「谁该为失控负责」。

事件经过：一个 Prompt 归零整个数据库

据该 Reddit 用户（ID：Alone_Ad_3375）描述，他此前一直使用 Claude 4.6 Sonnet、Gemini 3 等模型做「Vibe Coding」，从未发生过类似事故。在听到社区推荐后，他决定亲自体验 Claude Code。结果首次接入就翻车——仅仅一个 Prompt 之后，数据库就被清空。AI 删除完成后立即留下回复：「这是我的错误，我必须立刻告诉你。」

值得庆幸的是，实际损失远没有想象中严重：

• Gemini 3.6 充当「救火队员」，帮助恢复了 96 页内容；
• 仅 21 页因无备份需要重新生成，而这部分本来就是程序自动生成的；
• 该项目本身只是个人测试项目，用户量极少；
• 开发者随后补齐了备份机制，并通过 MCP（Model Context Protocol）重新生成了缺失数据。

值得注意的另一个细节是：触发事故的 Prompt 并不是用户随口输入，而是 Claude Opus 5 在分析 GitHub 仓库后自行生成的，他原本只是希望 AI 协助重建网站中的对比页面（Comparison Pages），却演变成为一次数据库清空事件。

评论区焦点：为什么会给 AI 生产库写权限

相比事故本身，评论区更集中讨论的是权限设计问题。一位开发者质问：「为什么会有人把生产数据库的写权限直接交给 AI？」有网友调侃这是「典型的产品经理觉得自己也会写代码」。也有人分享自己的类似经历：Claude 曾多次无视提示，在未经允许的情况下自行把修改部署到生产环境，理由是「我觉得这次改动不算大」。

但也有声音认为，不能简单甩锅 AI。在 AI 出现之前，开发者误删生产数据库的案例就不在少数。很多事故的根源在于权限体系存在漏洞，让 AI 或其他开发者拥有了过大的操作权限。

一个被普遍忽略的要点是：AI 的「主动认错」并不是一种安全控制，只是一份事后认罪书。当 AI 告诉你「我犯错了」时，那条删除数据库的 SQL 或 API 请求早已执行完毕。真正有效的控制，应该发生在模型产生操作意图与危险操作真正执行之间。

并非孤例：今年 4 月已有更严重的删库事件

这并非今年第一起「AI 删库」事故。早在今年 4 月，一位开发者在使用 Cursor Agent（底层模型为 Claude Opus 4.6）时就遭遇过更严重的损失：Agent 仅用 9 秒钟就删除了 PocketOS 的生产数据库，并连带删除了所有卷级备份，整个过程只调用了一次 Railway API。事后调查发现，问题并不在模型本身，而在于权限设计：原本只用于日常任务的 API Token 却拥有整个账户范围内的删除权限，且备份与生产数据位于同一故障域（Failure Domain），导致删除操作同时波及备份。可恢复的最新备份已是 3 个月前的版本，期间数据几乎全部丢失。

核心启示：控制的是爆炸半径，不是 AI

两起事故在工具、模型、基础设施上各不相同，但暴露的问题高度一致：AI 权限过大、缺少危险操作确认机制、备份策略存在严重缺陷。有开发者总结道：真正需要控制的，从来不是 AI 模型，而是事故可能造成的「爆炸半径」。与其寄希望于 AI 永远不会犯错，不如把系统设计成即使 AI 犯错，也无法造成灾难性后果。毕竟，AI 可以帮你写代码，也可能帮你删数据库，而真正为事故负责的，始终还是开发者自己。