clone 一个 monorepo 花了四十分钟。CI 跑一次够吃完饭再回来。Git 没变慢——是它底层那个前提不成立了。
Git 2005 年诞生时做了一条隐含假设：代码由人一行行敲，仓库变更速度可预测。它的数据模型是"存差异"——每次 commit 算新旧文件差值，只存那个 delta。git log 因此天然成立：每次 commit 就是一个 diff，你看到的是"变化本身"。
AI 代码生成把两个变量打爆了。commit 频率：agentic coding 一小时内能产生数百个 commit——AI 把"试着改→跑测试→回滚→再试"压到秒级。单 commit 文件量：一次 commit 新写五十个、改三十个、删十个。每个 commit 是"一堆完整文件快照"，不再是人手"几行 diff"。
delta compression 在这两种负载下崩得很直接。每个 commit 都要对成百上千文件算差值——这个开销跟文件数量正相关，被 AI 拉到了人类工作量的十倍以上。Git 没做错任何事：它只是被塞进一个没被设计去处理的输入密度。
然后是二进制。Git 用 LFS 外挂大文件。但 AI 生成内容里，大文件不一定是资产——可以是模型权重、训练数据切片。LFS 的"手动标记文件类型"策略，在内容由 agent 批量产生的场景完全失效——你不知道下一个被 commit 的是什么。
Epic Games 这周把 Lore 全面开源（MIT）。底层数据模型做了根本性切换：从"存差异"变成"存内容本身"。
Git 原语是 blob（文件哈希）+ tree（目录）+ commit（指向前一个）。Lore 是 Merkle 树节点 + 不可变 revision 链——每个 revision 是 320 字节固定片段，包含自身哈希、父 revision 哈希、数据哈希。相同内容永远哈希到相同地址，跨分支跨历史自动复用。分支创建零数据复制。
大文件底层原生：FastCDC 内容定义分块，一个文件切成可变大小 chunk，独立哈希。改 2GB 文件的一个字节，只重传那个 chunk。按需 hydration 是默认：workspace 永远只拉当前工作集。
但有一个反直觉取舍：Lore 是集中式架构。读操作完全离线，但 push 和 clone 需要 running server。它瞄准的不是 Git 去中心替代——是共享一个 central truth、本地操作不依赖网络的另一类场景。
可以直接略过的人：仓库文件 < 10 万、无 > 100MB 单文件、commit 正常（日 < 50）。Git 在你场景下仍最优——二十年代价不是换个模型就能抹平。
可以关注的人：团队在用 agentic coding、每天自动生成数百 commit、monorepo clone 已成日常抱怨。你的瓶颈在于 delta 模型被 commit 密度压到了不匹配区——跟 Git 快慢无关。
应该直接评估的人：游戏/影视/3D 团队、需版本管理大二进制。这是 Lore 第一目标场景——Epic 自己就在这个坑里。Git LFS 在你这种规模撑不住。
一个更简单的判断：如果仓库让 Git 表现得"慢"，说明设计假设已经失效了——不关 bug 的事。打补丁能撑一阵，从数据模型切 content-addressed 是迟早的事。
Git 没错。只是代码不再是人写的了。
