别等被AI背刺了才想起Git

2026-05-12 GitAIAgentHermesOpenClaw备份VPS产品经理

封面：别等被AI背刺了才想起Git

今天中午，我在给Hermes接语雀的MCP服务。

过程其实很简单。语雀有个官方API，通过MCP协议可以把知识库内容直接拉进来。我需要做的就是配一个代理，让服务器能连上语雀的API就行。按理说十几分钟应该搞定的。

但遇到了一个奇怪的问题——服务器直连语雀API老是超时。第一次我以为网络波动，多试了几次，全部超时。查了一下，应该是阿里云WAF把TLS握手给拦了，语雀的服务器在日本，走国内直连容易被阻断。

然后我做了一个决定。这个决定让我在接下来一个小时里，差点以为这台VPS废了。

一个决定，全网封杀

我的方案很简单——装个类似VPN的东西绕过去。装完语雀通了，我还挺高兴。

大概过了十分钟，想连服务器做点别的——SSH连不上了。

退出重连不行，等两分钟再试还是不行。ping timeout，换手机热点也timeout。

半小时前还能正常连接的服务器，装上工具之后突然像死了一样。是宕机了？IP被封了？还是我装的东西搞坏了什么？

控制面板显示"在线"，系统正常在跑——网络层面被切断了。但知道问题是网络问题和知道怎么修是两回事，我连SSH都进不去，VNC也连不上。

脑子里就一个想法：完了。

一台每天都在用的VPS，上面跑了博客、AI服务、各种工具，突然连门都进不去了。只记得装了一个工具，完全不记得改过什么网络配置。

更难受的是，装这个工具之前，我没有备份任何配置文件。

后来我是怎么恢复的呢？

借着还在线的Hermes对话通道，我让它翻了翻执行记录——之前装WARP时，它帮我写了一组网络策略，把流量端口和相关规则全干掉了，但Agent自己的通讯端口恰好没被拦，所以还能说话。知道问题出在哪就好办了，让它直接清掉拦截规则，SSH就恢复了。

整个过程从发现到修复花了大概一小时。但如果没有Hermes这个还能对话的通道，我连问题出在哪都不知道，只能干等工单回复——那可能就不是一小时，而是一天甚至更久。

如果当时有Git

事后回想这件事，真正让我不舒服的不是工具本身有问题——工具出bug很正常。我不舒服的是另一个事实：这台服务器上跑的所有东西，改之前没有任何版本管理。 我不知道原来配置长什么样，不记得装过什么依赖、改过什么参数。

如果当时有Git，事情会完全不一样。

对比：有Git vs 没有Git

场景	没有Git	有Git
发现问题后第一时间	凭记忆回想改了啥，大脑一片空白	`git diff` 立即看到所有变更
尝试恢复	手动一点点改回去，可能漏掉关键参数	`git checkout` 一键回退到上一版本
心态	慌了，不知道问题范围到底多大	冷静，因为知道不管出什么事都能回退
排查过程	全靠猜+试错，运气成分很大	看diff，精确到每个字符的差异
恢复时间	1小时+	可能5分钟就搞定了
回退成本	高，改错了要继续修复	极低，一个命令回到原点

这个表格不是我瞎编的。因为就在同一天，同样的事在另一个目录下发生了——结果完全不一样。

其实今天还被背刺了第二次

解决完网络问题之后，我继续折腾服务器，顺便调了一下博客首页样式——改导航顺序、换按钮文案、把头像换成真logo、加二维码hover。全是小改动对吧？但同样因为没有Git，这些小改动让我又想骂人。

我让AI改了一版——布局不对。又改一版——颜色间距也不对。想让AI回到第一次改的样子，但它已经不记得了。就这样反复拉扯了三轮，其中有一段CSS连它自己都分不清是刚改的还是本来就这样。最后我不得不把文件逐行看了一遍。

没有Git的时候，你连改错了一个数值都不敢确定原来的值是多少。

更让人烦躁的不是改样式本身，是情绪成本。几次之后你已经在跟自己较劲——"我就不信改不回来"。比写代码累多了。而就在几小时前，我刚给另一个项目目录做过Git提交——顺手到完全没意识到博客目录根本没配Git。

这两个目录在同一台服务器上，路径差了几个文件夹。一个配了Git怎么改都不怕，一个没配Git调几个按钮都提心吊胆。

这两件事之间的差距，就是一个git init。

你可能觉得我小题大做。但这两个场景的区别本质不是技术问题，是心态问题。有Git的时候你改东西有底气，敢试。没有Git的时候，你连按delete键之前都会犹豫一下。

你需要这个习惯吗？

坦白说，踩这个坑的不止我一个。AI工具——不管是智能体还是AI IDE——都会在你的项目里改你不知道的文件。像Hermes，一次对话可能产生415个文件、一万多行代码的变更。没Git的话出了bug我根本没法排查。

再说说AI IDE。你跟Codex说「把这个模块重构一下」，它可能顺手改了十几个文件。跟Antigravity说跑一次多智能体协作，好几个Agent同时改你的项目——没有Git你敢让它跑？

问题是你不知道它具体改了哪些地方。diff视图给你一个摘要，但你没精力逐行检查。最要命的是：AI IDE会改你「看不见」的代码——顺手改一下vite.config.ts加个插件、动一下tailwind配置改个颜色变量。这些都在你的注意力盲区里。出问题了——比如打包流程崩了——你根本不知道从哪查起。

而有Git的话，让AI动手之前commit一次，动完之后git diff一眼就知道动了哪些文件。过了一周回头查，git log也能锁定是哪个版本出的问题。

这时候你想回到最初的版本——"之前那个版本长什么样来着？"——对不起，找不到了。

我不是在说这些工具不好用——Hermes、Codex、Cursor我都在用，效率提升很明显。但正因为它们太快了，你才更需要一个安全网。

AI工具就是跑车，Git就是安全带。

AI用户的Git三步法


flowchart TD
    A["S1: 建立仓库<br/>(git init)"]
    B["AI 修改代码"]
    C["你 Review"]
    D{"OK?"}
    E["S3: add → commit → push"]
    F["Git 仓库 = 每次操作的<br/>「存档点」"]

    A --> B
    B --> C
    C --> D
    D -- "YES" --> E
    D -- "NO" --> B
    E --> F

我知道很多人听到"用Git"就开始头疼。包括我在内，一开始也觉得学习曲线太陡。不过你先别急着走——我不是要你学分支管理、rebase、远程协作。就三个操作，够你用了。

第一步：开始之前，Git init

在任何一个目录，你准备让AI动手之前，先做：

git init
git add -A
git commit -m "before: 开始之前的状态"

这三行命令加在一起不会超过30秒。但它给你的东西是——一张安全网。

第二步：配一个简单的.gitignore

如果不配，可能会把AI对话记录、临时文件也加进去。给你看看我自己的：

类型	不追踪的原因
`sessions/`	AI对话记录，每天几十个
`cache/`	临时缓存
`*.log`	日志文件，每秒钟都在增长
`node_modules/`	依赖包，能重新装
`*.db`	本地数据库，机器生成不宜进版本库

第三步：让AI动完就commit

AI执行完任务之后，跑一下：

git add -A
git commit -m "after: 接入了某个功能"

commit message随便写，能让自己看懂就行。核心是养成肌肉记忆。

你只需要记住一个原则：

让AI动手之前commit一次，让AI动完之后再commit一次。

这就够了。其他所有Git的功能——分支、合并——都是锦上添花。

一个不用手动操作的技巧

再加个定时任务，每天凌晨自动commit一次，忙起来忘了也有保底：

0 2 * * * cd /你的项目目录 && git add -A && git commit -m "auto backup $(date +%Y-%m-%d)" 2>/dev/null || true

这一行加到crontab里就行。没有文件变更就不会创建空commit，历史记录不会太多。

说实话，一开始我也觉得设cron有点过了。但后来发现，最有价值的备份往往是在你还没意识到它有用的时候做的。

第四步（可选）：推到远程仓库

本地commit能让你恢复误改，但VPS重装系统的话本地历史也保不住。硬盘挂了、系统崩溃了、或者单纯想迁移——没有远程备份，commit记录和文件一起消失。

解决办法很简单：把代码推到GitHub。先去建一个空仓库（不要点"初始化README"），然后在项目目录里跑：

git remote add origin https://github.com/你的用户名/你的仓库名.git
git push -u origin main

第一次推完之后，以后每次commit完加一句 git push 就行。也可以加到同一个cron里：

0 2 * * * cd /你的项目目录 && git add -A && git commit -m "auto backup $(date +%Y-%m-%d)" && git push 2>/dev/null || true

多了个git push，但意义完全不同——备份不在本地硬盘上，在GitHub的服务器上。VPS就算被人格式化了，新装一台机器git clone回来，配置和commit历史全在。前提是你先配好GitHub的SSH密钥。

不过说实话，我自己的几个目录也没全配远程推送。但我很清楚：本地commit保的是操作失误，远程推送保的是机器没了。

我记得以前做过一个WMS项目，上线前老板问我：你觉得自己系统最大的风险是什么？我说是数据没有冗余。他说不对，是你没想到的风险才是最大的风险——因为你想到的，你一定会预防。

Git备份也是一回事。当你意识到"这个目录需要git"的时候，你已经踩到某种翻车的边缘了。真正的预防，是在你还没想到需要它的时候，就先把它做了。

今天之前，我也觉得"就改个样式而已，不需要git"。

今天之后，我再也不敢这么想了。

说在最后

坦白说，这两次都不是什么严重的灾难——没有数据丢失，没有业务中断。但我真正在意的不是"有没有出事"，而是出事的时候我没有退路。

没有Git，出问题只能硬扛——靠记忆、靠试错、靠手动恢复。这些方式在简单场景还能应付，但一旦问题复杂起来——像WARP那次，连门都进不去了——你就基本没牌可打了。

Git备份解决的不是「会不会出错」的问题——工具总会出问题。Git解决的是「出错了怎么办」的问题。它给你一张安全网，让你敢犯错、敢试——因为你知道能回来。

如果你在用AI工具——不管Hermes、Codex、Cursor还是Antigravity——我想跟你说：不用等出了问题再想起来学。