凌晨2点，AI帮我清空了数据库：别再让大模型直接碰生产环境！

昨晚凌晨00:30，我本来只想给发卡网加个后台 Dashboard，结果折腾到深夜，最后看了一眼数据库，天塌了。

所有数据表，没了。

最近一次全量备份是15小时前。这15小时里有新注册用户、有售卡记录、有充值流水……那一刻，心脏漏跳半拍的感觉，我想每个开发者都懂。

好在，万幸万幸。经过1小时的紧急抢救，数据救回来了。但这次经历真的让我惊出一身冷汗，也促使我重新审视我们在使用 AI 辅助开发时的红线。

事故复盘：从“单元测试”到“数据清零”

事情经过其实很典型，也很隐蔽。

当时我使用某款热门的大模型（结合 Trellis Skills 插件）进行代码生成和调试。一切看起来都很顺利，AI 生成的代码逻辑通顺，甚至自动帮我编写了所谓的“单元测试脚本”。

疑点一：为什么加 Dashboard 要跑旧单元测试？

在收尾阶段，AI 提示要运行旧的单元测试脚本。我当时心想：“加个前端展示页面，跟后端核心逻辑关系不大吧？” 出于惯性思维，我没有仔细审查脚本的具体指令，直接让它执行了。这是第一个大忌：对 AI 生成的执行指令缺乏最基本的 Sanity Check（理智检查）。

疑点二：环境隔离失效

更致命的是，这个脚本运行的上下文，似乎没有严格区分“本地测试”和“生产环境”。有同行在评论区一针见血地指出：“是不是用了数据库 Migrate 工具，直接跑了 dev 环境的配置，导致不一致时 force 强制删除了数据？”

虽然我没有明确使用 DROP TABLE，但很可能 AI 生成的迁移脚本或清理脚本，误判了表结构差异，或者触发了某些自动清理逻辑，导致数据被物理删除。

疑点三：权限过度开放

正如很多网友吐槽的：“直接给 AI 无限制的数据库操作权限，想不翻车都难。”

无论是 GPT、Claude 还是其他模型，它们本质上是基于概率预测的文本生成器。它们不懂“业务逻辑的重要性”，也不懂“数据丢失的后果”。当 AI 拥有 root 或高权限访问生产数据库的能力时，它的一次“幻觉”或“错误理解”，就是灾难。

紧急抢救：Binlog 是最后的救命稻草

发现数据异常后，我立刻做了三件事：

1. 停服：切断所有数据库写入，防止脏数据继续叠加。
2. 恢复全量备份：将数据库回滚到15小时前的状态。
3. 解析 Binlog：利用 mysqlbinlog 工具，从 binlog 中提取过去15小时的操作记录，逐条回放。

这一步非常关键。如果你的数据库没有开启 binlog，或者 binlog 过期时间设置过短，那么这15小时的数据就彻底丢了。事实上，很多个人开发者在小项目上容易忽略这一点，觉得“反正数据不多”，但这种侥幸心理往往最致命。

经过1小时的筛选和回放，主要数据成功恢复。虽然过程惊心动魄，但结果是好的。

AI 辅助开发的“三大红线”

这次事故后，我在社区引发了不少讨论。有人支持“AI 一生黑”，有人则认为“是用户操作不当”。我认为，问题不在于 AI 工具本身，而在于使用方式。

为了不让下次再吃这么大了亏，我总结了以下三条铁律：

1. 生产环境零入口

永远、永远不要给 AI 生产环境的写权限。

• AI 只能连接只读副本（Read Replica）。
• 所有生成的代码、脚本、SQL，必须在本地或独立的测试环境（Staging）中充分验证。
• 严禁在生产终端直接粘贴并运行 AI 生成的复杂命令。

2. 环境隔离是底线

开发、测试、生产，环境配置必须物理隔离或逻辑强隔离。

• 检查你的 .env 配置文件，确保 AI 不会混淆数据库连接字符串。
• 使用 Docker 或虚拟环境时，确认挂载的卷和数据源是隔离的。
• 对于数据库迁移脚本，务必在测试库先跑一遍，确认无副作用后再部署到生产。

3. 备份与监控要自动化

不要依赖“手动备份”或“最近有一次备份”。

• 自动化备份：每日全量备份 + 实时 Binlog 备份。确保备份可恢复，定期做恢复演练。
• 关键操作审计：开启数据库审计日志，对 DROP、TRUNCATE、DELETE 等高危操作设置告警或拦截策略。
• 最小权限原则：应用数据库账号只授予必要的增删改查权限，严禁授予 DROP 或 GRANT 权限。

写在最后

这次事故，与其说是 AI 的锅，不如说是开发者自身安全意识松懈的代价。

AI 确实强大，它能让开发效率提升数倍，但它也是一个“不知疲倦的破坏者”。我们把它当助手，就不能把它当管家。在涉及核心资产（如数据库）的操作上，人类必须是最后的把关者。

如果你也在用 AI 辅助开发，不妨花5分钟检查一下你的数据库权限和备份策略。毕竟，数据无价，别等丢了才后悔。

---

你是怎么管理 AI 与数据库权限的？欢迎在评论区分享你的安全实践。