腾讯面试官:“为什么 Claude Code 不用 RAG 检索代码,而是 grep?”我:“因为...我也不知道”,他沉默了。

腾讯面试官:“为什么 Claude Code 不用 RAG 检索代码,而是 grep?”我:“因为...我也不知道”,他沉默了。 有没有想过Claude Code 的代码搜得又快又准到底是怎么实现的我花了一早上时间认真研究了会翻了翻 Anthropic 首席工程师 Boris Cherny 的播客、亚马逊科学团队发的论文、Cursor 官方博客的论证、Claude Code 源码把这件事从头到尾捋了一遍。系好安全带我们粗粗发01、Claude Code 到底怎么查找代码的先回答最基本的问题Claude Code 在分析代码仓库时用的是什么工具答案很简单——三个工具Glob、Grep、Read。是不是很意外是不是很惊喜Glob 负责按文件名模式匹配比如**/*.java找出所有 Java 文件。返回的结果按修改时间排序。Grep 负责在文件内搜索底层用的是 ripgrep一个 Rust 写的高性能搜索工具。比如我们想找哪个文件里用了Transactional注解Grep 很快就能返回结果。Read 负责读取具体文件的内容。可以读整个文件也可以指定行号范围只读一部分。支持图片、PDF、Jupyter Notebook覆盖面很广。没有向量数据库没有 Embedding 模型没有索引构建过程没有 Chunk 分片策略。Claude Code 拿到一个任务之后先用 Glob 看看目录结构再用 Grep 搜关键词最后用 Read 读取相关文件。Anthropic 内部给这种方式起了个名字叫Agentic Search智能体搜索。核心思路是不预先构建任何索引而是让 Agent 在执行任务的过程中根据当前的上下文和目标动态决定搜什么、怎么搜、搜到之后下一步干什么。这三个工具还有一个关键属性它们都是isConcurrencySafe true的只读工具可以并行执行。Claude Code 经常同时发起多个 Grep 搜索一次性扫描多个关键词效率拉满。02、RAG 检索代码的五个问题要理解 Claude Code 为什么不用 RAG得先搞清楚 RAG 用在代码搜索上到底有什么问题。第一代码不是自然语言语义相似度在代码这块不管用。RAG 的核心逻辑是把文本转成向量然后用余弦相似度找“语义最接近”的内容。这个逻辑在自然语言场景下很好使比如“如何处理用户认证”和“用户登录流程”语义上确实接近。但代码不一样。createD1HttpClient和buildD1HttpClient语义上很接近但在代码仓库里它们可能是两个完全不同的函数。我们要找的是那个精确的函数名不是“差不多的”函数名。反过来handleAuth和validateJwtToken语义上看起来不太相关但后者可能就是前者内部调用的关键逻辑。向量相似度不会帮我找到这种调用关系但一个简单的 grep 搜索validateJwtToken就能精确定位。代码世界里精确匹配比语义匹配重要得多。一个变量名、一个方法签名、一个 import 路径要么完全匹配要么就是找错了。没有“大概对”这回事。第二索引同步成本很高写代码的小伙伴都知道代码是不断变化的。刚改了一个方法名RAG 的索引里还是旧的名字。新增了一个文件索引里没有。删了一个类索引里还在。要保持索引和代码的实时同步得做增量更新、文件监听、冲突处理。这套东西做起来的复杂度比 RAG 本身还高。而 grep 天然不存在这个问题它搜索的永远是磁盘上此时此刻的文件内容。代码改了grep 的结果就跟着变了不需要任何同步机制。第三安全和隐私RAG 需要一个 Embedding 模型来生成向量。这个模型要么跑在本地消耗计算资源要么调用远程 API代码内容要发到外部服务器。代码库是“非常敏感”的我们肯定不愿意把代码发送到任何第三方服务去生成 Embedding。本地部署 Embedding又需要很高的算力成本。grep 直接在本地磁盘上搜索。从安全的角度看这个优势是碾压级的。03、ripgrep 凭什么这么猛说到 grep大家可能第一反应是 Linux 上的 GNU grep。Claude Code 用的不是这个是 ripgrep一个用 Rust 写的现代搜索工具。ripgrep 的作者叫 Andrew Gallant他在 Rust 的正则表达式引擎上花了两年半的时间。这个引擎用了 SIMD 指令集加速简单说就是用 CPU 的矢量计算单元来做文本匹配搜索速度能逼近内存带宽的极限。一般来说在一个几万个文件的中型代码仓库里ripgrep 跑一次全文搜索大概需要 200 毫秒。而同样的搜索任务如果走 RAG 流程先把查询文本发给 Embedding 模型生成向量一次网络往返再去向量数据库里做 KNN 搜索又一次网络往返拿到结果后可能还要做 Rerank又一次模型调用。整个链路下来至少 8 个步骤、四五个服务。ripgrep 还有几个对 Agent 特别友好的特性。它默认递归搜索整个目录自动跳过.gitignore里列出的文件和二进制文件输出结果自带文件名和行号。这些恰好就是 Agent 在分析代码时最需要的信息。Claude Code 的 Grep 工具在 ripgrep 之上还封装了一层保护机制。默认最多返回 250 行通过head_limit控制防止一次搜索返回几千行代码把上下文窗口撑爆。如果 ripgrep 超时了但有部分结果它会把最后一行不完整的结果丢掉返回已经拿到的部分。如果完全没有结果才会抛出超时错误。这种“尽力返回结果”的设计哲学和 RAG 的“要么成功要么失败”形成了鲜明对比。04、Anthropic 官方怎么说这一段的信息来源是 Boris ChernyClaude Code 首席工程师2025 年 5 月 7 日在 Latent Space 播客上的原话。这期节目的另一位嘉宾是 Catherine Wu也是 Claude Code 的核心工程师。Boris 说了这样一句Claude Code 早期版本确实用过 RAG。他们用的是 Voyage 的 Embedding 模型做了一套本地向量索引。效果“还行”。但后来他们试了另一种方式就是我们前面说的 Glob Grep Read 的 Agentic Search。结果发现这种方式在各项指标上全面碾压 RAG。Boris 原话说的是 “outperformed everything, by a lot”全面超越而且差距很大。他坦承这个判断主要基于“内部 vibes”也就是直觉和体感加上一些内部 benchmark 的数据。Boris 给出了放弃 RAG 的核心原因。第一是性能。Agentic Search 的搜索质量更高。这里的“质量”不只是准确率还包括搜索结果的可用性。grep 返回的是精确的代码行和文件路径Agent 拿到就能直接用RAG 返回的是一堆“相关”的代码片段Agent 还得二次理解和筛选。第二是简洁。RAG 需要维护索引的同步、处理增量更新、管理向量数据库的生命周期。Agentic Search 不需要任何预处理打开一个代码仓库直接开始搜没有“初始化索引”这个步骤。05、亚马逊论文的实锤2025 年 12 月亚马逊科学团队发表了一篇论文题目“Keyword search is all you need: Achieving RAG-Level Performance without vector databases using agentic tool use”关键词搜索就够了用 Agent 工具调用达到 RAG 级别的性能不需要向量数据库。他们的研究方法是搭建一个标准的 RAG 系统向量数据库 Embedding 检索 生成和一个只有关键词搜索工具的 Agent 系统然后在相同的问答任务上对比两者的表现。结论是基于关键词搜索的 Agent 系统可以达到传统 RAG 系统 90% 以上的性能指标。论文还有一个关键发现对于代码这种符号精确的结构化文本关键词搜索的表现实际上比语义检索还要好。因为代码的命名约定通常是一致的函数名、变量名、类名本身就携带了足够的语义信息不需要额外的语义理解。06、Cursor 的反面论证说到这里可能有小伙伴要问了如果 grep 这么好为什么 Cursor 还在用向量搜索这是个好问题。Cursor 训练了自己的 Embedding 模型建了一套完整的索引管道用 Turbopuffer 做向量数据库。他们的 A/B 测试结果显示加入语义搜索后Agent 的准确率提升了不少。在超过 1000 个文件的大型代码仓库中提升效果更加明显代码留存率Agent 写的代码被用户保留的比例增加了 2.6%。几个关键区别。第一Cursor 是 IDE 级别的产品用户在 IDE 里工作时代码仓库是相对稳定的索引同步的压力没那么大。而 Claude Code 是一个命令行工具用户可能随时切换到不同的代码仓库。第二Cursor 用的是混合检索grep 和向量搜索都用而不是只用向量搜索。他们的结论是“两者配合使用效果最好”而不是“向量搜索比 grep 好”。这反过来证明了 grep 是不可或缺的基础能力。07、LLM 就是最好的 Reranker在 Agentic Search 的架构里LLM 本身就充当了 Reranker 的角色。传统 RAG 的工作流是Embedding → 向量检索 → Rerank → 生成。其中 Rerank 这一步是为了弥补向量检索精度不够的问题向量搜索返回的“Top K”结果里经常混进不相关的内容需要一个更精细的模型来重新排序。但在 Claude Code 的架构里grep 返回的结果是确定性的搜createD1HttpClient就只会返回包含这个精确字符串的代码行。Agent 拿到这些精确的搜索结果后用 LLM 自己的推理能力来判断哪些结果是有用的、接下来应该读哪个文件、还需要搜什么关键词。这种模式下LLM 做的不是简单的 Rerank而是理解 决策 行动。它会根据第一轮搜索的结果调整后续的搜索策略比如发现一个关键函数调用后顺藤摸瓜去搜被调用的函数定义。这种多轮迭代的搜索能力是 RAG 的“一次检索”模式做不到的。RAG 像是去图书馆让管理员帮忙找书管理员根据描述找了几本“可能相关”的放到桌上至于对不对得自己翻了才知道。而 Agentic Search 像是自己去图书馆先看楼层指引Glob 看目录结构再去对应楼层的书架上找Grep 搜内容找到了翻开看看Read 读文件不对就换个关键词再找。09、简历怎么写项目名称PaiCLI 智能代码分析平台项目简介基于 Agentic Search 架构的代码分析工具采用 grep LLM 的方式替代传统 RAG 检索实现对大型代码仓库的高效分析和理解。核心职责基于 ripgrep 实现了代码级的全文检索引擎支持正则表达式和 Glob 模式匹配单次搜索耗时控制在 200ms 以内设计了 Agent 多轮迭代搜索策略通过 Glob→Grep→Read 的工具链实现代码上下文的逐步聚焦搜索精确率达到 95% 以上实现了搜索结果的智能截断机制head_limit partial results将单次搜索的 token 消耗控制在 6K 以内避免上下文溢出学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】