个人开发学习资料库

Appearance

《AI 大模型实现代码精准查找的秘密》 ​

更新: 6/21/2026 字数: 0 字 时长: 0 分钟

面向前端开发者与全栈工程师的学习文档。目标:讲清楚 AI 编码工具到底怎么在百万行代码里找到那一段你需要的代码。目前主流是两条路线——Code Indexing(代码索引)和 No Code Indexing(免索引/代理式搜索),它们的取舍很值得搞明白。

一、技术背景:为什么"找代码"是个硬问题 ​

大模型有个绕不开的硬约束:上下文窗口有限。哪怕是支持几十万 token 的模型,也塞不下一个中大型项目的全部代码。一个普通的前端工程,node_modules 之外的源码动辄几万行,企业级单体仓库更是几十上百万行。模型不可能"读完整个项目再回答你",它每次只能看到被喂进去的那一小部分。

于是真正的问题变成了:在你提问的瞬间,怎么从海量代码里挑出最相关的那几段,塞进有限的上下文里。这一步选得准不准,直接决定了 AI 是改对了文件还是改错了文件。有数据显示,编码 Agent 60% 以上的时间都花在"搜索上下文"上,搜索质量直接决定 Agent 成败[1]。

这件事和传统的全文检索还不一样。你搜 "用户登录",代码里相关的函数可能叫 authenticate、signIn、validateCredentials,一个 "登录" 的字面关键词都没有。这就是代码检索的核心难点:语义相关 ≠ 字面相同。两条技术路线,本质上就是对这个难点给出了两种不同的解法。

AI 代码查找的挑战与两条技术路线分叉

二、核心实现原理 ​

路线一:Code Indexing(代码索引 / 语义检索) ​

这条路线的思路是"先建库,后查询",本质是把 RAG(检索增强生成)用在代码上。流程分四步:

  1. 分块(Chunking):把源文件按语法结构切成一个个语义片段,通常一个函数、一个类是一个 chunk,而不是粗暴地按行数切。
  2. 嵌入(Embedding):把每个 chunk 送进 embedding 模型,转成一个高维向量。语义相近的代码,向量在空间里也彼此靠近。
  3. 存储:把这些向量连同元数据(文件路径、起止行号)存进向量数据库。Cursor 用的就是远程向量库 turbopuffer[2]。
  4. 检索:你提问时,系统把问题也算成一个向量,在向量库里做最近邻搜索(nearest neighbor),返回最相似的几个 chunk 的文件路径和行号,客户端再本地读出这些代码片段[3]。

这样做的好处是查询快、能跨越字面差异找到语义相关代码。前面 "用户登录" 找到 authenticate 的问题,语义检索能解决——因为它比的是含义,不是字符。据称语义检索相比纯关键词检索,代码召回准确率有约 12.5% 的提升[4]。

但它有个根本局限:embedding 存的是"相似度",不是"关系"。索引里没有解析出的边,所以它没法告诉你"谁调用了这个函数""谁实现了这个接口""改了这个签名会牵连到哪些地方"[2]。它还会出现切块切歪的问题——一个函数被切成两半,检索只命中了上半段,返回给你半个函数。

Code Indexing 代码索引的分块-嵌入-检索流水线

路线二:No Code Indexing(免索引 / 代理式搜索) ​

这条路线干脆不预先建库,而是让模型像一个人类工程师那样,临场用工具去翻代码。这叫代理式搜索(Agentic Search):模型自主规划并执行多步搜索,用的工具就是 grep、ripgrep、文件读取、列目录这些[1]。

它的工作方式是一个迭代循环:搜一下 → 读结果 → 根据读到的东西决定下一步搜什么 → 再搜 → 直到攒够上下文才停。和一次性返回文档的语义检索不同,代理式搜索是多步推理、边搜边想。关键在于,它跟着代码的逻辑结构走,而不是跟着向量相似度走。这也是 Claude Code 完全不用 embedding 的原因——Anthropic 给自己的 Agent 选了 grep 而非向量检索[1]。Claude Code 早期试过用本地向量库做 RAG,后来转向了纯代理式搜索[5]。

为什么对代码这条路走得通?因为代码是高度结构化、可被 grep 精确搜索的数据;而商业文档这类非结构化数据则不是,这正是两边争论时其实在说不同问题的根源[6]。代理式搜索的几个天然优势:不用维护索引、不会因为代码变更而索引过期、读到的永远是当前磁盘上的真实代码、且天然尊重文件权限。

代价也很实在:它要烧更多 token,因为每一轮搜索-读取-推理都在消耗上下文,有人就批评 Claude Code 的纯 grep 检索"太费 token"[7]。而且在超大规模文件系统上,grep 的扫描速度也会成为瓶颈。

No Code Indexing 代理式搜索的多步迭代循环

三、工业落地案例 ​

两条路线在头部产品里都有清晰的代表,放在一起看最能理解取舍。

Cursor —— Code Indexing 的标杆。打开项目时,Cursor 扫描文件夹、把代码分块,计算一棵 Merkle 树(每个文件一个加密哈希,每个文件夹的哈希由其子节点哈希算出),再把这棵树同步到服务端,生成 embedding 存进向量库[8]。推理时算出 query 的 embedding,让 turbopuffer 做最近邻搜索,把混淆过的文件路径和行号传回客户端,本地读取对应代码块[3]。

Claude Code —— No Code Indexing 的标杆。Claude Code、Gemini CLI、Devin 这些 2025–2026 真正在写和调真实代码的 Agent,都不为理解代码库而启动向量数据库,而是依赖 grep、find 和直接读文件[9]。一位 Claude 工程师在 Hacker News 上公开承认 Claude Code 根本不用 RAG。它的检索路径优化的是实时、精确、且感知权限的搜索[10]。

值得注意的是,两条路线并非你死我活。社区里有像 Claude Context 这样的开源 MCP 插件,专门给 Claude Code、Gemini CLI、Cline 乃至 Cursor 补上语义代码搜索能力[7]。混合用法正在成为新趋势。

Cursor 与 Claude Code 两大工业落地案例对比

四、性能优化方法 ​

两条路线各有各的优化重点,理解这些能帮你判断什么场景该选什么。

Code Indexing 这边,核心是解决"索引过期"和"重复计算"。代码天天在改,如果每次小改动都全量重建索引,成本不可接受。Cursor 用 Merkle 树解决这个问题:客户端编辑只会改变被编辑文件自身的哈希,以及它到根目录路径上的父目录哈希[8]。这样比对新旧两棵树的哈希差异,就能精确定位哪些 chunk 真正变了、只重新 embedding 这部分[11]。新用户加入同一个代码库时,客户端还会从 Merkle 树派生一个 simhash 作为内容摘要,从而复用已有索引、快速拿到首次查询结果[8]。优化方向还包括:更贴合语法的分块策略(避免切碎函数)、对召回结果做重排序(rerank)。

No Code Indexing 这边,核心是省 token 和提搜索效率。因为最大成本在反复的搜索-读取循环,优化重点就是:并行发起多个工具调用而非串行、用更精准的搜索词减少无效轮次、读文件时只读相关行段而非整文件。用 ripgrep 这类高性能工具替代普通 grep 本身就是一种优化。需要提醒的是,有人指出 grep 方案的可扩展性前提是"本地文件系统、毫秒级可扫描的几千个文件";当文件规模继续放大,这个前提会被挑战[12]。

一句话选型经验:代码这类结构化、可精确搜索的数据,代理式搜索往往够用且更省心;而非结构化的商业文档检索,传统 RAG 仍是更便宜的方案——按查询成本算,RAG 比全量塞上下文便宜约 100 倍[6]。两边都对,只是在解不同的问题。