Claude Code 的检索方式：为什么 grep 可能比 RAG 更适合代码库
原文链接：RAG 已死？从 Claude Code 源码到行业实践看 Grep 的回归
这篇文章讨论的是一个很容易被标题带偏的问题：Claude Code 这类编程 Agent 为什么不一定需要传统 RAG？
我的理解是，它并不是在说 RAG 彻底没用了，而是在说：对于代码库这种高度结构化、随时变化、天然可搜索的材料，LLM + grep/ripgrep + 文件读取 这种动态检索方式，很多时候比“提前切分、向量化、建索引”的传统 RAG 更直接。
先说结论
传统 RAG 的典型流程是：
- 把资料切成 chunk。
- 对 chunk 做 embedding。
- 存到向量库。
- 用户提问时先召回相似片段。
- 再把片段塞给模型生成回答。
这个流程在知识库问答里很常见，但放到代码库里会遇到几个问题：
- 代码变化很快，索引很容易过期。
- chunk 切分可能破坏函数、类、调用链的完整语义。
- 向量相似度不一定能准确命中真实入口。
- 检索出来的内容仍然需要模型继续判断是否相关。
而 Claude Code 这类工具更像一个会使用命令行的程序员：先看目录，再用关键词搜索，再读文件，再顺着调用关系继续追。它不是一次性“召回答案”，而是边查边缩小范围。
为什么代码库适合 grep
代码和普通自然语言文档不一样。
普通文档里，同一个意思可能有很多说法。比如“登录失败”“认证异常”“账号校验不通过”可能指向同一类问题。这个时候，embedding 的语义相似度有价值。
但代码里有大量明确锚点：
- 文件名
- 函数名
- 类名
- 变量名
- API 路径
- 错误信息
- 配置项
- 日志关键字
这些东西本来就是程序员为了可维护性留下的索引。你要找 login failed，直接搜错误字符串；你要找接口处理逻辑，搜路由；你要找某个配置怎么生效，搜配置 key。很多时候，字面搜索已经足够精确。
所以对代码库来说，真正重要的不是“有没有一个向量库”，而是模型能不能提出好搜索词，并且能不能根据搜索结果继续追踪上下文。
Agentic Search 和传统 RAG 的差别
我觉得文章里最关键的点是：Claude Code 的检索不是一次性的，而是 agentic search。
传统 RAG 更像：
先把可能相关的资料找出来，再回答。
Agentic search 更像：
先提出一个搜索假设，执行搜索，阅读结果，再决定下一步查哪里。
这个过程更接近真实开发者的工作方式：
- 先用
rg搜一个关键字。 - 看命中的文件名和上下文。
- 判断哪个文件像入口。
- 打开文件读实现。
- 顺着 import、调用链、类型定义继续查。
- 最后形成对问题的判断。
这种方式的优势是实时、可解释、成本低。它不需要提前维护索引，也不会因为代码刚改完但向量库没更新而查到旧内容。
但这不是说 RAG 已死
标题里的“RAG 已死”更像是一种问题意识，不应该理解成绝对结论。
RAG 仍然有适用场景：
- 大量自然语言文档检索。
- 用户问题和原文用词差异很大。
- 需要跨文档语义归纳。
- 资料更新频率较低，可以接受提前建索引。
- 需要在海量资料中做粗召回。
代码库检索只是一个特殊场景。它的特点是结构强、命名密集、变更频繁、局部上下文重要。因此，对它来说，轻量的本地搜索经常比重型 RAG 更实用。
更准确的说法应该是：RAG 不是死了，而是不能无脑套到所有检索问题上。
对我写代码的启发
这篇文章给我的启发是：做 AI 工具时，不要一上来就默认“需要向量数据库”。
应该先问几个更底层的问题：
- 数据是不是天然有明确关键词？
- 数据是不是变化非常频繁？
- 用户的问题是否能转成精确搜索条件？
- 检索结果是否需要可解释路径？
- 维护索引的成本是否高于收益？
如果答案偏向“是”，那 grep/ripgrep + 文件读取 + 多轮推理 可能就是更合适的第一版方案。
尤其在编程 Agent 里，工具调用能力比单纯 embedding 更关键。模型真正需要的不是一次性拿到一堆“看起来相似”的片段，而是像开发者一样，有能力逐步定位、验证、排除和追踪。
小结
这篇文章的价值不在于证明 RAG 没用了，而在于提醒我们：检索方案要服务于数据形态。
自然语言知识库适合语义召回，代码库则天然适合精确搜索和上下文追踪。Claude Code 选择 grep/ripgrep，并不是技术倒退，而是回到了一个很朴素的工程判断：能用简单、实时、可解释的方法解决问题，就不要先引入复杂系统。
对代码检索来说，最强的方案未必是“向量库优先”，而是“让模型学会像工程师一样搜索”。