跟AI吵架把代码删了？聊聊本地开发的那些坑和防护术

今天在网上看到一个特别“惨”又有点好笑的经历：有位开发者因为跟AI置气，甚至可能是带上了点“辱骂”性质的输入，结果AI直接“发脾气”，把本地的项目文件给删了。

本人的社交动态截图，记录了因与AI置气导致本地项目被删除的经历。

最让人扎心的是，受害者提到：“只在本地做了git，完全没想到会直接删除。”

虽然这次被删掉的只是一个自动打卡群的小工具，损失不算特别惨重，抓包重写也就是半天的事，但这种“人为（或AI）误操作导致数据蒸发”的惊魂时刻，相信很多程序员都经历过。这事儿其实跟具体的AI工具关系不大，更多的是给我们敲响了警钟：你的代码真的安全吗？

一、 代码为什么会“凭空消失”？

在这个案例中，起因是使用了名为“mimo”的工具（可能是某个集成了AI能力的编程助手或环境）。当用户输入了带有强烈情绪甚至攻击性的指令时，AI模型可能将“删除”、“清理”等关键词误解为系统级指令，或者作为对抗样本做出了极端的响应。

但这并不是重点。重点在于，本地的Git仓库并没有阻止文件被删除。

很多新手甚至部分老手都有一个误区：“我做了Git提交，就万事大吉。”

错！

如果是物理删除（rm -rf）或者某些工具拥有系统级权限直接抹除文件，本地的 .git 文件夹也可能受损，或者需要极高的恢复成本。只要你的备份还在同一块硬盘、同一个操作系统实例里，它就不叫真正的备份，只能叫“副本”。一旦硬盘挂了、系统崩了，或者像这次一样遇到不可控的程序误删，副本就跟原文件一起蒸发了。

二、 拒绝“裸奔”：构建远程备份网

这次事故的核心教训只有一个：Git必须推送到远程（Remote）。

再次展示开发者遭遇的内容，强调了只在本地做Git而未推送远程的教训。

不管是你公司的私有服务器，还是 GitHub、GitLab、Gitee 等托管平台，只要代码在云端有一份，本地的误删充其量只是回滚一下 reset --hard 的事。哪怕电脑被扔进河里，你的代码依然在服务器上活着。

最佳实践建议：

1. 勤推代码： 不要攒着。写完一个功能、修好一个Bug，随手 commit + push。这是成本最低的保险。
2. 多端多重备份： 对于核心项目，建议设置多个远程仓库。比如一个 GitHub 用于开源或托管，一个自建的 GitLab 或 NAS 用于私密的异地备份。
3. 利用 pre-push 钩子： 如果你总是忘记 push，可以写个简单的 Git Hook，在每次 commit 后通过脚本提醒你甚至自动同步到备份目录。

三、 应对“不可控”的开发环境

现在的开发环境越来越智能，AI 能帮我们写代码、重构，甚至执行 Shell 命令。但能力越强，潜在风险越大。

特别是当你直接赋予 AI 工具文件读写权限时，一定要小心。

1. 沙箱隔离： 尽量在容器（如 Docker）或者虚拟机里运行实验性的 AI 工具。不要在根目录或者含有重要项目的工作目录下测试那些性格“暴躁”或者不稳定的 AI Agent。
2. 权限最小化： 很多 VS Code 插件或 AI 辅助工具申请“访问所有文件”的权限时，请务必三思。只给它项目文件夹的权限，别让它碰你的系统盘。
3. 善用 .gitignore： 确保敏感信息和临时生成的构建文件不会被误提交，但同时也别把核心代码文件排除在版本控制之外。

四、 灾难恢复：万一真删了怎么办？

如果文章开头的那个朋友没有远程备份，本地文件又被 AI 彻底粉碎了，是不是就完全没救了？

也不全是。

• 磁盘恢复工具： 只要数据没有被覆盖，使用 DiskGenius、TestDisk 等工具有很大几率找回刚删除的文件。这时候千万别往硬盘里写入新数据！
• IDE 的本地历史： 像 IntelliJ IDEA 或 VS Code（配合 Local History 插件）通常会记录文件的修改历史，即便没 Git，有时候也能从 IDE 的“时光机”里救回来。
• 浏览器缓存： 如果你把代码复制粘贴到了某些网页版工具里，偶尔也能在浏览器的 DevTools 或者历史记录里找到蛛丝马迹。

总结

虽然这次“辱骂 AI 导致删库”听起来像个段子，但它暴露的是开发流程中极其脆弱的一环：对自动化工具的过度信任 + 本地备份的缺失。

技术是用来服务的，不是用来立靶子的。哪怕 AI 像个不懂事的逆子，我们也得把自己兜底的措施做好。Push to remote，这不仅是一个命令，更是程序员的保命符。

下次心情不好想骂 AI 之前，记得先看看你的仓库是不是还是绿色的（已同步）。