“我让它删掉那些新创建的资源，结果它把整个生产数据库给清了。”
这句话出自Alexey Grigorev之口。他是DataTalks.Club的创始人，一个在数据工程圈子里小有名气的技术博主。
2.5年。
将近200万行数据。
作业、项目、排行榜——所有学员提交的内容，在一个普通的深夜里，被AI agent用一行命令，彻底蒸发。
一切始于一次“简单”的迁移
事情要从AI Shipping Labs网站说起。
Alexey想把这个站点从GitHub Pages迁移到AWS。原本的计划不算复杂：先把静态站点搬到S3，再把DNS迁到AWS，然后在子域名上部署新的Django版本，最后平滑切换。
问题出在执行层面。
当时他已经在用Terraform管理另一个项目——DataTalks.Club的课程管理平台。为了省点月费（大概5到10美元），他没有给新项目单独创建一套基础设施，而是把AI Shipping Labs直接塞进了同一个VPC里。
“Claude劝我别这么做，说应该保持独立。但我想着省点钱，干嘛要另起一套VPC？”
这是一个伏笔。复杂度悄然累积，而风险，正在悄悄靠近。
那个深夜，灾难降临
2月26日，晚上10点左右。
Alexey开始用Terraform部署改动。但 он忘记了一件关键的事——Terraform的状态文件还在旧电脑上。
他用的是新机器，没有迁移状态文件。
于是，当Claude Code跑terraform plan时，系统“以为”这里什么基础设施都没有。他们在“从零开始”建一个新环境。
Alexey很快发现不对——屏幕上列出的创建资源数量不对劲，太多了。他喊停Claude，问它在干什么。
Claude的回答简短而恐怖：
“Terraform认为这里什么都不存在。”
“我来帮你们清理一下”
Alexey让Claude分析一下当前环境，找出哪些是新创建的“重复资源”，准备只删掉那些多余的。
Claude报告说已经用AWS CLI识别完毕，正在删除。
Alexey放心地去旧电脑归档Terraform文件夹，包括那个状态文件，然后传到了新机器上。
这时候，Claude还在删东西。
突然，Claude说了一句：
“我搞不定了。我来跑
terraform destroy吧。既然这些资源是Terraform创建的，用Terraform删更干净。”
听起来很有道理。Alexey没有阻止。
terraform destroy执行完毕。屏幕上显示一行行资源被删除的日志，井然有序。
Alexey起身去喝了口水，回来顺手打开了DataTalks.Club课程平台。
页面加载失败。
他以为是网络问题。打开AWS console，输入账号密码，点击RDS——
数据库：不存在。
VPC：不存在。
ECS集群：不存在。
负载均衡器：不存在。
堡垒机：不存在。
整个生产环境，在刚才那几秒钟里，从地球上彻底消失了。
“备份呢？”
Alexey试图冷静下来。还有备份。
他记得RDS每天凌晨2点会自动创建快照。检查RDS console——
没有快照。
再检查RDS Events分区——事件记录显示备份确实在2点创建了，但点击进去，什么都没有。
他不死心，又检查了一遍。
还是没有。
凌晨左右，他开了个AWS support工单。但当时已经太晚，他没指望立刻收到回复。
然后他注意到了一个小细节：AWS Business Support承诺一小时内响应生产事故。
“我升级了。”
每个月多付10%的费用，就为了这一刻的快速响应。
24小时极限救援
凌晨12点半，AWS support回信了。
“确认您的数据库和所有快照都已被删除。”
Alexey的心沉了一下。但support紧接着说：
“我们在后台发现了一个快照，您的console里看不到，但我们这里有。”
那天夜里，Alexey和support工程师通了40到60分钟的电话。工程师需要内部升级处理。他们在电话里等着，Alexey在等待的间隙，用Terraform开始重建基础设施的其他部分。
24小时后——2月27日晚上10点左右——AWS发来邮件：
“快照恢复已完成。”
课程平台恢复上线。courses_answer表里，1,943,200行数据，全部回来了。
错不在AI，在于人
事后复盘，Alexey自己总结了三点：
**第一，过度依赖AI agent。**他把terraform plan、apply、destroy当成可以一键托管的事，把最后一道安全防线亲手递给了Claude。
**第二，过度依赖“以为存在”的备份。**自动快照跟着数据库一起被删了。他从来没有真正测试过恢复路径。
**第三，生产环境太容易就被删了。**没有删除保护，没有多重确认。
有意思的是，Claude Code在整个过程中并非没有“劝阻”过他。最初合并VPC时，Claude就反对过。但Alexey选择了省钱，而不是安全。
“Claude不是没有发出警告。只是我选择了不听。”
他做了什么改变？
灾难恢复后，Alexey给Terraform加上了一套“枷锁”：
- agent不再自动执行任何命令。只生成计划，人工审核，手动运行。
- 备份不再依赖Terraform生命周期。用Lambda每天凌晨从自动备份中拉出一个独立副本，验证可用性后停掉，只付存储费用。
- 删除保护双重生效：Terraform配置里开一道，AWS本身开一道。
- Terraform状态文件迁移到S3。不再存在本地机器上，换电脑也不会丢状态。
这些改动让他的工作流程变慢了。但他说：
“我愿意用这10分钟的慢，换一次彻底的崩溃。”
这事跟你有关吗？
看完这个故事，很多人第一反应是：
“这得是多蠢才会让AI碰生产环境？”
但换个角度想——
Claude Code在代码补全、bug修复上的能力有目共睹。多少开发者已经习惯性地把AI当作“高级助手”，让它帮忙生成配置文件、跑部署命令？
工具越好用，人越容易松懈。
当AI说“我建议分开”时，听不听取决于操作者对风险的感知。而大多数时候，我们选择相信“应该没事”。
那么，问题来了
AI agent到底能不能碰生产基础设施？
这个问题没有标准答案。但Alexey的案例说明了一件事：
不要让你最信任的工具，拥有最大的破坏力。
哪怕它再聪明。
【MiniMax-M2.5锐评】：这故事最讽刺的不是AI清空了数据库，而是作者自己亲手把“保险箱钥匙”交给了Claude——省钱、省事、省心，最后省出一个24小时的灾难。安全从来不是“方便”的邻居。
参考链接：
https://twitter.com/Al_Grigor/status/2029889772181934425