1973年，Unix诞生grep。2025年，AI编程工具Cursor的用户还在等它搜完代码库——15秒。
这不是怀旧，是规模碾压。Cursor的Enterprise客户活在巨型单体仓库里，ripgrep再快也得逐行啃。Agent每问一个问题，人类就得盯着转圈光标发呆。
Cursor团队算过账：Agent写代码时，正则搜索已成核心操作。语义索引能解决大部分事，但有些查询模型只能靠正则死磕。换句话说，1973年的技术债，2025年得还。
1993年的论文，被AI唤醒
索引加速正则匹配不是新想法。1993年，Zobel、Moffat和Sacks-Davis发过一篇论文，用n-gram（定长字符片段）建倒排索引，把正则表达式拆成树形结构去查。
三十二年过去，这篇论文被Cursor翻出来重做。传统IDE给"跳转到定义"建语法索引，Cursor给Agent的文本搜索建正则索引。技术路径没变，需求场景全换。
ripgrep的作者Andrew Gallant花了大量时间优化匹配速度，但有一个天花板躲不掉：必须打开每个文件。小项目无感，十万级文件的单体仓库里，这就是瓶颈。
Agent的搜索习惯，逼出工程妥协
Cursor观察到一个反直觉现象：Agent特别爱用grep。LSP标准化了语法导航，语义索引提升了理解能力，但Agent写代码时，第一反应仍是正则搜索。
可能是训练数据的烙印，也可能是正则的确定性让模型更安心。不管原因，工具必须适配用户行为，而不是反过来教育用户。
于是Cursor开始动手：把n-gram索引塞进生产环境，让正则查询先走索引过滤，再对少量候选文件做精确匹配。复杂度往上堆，用户等待往下压。
索引的代价是存储和构建时间，收益是查询时的数量级提速。Cursor没公布具体数字，但提到" routinely see rg invocations that take more than 15 seconds"—— routinely，例行公事般的15秒，现在被盯上了。
历史循环里的产品逻辑
技术史是个 Flat Circle（平环）。grep被ctags取代，ctags被IDE吞掉，IDE被LSP统一，LSP又被Agent绕过。每一代工具都以为终结了前代，最后发现前代的某些能力无法替代。
Cursor的选择是显式优化：不为优雅架构，为解决具体用户的具体卡顿。15秒在演示视频里看不见，在每天两百次搜索的工程师手里，是生产力税。
论文引用、工程实现、产品决策，三层事叠在一起。1993年的理论，2025年的单体仓库，中间隔着的是对"Agent到底怎么工作"的观察。
Cursor还没说新系统上线后的具体耗时。但一个猜得出来的问题是：当你的Agent能在0.3秒内搜完全库，它会不会变得更爱用grep了？
热门跟贴