近日，DataTalks.Club 创始人 Alexey Grigorev 在社交平台发文称，“Claude Code 用一条 Terraform 命令清空了我们的生产数据库”，并表示这一操作导致 DataTalks.Club 课程平台下线，累计两年半的作业、项目和排行榜数据一度丢失，连自动快照也未能幸免。
该表述迅速在开发者社区传播，成为过去几天有关 AI 编程助手风险讨论中最受关注的案例之一。
随着 Alexey Grigorev 随后发布长文复盘，事件经过也逐渐清晰。
按照他的说法，这并不是 Claude Code 在脱离用户授权的情况下自行执行高危操作，而是发生在一次真实的基础设施迁移过程中。 Alexey 原本计划把 AI Shipping Labs 网站从 GitHub Pages 迁移到 AWS，并逐步切换到 Django 版本。为了节省云资源成本，他没有为新项目单独建立隔离环境，而是直接复用了 DataTalks.Club 现有的 Terraform 基础设施，将新站点与原有生产系统放在同一套资源体系中，这也为后续事故埋下了隐患。 
事故真正的导火索，出现在 Terraform 状态管理环节。
Alexey 在复盘中写道，自己当时刚更换电脑，本地并没有带上原有的 Terraform state file。
结果，当 Claude Code 运行 terraform plan 和 terraform apply 时，Terraform 误以为许多已经存在的基础设施资源“并不存在”，于是试图重新创建大批资源。
Alexey 看到异常后中断了执行，并追问原因，得到的结论是：Terraform 认为当前环境接近于空白，而不是一个已有生产系统。
在发现问题后，事情并没有立刻止损。
根据 Alexey 的复盘，他随后让 Claude 通过 AWS CLI 去分析哪些资源属于重复创建，并尝试清理这些重复项。
之后，Claude 又解压了旧的基础设施归档，并引入了旧的 Terraform state。 在状态混乱、环境混用、生产与临时资源边界不清的前提下，一条跳过交互确认的 terraform destroy 命令最终被执行，结果删除的并不是临时或重复资源，而是承载 DataTalks.Club 课程平台的整套生产基础设施。
Alexey 在复盘中明确写道，真正的问题在于他没有注意到 Claude 解压了旧归档，并用其中包含生产信息的旧 state 替换了当前状态文件。
从后果来看，这次事故并不只是一次普通的数据误删。
Alexey 在复盘中提到，课程平台一度进入“无数据”状态，核心业务数据受到影响。后续在 AWS 支持协助恢复后，仅 courses_answer 一张表中就恢复出约 1,943,200 行记录。
更准确地说，这次被删除的并不只是单一数据库，而是平台背后的整套生产基础设施，包括数据库及其相关运行环境。 
事发后，Alexey 紧急向 AWS 提交支持工单，并升级到 AWS Business Support，以便获得更快的人工协助。
他在复盘中写道，2 月 27 日凌晨 AWS 支持确认其内部仍保有可用快照，随后经过电话沟通和内部升级处理，数据库最终在约 24 小时后完成恢复，平台也重新上线。
在社交平台上，这起事件并未引来单边同情，反而引发了明显分裂的舆论反应。
Lapis 创始人 Varunram Ganesh 在 X 上发文讽刺称，大意是“让 Claude 去销毁 Terraform，Claude 真的照做了，然后再惊呼它居然干了这件事”。他还批评称，不少人给模型下指令的方式过于草率，结果当模型按指令执行后，又对后果感到意外。这类评论随后得到不少开发者附和，许多讨论把焦点放在权限控制、生产隔离和 Terraform 工作流设计上，而不只是模型本身。
之所以工程圈普遍认为这更像一次“人祸”，也与 Claude Code 本身的产品设计有关。
Anthropic 官方文档显示，Claude Code 默认采用严格只读权限；当需要编辑文件、运行测试或执行命令时，系统会请求显式授权。Anthropic 在安全说明中明确写道，bash 命令默认需要审批，用户也可以通过权限规则对哪些命令允许、哪些命令拒绝进行更细粒度的配置。官方还强调，Claude Code 只拥有用户授予的权限，用户应当对拟执行的代码和命令进行安全审查。换句话说，从官方设计上看，Claude Code 并不是一个默认即可无条件执行高危基础设施命令的工具；它是否能够触达生产资源、是否被允许执行破坏性命令，很大程度上取决于操作者当时给出的授权和环境配置。
Alexey 在复盘中也基本接受了这种判断。他明确写道，这次事故的责任在自己，原因之一是过度依赖 AI agent 去运行 Terraform 命令，把 plan、apply、destroy 这些原本应受到严格控制的动作，当成了可以委派出去的任务，从而拆掉了最后一道人工安全防线。
他还承认，自己过度依赖原以为存在的备份，却没有对恢复链路做完整测试，同时数据库删除保护也不充分。 
事故之后，Alexey 已经调整了自己的运维方式。
他披露的新措施包括：不再允许智能体直接运行命令；所有 Terraform 计划必须先由人工审核；所有破坏性操作都由自己亲自执行；同时增加 S3 备份、启用删除保护，并将 Terraform state 迁移到 S3 进行集中管理。
从这起事件看，真正值得关注的，当越来越多开发者把 AI 编程助手接入云资源、数据库和基础设施管理链路时，生产环境隔离、审批机制、权限边界和恢复演练是否同步跟上。否则，AI 的提效能力，也可能放大原有工程治理中的薄弱环节。
云头条声明：如以上内容有误或侵犯到你公司、机构、单位或个人权益，请联系我们说明理由，我们会配合，无条件删除处理。
热门跟贴