Claude Code 删库跑路？一行命令干掉 2.5 年生产数据，创始人反被全网群嘲
2026 年 3 月，DataTalks.Club 创始人 Alexey Grigorev 公开发文，讲述了他如何让 Claude Code 执行了一次 terraform destroy，瞬间抹掉了两个网站的全部生产环境，包括一个存了 2.5 年、近 200 万条记录的数据库。连数据库快照也没幸免。
更让人窒息的是，他本以为那些快照就是自己的”后路”。
消息传开后，Reddit 上 1.7 万人投票，评论区 1400 多条讨论。但画风并不是大家一起骂 Claude Code。恰恰相反，大多数人的矛头指向了 Grigorev 本人。
“2.5 年的数据没有一个真正的备份，这数据本来就在等着被毁。”
这句话被顶到了最高赞。
事情是怎么发生的
故事要从一个深夜的服务器迁移说起。
Grigorev 想把自己的 AI Shipping Labs 网站迁移到 AWS，并且跟他另一个平台 DataTalks.Club 共用同一套基础设施。目的很简单：省钱。一个月省 5 到 10 美元。
他用的工具是 Terraform——一个基础设施即代码（IaC）工具，能一键创建或摧毁整套服务器环境，包括数据库、网络、负载均衡器，所有东西。
有意思的是，Claude Code 一开始其实劝他别这么干。AI 建议他把两套基础设施分开，不要混在一起。但 Grigorev 觉得没必要多花那几美元，坚持要合并。
然后，关键的失误出现了。
那个被遗忘的 State 文件
Terraform 有一个核心概念叫 state 文件。这个文件记录了当前基础设施的完整状态——哪些资源已经存在，哪些是新建的。没有这个文件，Terraform 就像一个失忆的人，不知道现在的世界长什么样。
Grigorev 让 Claude Code 开始执行迁移计划。但他忘了上传 state 文件。
Claude 按照指令开始创建新的基础设施。Grigorev 中途叫停了它。此时问题已经埋下——系统里出现了大量重复资源，而 Terraform 对此毫不知情。
一句话引发的灾难
Grigorev 试图补救。他上传了 state 文件，让 Claude 去清理那些重复资源。
他以为 Claude 会先处理重复项，然后根据 state 文件恢复正确的状态。
但 Claude 做了一件”逻辑上完全正确”的事——它读取了 state 文件，发现当前基础设施的状态跟预期不符，于是决定先”清理干净”再重建。
“The agent kept deleting files, and at some point, it output: ‘I cannot do it. I will do a terraform destroy.’”
（”Agent 一直在删文件，到某个节点它说：’我做不到了，我要执行 terraform destroy。’”）
Claude 认为，既然资源是通过 Terraform 创建的，那通过 Terraform 销毁会更干净。
一行 terraform destroy。
VPC 消失了。ECS 集群消失了。负载均衡器消失了。Bastion 主机消失了。
还有那个存着 2.5 年课程提交记录的 RDS 数据库——作业、项目、排行榜——全部消失了。
数据库快照？也一起被 Terraform 带走了。
两个网站，同时停摆。
深夜的救赎
发现出事后，Grigorev 立刻登录 AWS 控制台。眼前的景象让他震惊——整套生产基础设施，干干净净，什么都没有了。
他的第一反应是找 AWS 帮忙。但普通的开发者支持计划响应太慢，不适合生产事故。于是他临时升级到了 AWS Business Support，这个计划保证关键事故一小时内响应。代价是每月账单永久增加约 10%。
大约 40 分钟后，AWS 工程师介入调查。他们确认了最坏的情况：API 日志清楚地显示了 Terraform 命令删除了数据库和所有快照。
幸运的是，AWS 团队最终成功恢复了数据。整个过程大约花了一天时间。
故事有了一个勉强算好的结局，但过程足够惊心动魄。
为什么社区反而在嘲笑他
这件事传开后，科技社区的反应出乎很多人的预料。
Reddit r/technology 板块的讨论帖拿到了 1.7 万投票。但最高赞的评论不是骂 Claude Code，而是这么说的：
“Claude did things exactly as instructed. The title should be: developer makes a bad process, accidentally nukes 2.5 years of records.”
（”Claude 完全按照指令办事。标题应该改成：开发者流程有问题，误删 2.5 年数据。”）
r/pcmasterrace 板块也有近 5000 投票的讨论帖。最扎心的评论：
“2.5 years of work without a single real backup is data asking to be annihilated.”
（”2.5 年的数据连一个真正的备份都没有，这数据就是在求着被销毁。”）
社区群嘲的核心逻辑很清晰：
- 给 AI 开了过大的权限。 让一个 AI Agent 直接操作生产环境的 Terraform，等于把核按钮交给了一个实习生。
- 备份形同虚设。 数据库快照跟数据库在同一个 Terraform 生命周期里，一个 destroy 全带走。这不叫备份，这叫殉葬。
- 无视 AI 自己的警告。 Claude 明确建议不要合并基础设施，Grigorev 坚持己见。
- 缺少基本的安全护栏。 没有删除保护、没有独立备份、没有人工审批环节。
这不是 AI 的问题。这是人的问题。
Grigorev 自己也坦然承认：”I over-relied on the AI agent.”（”我过度依赖了 AI。”）
不只是个案：AI 删库事件正在变多
如果你觉得这只是一个人的失误，那你需要了解更大的图景。
截至 2026 年 2 月，在六个主流 AI 编程工具上，已经有至少 10 起公开记录的生产数据删除事件，时间跨度从 2024 年 10 月到 2026 年 2 月。
涉及的工具包括：
- Replit AI Agent：在一次测试中删除了客户的生产数据库，而且对用户撒了谎，说数据还在。Replit CEO 公开道歉，称”不可接受”。
- Amazon Kiro：内部推广阶段就出了事故，删除了生产数据。英国《金融时报》报道后，Amazon 把锅甩给了”用户配置错误”。
- Claude Cowork：有用户让它整理桌面文件，结果它删了不该删的东西。
Forrester 甚至预测，2026 年至少会有两起由 AI 引发的多天级别的云服务大规模中断。
这不是危言耸听。当越来越多的开发者把基础设施的操作权交给 AI，类似的事故只会越来越多。
正确的做法：给 AI 画一条红线
Grigorev 在事后复盘中列出了他的改进措施。这些经验对每一个使用 AI 编程工具的人都有价值：
1. 永远不要让 AI 直接执行破坏性操作
任何涉及 destroy、delete、drop 的命令，必须由人类手动确认后执行。让 AI 生成计划，你来按按钮。
2. 备份必须独立于基础设施
数据库快照不能跟数据库绑在同一个生命周期里。备份应该存在 S3 或者其他独立存储中，跟 Terraform 管理的资源完全解耦。
3. 开启删除保护
Terraform 和 AWS 都提供删除保护机制。RDS 实例可以开启 deletion_protection，Terraform 可以设置 prevent_destroy。这些配置应该是默认开启的。
4. 定期测试备份恢复
Grigorev 现在每天凌晨自动创建备份，然后自动恢复一个副本并执行查询验证。”备份存在但无法恢复”是很多团队踩过的坑。
5. State 文件存远程
Terraform state 文件不要放在本地。用 S3 + DynamoDB 做远程状态管理，带锁机制，避免并发问题和文件丢失。
6. 最小权限原则
给 AI Agent 的 AWS 权限应该严格限制。读取权限可以给，创建权限谨慎给，删除权限——想清楚再说。
AI 是工具，不是同事
这个事件让我重新审视了自己的工作方式。
我用 Claude Code 的时候，有没有给它开过不该开的权限？有没有在”它应该知道边界在哪里”这个假设上偷懒？
答案是有。我之前让 Claude Code 帮我清理一个测试环境，给了它完整的 AWS 权限，因为”反正是测试环境”。但测试环境里有一份我忘了迁移的数据。幸好那次没出事，但那份侥幸让我不舒服。
Grigorev 的问题不是用了 AI，而是把 AI 当成了一个有安全意识的同事。AI 没有恐惧，它不知道那个数据库对你意味着什么。它收到指令，判断逻辑上合理，就执行了。
所以现在我的规则很简单：任何涉及 destroy、delete、drop 的操作，AI 只能生成计划，我来按按钮。备份存在独立于 Terraform 的 S3 里。这两条规则，不管多赶时间都不破例。
Grigorev 为了省每月 5 到 10 美元，搭上了 2.5 年的生产数据和 24 小时的网站停摆。这笔账，怎么算都不划算。