字节面试被问“Claude Code怎么做搜索”？答RAG后就没后续了

最近和在社区看到有个求职者面试字节的时候聊到了一些rag相关问题正好这个求职者就说自己用过claude写代码面试官就问他那你知道Claude Code检索代码用的是什么方式吗他说是RAG吧现在不都这样做吗。后续面试官就没接着聊rag相关的了。其实乍一看很多人不去查的话还真的可能会回答出rag,但是Anthropic 的工程师不仅没有给 Claude Code 配 RAG甚至在早期真的试用过之后主动把它移除了——最终依赖的是最老派的 Grep 命令。这件事在技术圈引发了不小的争议的不过后面大家也可以理解。这到底怎么个说法呢为啥用grep呢这里详细解读一下。先说说那个最流行的误解好多人一听Claude Code用Grep不用RAG第一反应就是啊这么简答还可以这样啊难道是为了省钱吗。这也不能说全错把但这部分小伙伴只看到了最外面那层。调用 Embedding模型和向量数据库确实要花一些钱而且哈Grep 这种系统自带的工具成本几乎可以忽略不计。虽然这么想有点道理但是却是把那些工程师想得太简单了人家用这个Grep肯定也是有自己的考量的而且这部分人这么说也根本没碰到问题的核心。实际上据我了解哈Claude Code一开始并不是奔着 Grep 去的。Boris Cherny就是 Claude Code 的创造者也是 Anthropic 的主任工程师他在 Hacker News 上直接说过早期版本确实用了RAG加本地向量数据库但很快就发现 Agentic Search也就是基于 grep/glob 的主动检索效果更好。后来在 Latent Space 播客里他又补了一句说测试结果“好很多幅度大到团队自己也觉得意外”。你看人家不是没做人家是一开始想到的也是RAG的做法但是效果不好啊那服务广大用户肯定是要用效果好的啊。所以这根本不是一开始就没有理由的选择Grep而是跑过实验之后得出的结论所以实验才是验证真理的唯一标准啊。有看我之前内容的小伙伴应该知道我在claude code源码中对其中用到的一些工程技术进行了升入的分析且发现很多东西就是很简单但是简答的好啊。RAG有点小问题那最直接的问题是肯定就是时效性。RAG的思路大家肯定都知道的吧就是提前建索引怎么做呢先把代码库切块、向量化、存进数据库查的时候再去库里找。听着挺合理的吧可代码库是活的啊一个正常迭代的项目一天下来可能改动几十次。你的索引刚建完了第一个文件一改它就过时了。要想保持实时同步就得搭一套差量更新、重切块、重 Embedding 的流水线这套东西的维护成本比省下来的那几次 API 调用贵太多了。再一个就是精确性的问题这个很多小伙伴肯定没有想到而且这问题更根本哦面试的时候一定要答上来。代码检索和文档检索的需求不一样你搜的是函数名、类名、API 名称这些都是精确的字符串不是模糊的“概念”或者啥文本哦。语义搜索本来是为了处理“你想说的和文档里写的不是同一个词但意思差不多”的情况但在代码里你要找的东西只有唯一正确的写法语义相似反而会给你捞出一堆完全不相关的干扰项。所以就是要精确的找到就是要Grep去搜。还有安全和隐私的考量这个能答上来就最好了因为索引文件本身就是一个攻击面代码的 Embedding 向量也不是绝对安全的有研究表明在某些条件下可以从向量里部分还原出原始文本。对于企业用户来说代码是最核心的资产多一套外部系统就多一重风险。Agentic Search 的逻辑说到底争论 Grep 还是 RAG绕不开一个更根本的问题代码检索到底是一次性的查库行为还是一个需要来回确认的过程呢。RAG 默认选的是前者也就是你问问题它找代码然后就完事了。但实际写代码时候你很少能一次就把问题描述清楚。大多数时候第一次搜出来的结果只是个线索引出下一个问题。Agentic Search 恰恰顺应了这个规律每一轮 grep 的结果都成为下一轮搜索的判断依据不断收窄范围直到锁定目标。这有点像一个资深程序员排查陌生 Bug 时的工作方式——不会上来就把所有文件扫一遍而是先 grep 一个关键词看到结果之后判断往哪个方向走再接着往下挖。Claude Code 的 Agentic Search本质上是在用工具复现这种有目的、有反馈的探索节奏。这里还有个细节很多人注意到了但没说透答出来肯定是大大的加分项。Claude Code 在处理复杂的检索时候会拉起一个独立的子进程来专门跑 grep/glob/read 这些操作底层用的是响应速度最快的 Haiku 模型。这个子进程把混乱的搜索原始结果捋一遍然后只给主模型递一份摘要。为什么要这么设计因为 grep 的原始输出往往又长又杂如果每次搜索结果都直接塞进主模型的上下文跑几轮下来上下文窗口就满了。这个架构的核心其实是在做一件事隔离噪音。这点的话大家可以看我发的参考链接。对手的选择当然那肯定不是所有工具都做了同样的决定这个分歧本身也很值得看的。Cursor 从一开始就选了代码库索引路线把仓库切块、向量化需要上下文时语义检索。这是 RAG 在代码场景里的标准实现。有人评测说Cursor 在处理大型陌生代码库时确实更聪明找到的上下文更紧凑、冗余更少。[2]但这条路也有代价。路径屏蔽要做加密处理的权限边界要管的向量泄露要防的索引同步要维护的这基本上是在原有系统之外另起了一套。Claude Code 有意回避了这条路Boris Cherny 自己说过Claude Code 的定位是一个 Unix 工具不是一个产品设计原则就是先做最简单的能跑通的东西复杂度等到真正必要时再引入。所以这不是谁比谁高明而是两种价值取向的不同选择一个愿意投资基础设施换语义能力另一个选择保持极简换可靠性和可控性。[3]Grep 也不是没有短板说了这么多 Agentic Search 的优势也得说说它的问题不然就不公平了。反对声音里最有力的一条来自 Milvus,他认为grep 没有语义理解搜出来的东西里有大量不相关的匹配模型要从这堆结果里找有用的信息本身就在消耗大量 Token。他们基于这个痛点做了一个开源 MCP 插件叫 Claude Context引入向量检索之后声称 Token 消耗能降低 40%。其次哈规模也是个边界条件。对于 Google、Meta 这种量级的超大型 Monorepo几百万个文件、几十年积累下来命名惯例混乱纯靠 grep 确实会遇到天花板。在这种场景下提前建索引做语义预筛再配合 grep 精确确认反而是更合理的混合方案。所以更准确的说法不是Grep胜过RAG而是在大多数日常开发场景里Agentic Search 的性价比和可靠性更好但它没有解决所有问题边界条件是真实存在的。最后想说聊了这么多技术细节最后说点感受层面的东西。这场争论里最有意思的不是谁赢了而是为什么那么多工程师第一反应是RAG 肯定更好。大家太习惯用技术的新旧程度来判断优劣了——新的就该更好用旧的就是保守。Anthropic 这个决定之所以值得反复想不是因为 Grep 有多厉害而是因为他们真的跑了很多的实验、看了很多的数据然后做出了一个反直觉但有效的选择。学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%免费】