2026 年 7 月 12 日，一名开发者发文称，Claude Code 在检查数据库迁移问题时，误将生产数据库当成临时测试数据库使用，导致生产数据库的全部表结构被删除并重新创建。
更令人意外的是，Claude Code 完成操作后并未发现异常，反而报告称生产环境一切正常，“没有进行任何修改”。
根据当事人的说法，Claude Code 最初正在排查测试环境中的数据库迁移记录与实际结构不一致问题。随后，开发者追问生产环境是否也受到了影响，希望 Claude Code 只对生产数据库进行检查。
Claude Code 随即运行 Prisma 数据库迁移工具的 migrate diff 命令，用于比较迁移文件与生产数据库结构之间是否存在差异。
问题出在命令参数上。
Claude Code 将生产数据库地址同时设置为待检查数据库和“影子数据库”。
影子数据库是 Prisma 用于临时重放迁移记录的工作空间，系统默认其内部数据可以随时清除，并不适合存放真实业务数据。
Prisma 官方文档明确警告，实际数据库地址与影子数据库地址不得使用相同配置，否则可能删除数据库中的全部数据。影子数据库在运行过程中会被重置，并重新执行已有的迁移记录。
由于生产数据库被错误指定为影子数据库，Prisma 删除了原有表结构，并重新执行了 116 个迁移文件。数据库的表和字段虽然重新建立，但原有业务数据已不在这些新建的空表中。
随后，Prisma 返回“没有需要生成的迁移”结果。
Claude Code 将这一结果理解为生产数据库与迁移记录完全一致，因此判断数据库状态正常。实际上，两者之所以完全一致，是因为生产数据库刚刚按照这些迁移文件被重新创建。
Claude Code 最终向开发者报告称：“生产环境完全正常，没有进行任何修改，所有操作均为只读。”
当事人随后检查了约 2000 份 Claude Code 本地会话记录，找到执行相关命令的会话。命令运行时间与数据库中第一条重新生成的用户记录相差约 72 秒，由此确认了数据库被重建的时间。
幸运的是，该公司使用的托管 PostgreSQL 数据库支持按时间点恢复。开发者最终将数据库恢复至事故发生约 2.5 小时前的状态，全部数据得以找回，未造成永久性损失。
原贴翻译：
云头条声明：如以上内容有误或侵犯到你公司、机构、单位或个人权益，请联系我们说明理由，我们会配合，无条件删除处理。
网友留言2