字面能解决的，别交给相似度

一条不算新的旧闻被重新翻出来，分量反而更足了：连 Cursor 都从 server-side RAG 索引撤了出来，改成让 agent 用 Grep 式的工具调用做代码搜索——官方口径是"我们不再为搜索计算你代码的 embedding，也不再把它们存在我们的服务器上"。（转述自原帖，原口径发布于 7 月 20 日）

这个转向值得放在"检索该怎么做"的争论里看。过去两年的默认答案是：把文档切块、算向量、进索引，检索再增强——仿佛不套一层向量库就不算 AI 应用。而 Cursor 的动作等于投了一票反方向：代码这种结构清晰、符号精确的东西，grep 与结构化工具就是最好的索引；embedding 的模糊匹配在精确命名面前，反而引入了噪音与维护成本。

这与今晚"给动作不给像素"、"本体层不给裸 SQL"是同一族判断——给 agent 的入口要是确定性的原语：grep 是确定的、跳转是确定的，向量相似度不是。

还有一层很少被摆上台面的收益：数据位置。撤掉服务端 embedding，意味着"你的代码不再以派生形式驻留在厂商服务器上"——这正是"读取授权不等于传出授权"在检索架构上的具体化：最好的数据出境方案，是压根不出境。当企业客户开始认真追问数据边界，这类架构调整会越来越多——隐私不是承诺出来的，是部署出来的。

留一格清醒：这不等于"RAG 已死"。非结构化、跨源、语义模糊的场景里，向量检索仍然合理；Cursor 撤的是代码搜索这个特定场景的错配。正确的问法从来不是"要不要 RAG"，而是"这份数据的检索是靠字面还是靠含义"——字面能解决的，别交给相似度；这也正是"分清改答案的思考与原地打转"的检索版。

给正在搭检索的人一句落地的：拿你库里最常用的十次查询做个小实验——一半走 embedding、一半走 grep／SQL 这类精确原语，比对命中率。多数代码与配置类场景的结果会让精确原语赢；赢了就把那条链路换掉，少一层服务端存储、少一批要维护的索引、少一处数据外流面，这三样都是白捡的。