AI Coding工具搜文件为啥这么快?答案你可能猜不到

Claude Code、Codex这些AI工具,在项目里搜代码,几乎是秒出结果,是不是有什么黑科技?

其实没有。

它们用的是一个很朴素的命令行工具——

ripgrep(rg)

而它快的秘密,就四个字:

顺序读盘。

不是AI聪明,是工具够狠

先记住一句话:

AI负责判断,ripgrep负责干活。

就像聪明的项目经理,不会自己搬砖,他会找最能搬砖的人。

顺序读,才是真正的杀手锏

很多人一看”没索引”,第一反应是:

那肯定慢啊

这里有个特别大的误解。

数据库、向量库之所以要建索引,是因为它们要做随机查找——

这条记录在哪?那条记录在哪?

磁盘最怕的就是随机读。

而ripgrep做的事完全不一样:

从头读到尾,边读边匹配

这叫顺序读。

顺序读有多快?举个直观的数:

SSD 随机读:几万 IOPS

SSD 顺序读:3000~7000 MB/s

差了两个数量级。

更狠的是,操作系统还会提前帮你预读——你读第1MB的时候,第2MB已经在内存里等着了。

所以一个5GB的代码库,真正扫起来:

几秒钟的事

ripgrep快,不是快在算法,是快在它顺着硬件的脾气做事。

索引?不需要。缓存?不需要。

读 → 匹配 → 输出,一条直线走到底。

再叠三个buff,起飞

光顺序读还不够,ripgrep又叠了三层优化:

第一层:自动跳过垃圾目录

默认读.gitignore,直接略过:

node_modules

dist

.cache

这些通常占项目80%以上。

它扫的根本不是整个项目,而是你真正在乎的那一小块。

第二层:多文件并行

16核 → 16个文件同时读

每个文件内部是顺序读,文件之间是并行读——把SSD和CPU同时榨干。

第三层:只啃纯文本

.py.md.json 直接上。

.docx.pdf 得先解析,再喂给ripgrep。

为啥Markdown特别吃香?

因为它本质就是文本。

ripgrep眼里就是一长串字符,顺着读下去就完事了。

AI还能顺手按标题切块,返回的不是”第42行”,而是:

第3章 > 登录流程

人看着更舒服。

代码里咋调?

就一行系统命令的事:

subprocess.run([“rg”, “UserService”])

Java也一样,ProcessBuilder包一下。

重点不是代码,是思路:

ripgrep是系统工具,不是类库。跟git、docker一个路数。

为啥AI Coding都选它?

四个字:

快、稳、轻、广

关键是——不用维护索引。

代码天天改,索引天天更新,反而是负担。

而顺序扫一遍?

每次都是最新的,永远不会过时。

最后

很多人看到”秒级返回”,下意识就去想”肯定有复杂索引”。

但真相反过来:

ripgrep快,恰恰是因为它啥都没建,就老老实实顺着磁盘一路读过去。

这背后有个特别朴素的工程哲学:

别跟硬件较劲。顺着它的脾气来,它就给你最快的速度。