从语义搜索到精确搜索：不是谁淘汰谁，而是任务开始分层

大家好，欢迎来到心眸AI笔记，我是jackli！今天是2026年9月26日，周六快乐。下面带来今日资讯。

懒人总结

1. Cursor 在 2025 年 11 月 6 日的官方博客里说，语义搜索能改善结果；给 Agent 配上语义搜索工具后，受测模型表现均有提升。
2. 到了 2026 年 7 月，Cursor 官方论坛的 Colin 确认，语义/embedding 索引正在逐步停用，检索更多转向基于 grep 的精确搜索。
3. 这并不等于“向量检索没用了”。变化的核心是：模型更强后，能靠多个搜索词、看目录、读文件，一轮轮缩小范围。
4. 代码排错常常需要精确线索，比如变量名、错误码、接口路径；grep 适合从名字入手，语义检索适合“意思相近但用词不同”的资料。
5. 更稳的做法是混合策略：语义找业务模块，grep 定位函数，读完整代码，再跑测试验证。已有方案先别删，拿真实问题对比正确率、成本和失败点。

一、八个月，两种口径：语义搜索被点赞，也被降级

文章把两份相隔约 8 个月的官方材料放在一起对照，味道就出来了。

2025 年 11 月 6 日，Cursor 官方博客公布过一组对照测试。结论很直接：语义搜索能改善结果。给 Agent 配上语义搜索工具后，受测模型表现均有提升。那时，语义检索是加分项。

2026 年 7 月，Cursor 官方论坛的 Colin 又确认：语义/embedding 索引正在逐步停用，当前模型会尝试多个搜索词，再看目录、读文件，继续缩小范围。检索路径，明显往 grep 这类精确搜索靠。

作者提醒得很克制：模型和工具变了，合适的检索组合也会变。用去年的测试证明“永远需要”，或者用今年的调整证明“彻底没用”，都走得太远。

先把三个概念摆清楚。

Harness，是让模型持续干活的配套机制。模型提出“我要查文件”，Harness 调用工具、接回结果，让模型继续判断；它还处理权限、历史信息和执行边界。

向量检索，是按意思找内容。用户问“怎么退出账号”，文档写“终止会话”，文字没对上，但意思接近。Embedding 把文本变成一串数字，检索系统据此寻找相似内容。

向量数据库，是存储和查询这些向量。它只是实现方式之一。PostgreSQL 加上 pgvector 也能做向量相似度搜索，不一定非要再部署一种数据库。

Anthropic 在 2025 年 9 月 29 日的材料里用图示拆过这一点：模型每次看什么，需要有人组织。左侧是单轮提示，右侧把文档、工具、记忆和历史筛选后交给模型，工具结果再进入下一轮。

二、登录 bug 示例：Agent 如何自己追线索

文章用一个假设的登录 bug 场景，演示 Agent 的按需搜索循环。注意，这是教学示例，不是产品实测。

问题是：用户登录明明成功了，为什么又跳回首页？

第一步，找一个入口。

grep 类工具可以理解成“在文件里查文字”。假设项目有 src 目录，Agent 用 ripgrep 搜索登录和跳转线索：

rg -n 'login|redirect|returnTo' src

意思是在源码里找这几个词，并带上行号。

第二步，读到具体字段，换更准的线索。

假设打开的函数里有这样一行：

const next = session.returnTo || "/";

现在问题具体了：returnTo 没有有效值时，会回到 /。接下来要查的是，它在哪里被写入、是否中途被清空，以及产品本来希望怎样跳转。

第三步，继续查，最后验证。

流程是：搜登录线索 → 读跳转函数 → 查 returnTo 的来源 → 核对预期 → 修改 → 运行测试。

找到那一行，只是提出了假设。测试通过、行为符合预期，才算完成排查。

关键变化发生在“下一步搜什么”的判断上。grep 负责找字，模型读完结果后负责调整方向。第一次没搜准，也有机会沿新线索继续找。

三、为什么 grep 又香了？

原因不神秘，至少有三层。

模型更会追线索了。

一个搜索词没命中，可以换词、看目录、读相邻函数。Cursor 7 月的解释强调的，就是当前模型与快速搜索工具的组合。模型不再只是被动等喂料，它开始自己找路。

代码经常需要精确对号。

returnTo、错误码、接口路径，都是明确线索。相似片段能帮忙找入口，真正排错还得追到变量、分支和调用位置。这时候，精确搜索比“相似但不确定”更可靠。

少维护一条同步链路。

代码向量索引通常要经历“发现文件—切分—计算向量—更新索引”。项目改动、分支切换，都要处理内容是否及时同步。搜索当前工作区，可以省去其中一些环节。

但别误会。grep 也可能使用索引。Cursor 的 Instant Grep 就维护本地文本索引。少用向量索引，不等于彻底不用索引。

成本也要算总账。

省下向量服务，不等于整个任务必然更便宜。多搜几轮，也会增加模型调用和等待时间。要比较的，是把任务做完的总成本，而不是某一层看起来省了多少。

四、你的项目要不要跟着删数据库？

作者的判断逻辑很实用：按线索选工具，别按热词选架构。

已有名字、路径或报错，从精确搜索开始。只有大致意思、资料用词差别很大，可以尝试语义检索。两条路都要核对原文。

举个例子。想找“换平台后旧数据会不会丢”，客服记录写的是“历史订单能否迁移”。这类表达变化多的资料，仍然是语义检索值得发挥作用的地方。

更稳的策略是混合：

语义检索找业务模块 → 精确搜索定位函数 → 读完整代码 → 验证。

如果已有能工作的方案，先留着。建议挑一组真实问题，在相同模型和代码版本下对比三项：

下一次 Agent 漏掉你明明写过的代码，就把问题、正确文件和搜索过程留下来。先找到它到底卡在哪，再决定删哪一层。

相关工具与官网入口可查：

• Cursor 官网：https://cursor.com/
• Cursor 官方论坛：https://forum.cursor.com/
• pgvector：https://github.com/pgvector/pgvector
• ripgrep：https://github.com/BurntSushi/ripgrep
• Anthropic 官网：https://www.anthropic.com/

文章核对日期为 2026 年 9 月 24 日。登录代码为教学示例，选型部分为建议。

写在最后

这波变化，更像换挡，不是退档。

向量检索没有死，grep 也不是万能。真正该问的是：在当前模型、当前任务、当前成本结构下，哪种检索能更快把问题收窄？如果模型已经会追线索，就给它更锋利的精确工具；如果资料里满是同义表达，就别把语义检索一刀切掉。

我的看法是，别因为一篇官方调整就清空基础设施，也别因为一次对照测试就拒绝新组合。拿真实问题跑一遍，记录正确率、耗时和失败点。工具会变，任务会变，检索策略也该跟着变。

如果这篇内容对你有帮助，欢迎点个赞、转发给需要的朋友，再点一下“在看”。要是方便，也顺手给心眸AI笔记加个星标⭐️，下次更新文章你就能第一时间见到。谢谢你读到这里，我们下篇再见。