Cursor 绕过了 Git 在大规模下的限制

Cursor，这款AI代码编辑器，为了在非常大的代码库上正常运行，不得不解决Git的真实可扩展性问题。以下是他们所做的——以及为什么这对每一位高级开发者都很重要。

具体案例

想象一个拥有数百万行代码的代码库——这种规模常见于大型科技集团、成熟的开源项目或快速成长的创业公司的单体仓库。Git 开始变得举步维艰：git status 需要几秒钟，常规操作变得让人沮丧。现在再加上一个 AI 工具（如 Cursor），它需要实时理解仓库状态以提供上下文建议。问题变得至关重要。

Cursor 正面临这一挑战——而 The Register 详细介绍了他们如何突破 Git 可扩展性的限制。

根本问题：Git 并非为 AI 而设计

Git 由 Linus Torvalds 于 2005 年设计，用于管理 Linux 内核——一个规模庞大但使用模式以人类为中心的代码库：开发者提交、分支、合并。Git 并未考虑 AI 工具每分钟读取仓库状态数十次甚至数百次以实时提供建议的需求。

已知的瓶颈包括：

• Git 索引：.git/index 文件在每次状态操作时被完全重新读取，即使只有一个文件被修改。
• 对象存储：通过哈希获取对象的操作未针对大规模重复读取进行优化。
• 文件系统钩子：在 Windows 和 macOS 上，文件系统监听器会增加延迟。

Cursor 的解决方案：S3 作为真实数据源，NVMe 本地缓存降低延迟

据 The Register 披露，Cursor 的架构采用双层设计：S3（云对象存储）作为代码库的真实数据源，而本地 NVMe（高性能 SSD）仓库则用于对延迟敏感的操作。

具体而言，Cursor 并非让 AI 直接在本地 Git 仓库上运行（受限于可扩展性），而是维护 S3 中的规范副本，并使用本地 NVMe 缓存进行需要快速响应的操作。两层之间的同步经过优化，以最大限度减少对 Git 索引的完整读取。

这是资深开发者耳熟能详的问题：标准抽象在某个节点前运行良好，但之后就需要深入底层——在这里，即重新思考存储模型，而非仅对 git 调用进行边际优化。

为什么这对每个人都有意义

Cursor 的解决方案超越了其工具本身的影响：

• 单体仓库：任何在大规模单体仓库上工作的团队都会遇到这些问题。S3 + 本地 NVMe 的架构可以复制。
• Git LFS：解决了大型二进制文件的问题，但未解决索引的可扩展性。这是 Cursor 通过其他方式绕过的一个未解难题。
• 基于代码库的 AI 工具：所有静态分析工具、辅助代码审查或代码生成工具在成长过程中都会遇到这一问题。