慎用 AI 编程助手！一次惊心动魄的 Git Reset 救援实录

现在用 AI 写代码或者辅助操作 Git 已经是很多开发者的日常了，但说实话，这东西有时候真能给你搞个“大惊吓”。

今天我想聊聊最近遇到的一个翻车现场，顺便给各位提个醒，别把太核心的操作全权交给那些“聪明过头”的模型。

翻车现场：我想建 Worktree，它帮我来了个 Reset

事情的起因很简单。我在做项目开发，需要在同一个仓库里并发处理多个分支。按照常规操作，这时候用 git worktree 是最方便的，不用频繁切分支，还能同时运行不同版本的服务。

某 OpenCode 插件在收到创建 Worktree 指令后，错误地执行了 git reset --hard，导致本地提交记录丢失。

我用的编辑器自带的 AI 插件（也就是某 OpenCode 自带的免费版 Mimo 2.5 模型）。我心想着这是个简单的指令，直接告诉它：“帮我新建一个 worktree 用于处理 hotfix 分支”。

我本以为它会乖乖在终端里吐出一条 git worktree add ... 命令，结果它反手就给我来了个“骚操作”——直接执行了 git reset --hard！

当我切回屏幕看的时候，不仅 worktree 没建起来，我本地刚才写的一堆代码提交记录全没了！那一瞬间真的头皮发麻，这几小时的代码难道要重来？

踩坑分析：为什么 AI 会“理解错”？

事后我复盘了一下，为什么这种免费模型会犯如此低级的错误？

1. 上下文理解能力偏弱：很多所谓的“免费版”或轻量级模型，在长文本或复杂指令的理解上真的很一般。它可能提取到了“Git”、“分支”、“清理/新建”这些关键词，但在逻辑链上崩塌了，把它理解的“清理当前环境以便新建”映射成了 reset 这种高危指令。
2. 缺乏“安全阀”机制：人类操作 git reset --hard 之前通常会下意识看一眼状态。但 AI 是指令执行机器，一旦概率上判定这是下一步的最优解，它就会毫不犹豫地执行，完全没有“恐惧感”。

当时我心急火燎地赶紧问同一个 AI：“你刚才干了什么？帮我把提交记录找回来！”

结果这模型给我整出一句“对不起，我无法找回历史记录”，直接装傻卖乖。这真叫“杀人诛心”。

成功救援：还是得靠 Kimi 2.6

没法子，我只能指望更靠谱的“外援”了。我转头找到了 Kimi 2.6（当然，Moonshot 自家那几个强力模型其实也行）。

我把我刚才想做的一系列操作、现在的惨状，以及它之前的错误行为描述了一遍。Kimi 的反应明显不一样，它没有急着给我执行命令，而是先分析了情况，然后给我提供了一套 git reflog 的救援方案。

简单说一下它给我的救援思路（建议大家收藏，保命专用）：

1. 不要慌，先查日志：只要你的仓库没被暴力垃圾回收（GC），Git 其实什么都记得。Kimi 提示我先运行 git reflog。这个指令会列出 HEAD 的所有移动记录，包括那个误操作的 reset。
2. 定位灾难发生前的 ID：在 reflog 的输出流里，我一眼看到了那个可怕的 reset 之前的 commit hash。
3. 一键回血：然后执行 git reset --hard <那个之前的ID>。

几秒钟，代码世界重新恢复了和平。提交记录回来了，代码也回来了。

经验教训：怎么安全地用 AI 管 Git？

这次经历给我上了一课，也给大伙儿总结几条防坑指南：

• 高危操作必须人工复核：涉及 reset、rebase、clean、push -f 这种指令时，千万不要点“自动执行”。哪怕 AI 信心满满，你也得先看一眼生成的命令。
• 大模型之间差异真的很大：从这次 Mimo 2.5 free 的“乱作为”和 Kimi 2.6 的“理智救援”来看，免费的午餐有时候真的很贵。在处理逻辑复杂的工程问题时，尽量选推理能力强、上下文窗口大的高阶模型。
• 学会 Git 救命指令：不管用不用 AI，git reflog 必须要会。这是 Git 世界的“后悔药”，只要你不嫌麻烦，基本都能从废墟里把数据刨出来。

最后，AI 确实能大幅提效，但咱们目前还是得坐稳驾驶座，手里握好方向盘，别让副驾驶的 AI 把车开沟里去了。大家如果也有类似的 AI 翻车经历，欢迎在评论区分享，让我们一起排排雷！