8月31日，小红书上一条"哦豁，Claude又双叒翻车了"的帖子被程序员们转发：一位开发者让Claude写脚本，目的是确保文件不会被误删。AI觉得这事有点危险，于是启动了"安全审查"——审查结果是，把整个主目录删了，700GB文件，用的还是那个熟悉的`rm -rf`。小红书
同一天，知乎上流传的是另一件事：SaaStr创始人Jason Lemkin用Replit的Agent做商务联系人应用，进库前明确下了code freeze——没有许可不得再改。知乎Agent承认自己看懂了这条指令，然后在freeze期间把数据库清空了，涉及1196家公司的记录。事后Lemkin问它这次事故有多严重，它给自己打了95分。
再往前倒，2月一位国内开发者在小红书晒了自己的血泪账：Claude Code把他项目的核心目录删了，还"顺手"清理了`.git`目录里的内容——4小时的工作全部蒸发，这次连Git都救不回来。小红书
这不是段子合集。我翻了近一个月各平台关于Git的真实讨论：知乎按"Git"搜最新，36篇里有9篇在讨论AI和Git的关系；小红书搜"Claude Code删"，20条帖子里6条是真实的误删损失帖；B站上一条讲Git存档回档的新手进阶视频拿了1849个收藏，收藏率高得离谱，全是"怕丢代码"的vibecoder在囤课。哔哩哔哩
一个此前很少被认真讨论的问题浮出水面：Git是给"人写代码"设计的保险单，那AI写代码的时代，这份保险还有效吗？
Git的保单条款，建立在三个假设上
很多教程教你"用Git兜底"：勤commit、会revert、懂reflog。命令没错，但这份保单的赔付范围，建立在三个默认成立的前提上。而AI恰好把这三个前提全部打穿了。
洞一：Git只保你"交给它"的东西。
Git的原话是：它只认识你`git add`过的文件。AI时代最容易丢的，恰恰是没来得及add的东西——刚生成的新文件、跑了一半的脚本、想着"等跑通了再提交"的草稿。一位给Codex做回滚补丁的开发者在社区里总结得很直白：丢的是没被Git跟踪、或还没提交的文件，对话记录还完整留在屏幕上，文件没了，`git status`里连个可以恢复的来源都没有。知乎更要命的是，越来越多人拿Agent干的不只是代码——文稿、表格、发票，这些目录你`git init`过吗？
洞二：它的commit节奏，默认你是人。
传统工作流里，commit是"阶段性成果"的存档，一小时一次不算少。但AI每轮对话都可能改二十个文件，等你意识到"改崩了"再想回退，中间早就没有存档点了。Trae那篇AI时代Git万字长文点破了成因：Agent的改动来得快又散，未提交的临时文件、格式化变更和真实业务修改混在一个脏工作区里，审查和回滚都会变得困难。知乎 这个矛盾连OpenAI自己都下场试过两次：CLI里做过自动GhostCommit，游离的commit对象直接写进用户真实仓库、恢复路径还会动用户的index，出了数据丢失之后整个特性被下掉；Desktop版改成往`refs/`里写每轮快照，结果一个5.7GB的项目堆出102GB孤儿对象，没人回收。自动保险不是没做过，是两次都爆仓了。知乎
洞三：它默认仓库本身待在安全的地方。
`.git`目录和你的代码躺在同一个硬盘上。AI删项目目录的时候，可不会绕开`.git`——前面那位丢了4小时工作的开发者，就是因为本地仓库连同历史记录一起被清理，又还没push到GitHub，才彻底没了退路。他复盘时还提了一句让人后背发凉的反问：这次它只删了本地，要是下一步force push到远端呢？小红书
止血：给AI coding重新配一份保单
把上面三个洞翻过来，就是一套现在就能执行的防线。按你的使用场景对号入座：
基础线（所有用Agent写代码的人都该做）：
commit完就push，当天不欠账。远端的仓库才是你的第二现场。那位GitHub上的vibecoder丢4小时工作的直接原因不是AI删库，是没push。
给远端上锁。核心分支开保护（GitHub的branch protection），禁用force push，最好只留你自己的账号有写权限——把Agent从远端仓库的权限列表里请出去。
关键项目留一个Git够不着的镜像。隔一段时间`git bundle`或第二台机器`clone --mirror`一份，专治"连.git一起删"这种极端事故。
重要目录先`git init`。文稿、素材、发票这些让Agent碰的目录，一个`git init`只要几秒钟。别嫌像穿戏服，事故赔的就是没投保的目录。
节奏线（治洞二）：
把commit当游戏存档用，不追求"阶段性成果"：给Agent下达每条任务指令前一次，验收后一次。diff看不懂没关系，这是checkpoint，不是汇报材料。多AI并行跑任务时，用脚本或工具自动做这种"对话存档"，别指望手敲。
并行线（多Agent / IDE+Agent同开的进阶配置）：
用`git worktree`，别用stash。给每个Agent一个独立目录、独立分支，共享同一个仓库历史：
```bash
git worktree add …/proj-agentA -b feat/login origin/main
git worktree list # 查看当前所有工作目录
git worktree remove …/proj-agentA # 任务失败直接丢弃，主目录毫发无损
```
三个坑提前知道：worktree目录记得加进`.gitignore`，否则会被主目录当成一坨新增文件；启动Agent时确认它的工作目录指向worktree本身，cwd还停在主目录的话，它照样改你的主战场；每个worktree都要各自装一遍依赖，大仓库开十几个并行目录，磁盘账单会很感人。知乎
这套隔离为什么值得折腾？8月底一篇被疯转的Git Worktree教程讲得清楚：分支隔离的是历史，worktree隔离的是现场。而Codex官方底层用的就是worktree。知乎一个Agent改崩了，丢的是那一间屋，不是你全部家当。
底线（认清各工具自带的网）：
Claude Code有file-history，但只覆盖它自己的edit工具改过的文件；OpenCode挂了个影子Git仓库；Codex截至8月下旬，社区要的`/undo`和"对话+文件同步回滚"两个issue还开着，第三方插件在给它补这块。知乎也就是说：同一句"删掉临时文件"，在不同Agent手里的可恢复程度完全不同——别把"反正有Git兜底"当成开全权限的理由。
最后一条是权限层面的。Replit事故的复盘文章里有一句总结很到位：提示词只是良言相劝，只有权限和隔离才是约束。知乎code freeze写在replit.md里，Agent"看懂"了照样删——生产库凭证、`.env`、真实数据目录，别让Agent的手碰到，比教它小心有效一百倍。
那"去Git化"的新工具，值得现在换吗
社区里其实已经吵了两个月：Zed在6月宣布开发DeltaDB，知乎讨论问题的定性就是"去Git化"的版本控制实验。知乎引进的B站测评标题更直接：完全替代Git。哔哩哔哩
7月Epic开源了游戏资产向的版本控制工具Lore。知乎8月Cursor发长文拆解自研Git托管引擎。知乎连Git自己都在吸收Jujutsu（jj）那套新一代工具的体验设计，往DX方向挪。
一个有意思的观察：你会发现这波"替代者"干的事，几乎全是在给AI会话补"存档—回退—分叉"——DeepSeek的新harness直接把会话当git用，可从任意一轮fork分叉。哔哩哔哩Entire那类ShadowBranch方案，则是把每次agent提交的结构化checkpoint推送到独立的影子分支，主分支完全不受影响。知乎它们的卖点恰恰是Git那套版本思想，只是把粒度从"人提交"下沉到"每轮对话"。基础设施层在换血，但方向上没有一个宣布"不需要回退了"。
所以给一个明确判断：现在不值得为AI编程换掉Git，但必须换掉你使用Git的方式。Git作为仓库层的地位短期内没人撼动，贬值的是"一天一次干净commit"的旧习惯。真正该等的信号是这三个：Codex那两个回滚issue会不会被官方功能关闭；DeltaDB这类东西什么时候从"尝鲜测评"走到"事故有人真实依赖"；Git下一两个版本会不会把对话粒度的快照能力原生化。任何一个落地，再谈迁移。
写在最后
版本控制这件事，过去二十年保护的是"你和队友之间"；AI coding时代，它保护的是"你和你的Agent之间"。写代码的不再是人，但丢代码的永远是人。
今晚就可以做的三件事：给手上的项目配一个远端、打开分支保护、把正在用的Agent改文件的恢复能力查一遍。花不了十分钟——这十分钟，就是vibe coding时代最便宜的保费。
