京东面试官：“为什么Claude Code不用Rag索引代码，而是用grep”，我笑了：“RAG的Chunking放到代码里，最怕把结构切断”，面试官点头

“为什么 Claude Code 不用 RAG 检索代码而是直接用 grep”这个问题听起来像工具选型其实不是。它问的是你到底懂不懂代码检索和普通知识库检索的区别。很多录友一听检索脑子里就自动冒出 RAG、Embedding、向量数据库、Top-K、Rerank。这套东西当然重要。但注意RAG 很强不等于所有检索都该用 RAG。尤其是代码检索。代码不是一篇篇静态文档代码是每天都在变的、强结构化的、需要精确定位的工程对象。你找getUserById要的就是这个函数不是语义上差不多的用户查询函数。你找LoginController要的是这个文件、这个类、这几行调用链不是一堆和登录相关的片段。所以 Claude Code 这种编程 Agent没有把核心检索路径押在传统 RAG 上而是把最朴素的工具做到了极致Glob 找文件Grep 搜内容Read 读上下文再让模型多轮判断下一步。看起来土。但这恰恰是工程判断。这篇文章我们从代码检索的本质开始讲一层层拆代码检索到底在解决什么问题为什么传统 RAG 放到代码里会别扭Claude Code 的 Grep、Glob、Read 为什么不是简单 shell 命令多轮 Agent 检索为什么比一次性 Top-K 更适合写代码子 Agent 为什么能解决上下文污染grep 也不是银弹什么场景仍然该用 RAG 或混合检索面试里怎么回答才能答出架构感认真看完面试官再问这题你别只说因为 grep 快。目录先说结论这不是 grep 赢了 RAG代码检索和文档检索根本不是一类问题RAG 检索代码的四个硬伤Claude Code 为什么把检索拆成三件套Grep 不是简单 grep而是受控的代码搜索工具Glob 和 Read 解决的是文件入口和上下文边界真正关键的是多轮循环不是某个工具子 Agent把探索过程隔离出去grep 方案也有边界什么时候 RAG 仍然有价值面试怎么答一、先说结论这不是 grep 赢了 RAG先把结论放前面Claude Code 不用传统 RAG 作为代码检索主路径不是因为 RAG 落后而是因为代码检索更需要实时性、精确性、可解释性和多轮决策。这四个词就是这道题的核心。RAG 的典型思路是先把代码切块做 Embedding写进向量库。用户提问时再把 Query 也向量化召回语义相似的 Top-K 片段塞给模型。这套方案适合什么适合知识库问答、产品文档、FAQ、政策条文、客服资料。因为这些内容有几个特点文档相对稳定用户问题偏语义匹配目标通常是找到相关材料答案可以由多个文档片段综合出来但代码检索经常是另一种形态文件刚改完下一秒就要读到最新内容函数名、类名、变量名必须精确匹配调用链不能被切碎搜索过程要能根据结果不断改方向错了要能知道是哪一步搜错了所以这不是grep 技术含量比 RAG 高。不是。grep 本身很普通。真正厉害的是Claude Code 把 grep 放进了 Agent 的多轮工具调用循环里让模型像程序员一样边搜、边读、边判断、边修正。如果只看工具grep 很老。如果看系统grep Agent Loop 就不老了。它不是一个搜索框。它是一个会自己改搜索策略的代码侦查流程。代码检索要解决的是符号、入口、调用链和最新状态二、代码检索和文档检索根本不是一类问题很多人把代码库当成一堆文本。这就是第一层误解。代码当然是文本但它不是普通文本。一篇产品文档里某句话断在两段之间可能还凑合能读。代码不行。一个if的条件在上面分支在下面你只召回下面那几行模型根本不知道为什么走到这里。一个函数只看函数体不看它的类型定义、调用方、配置文件、路由入口也很容易改错。代码检索至少有四类目标。第一类找符号。比如找getUserById、UserService、AuthMiddleware。这类问题不需要语义相似。要的就是字面命中。面试里你可以直接说代码里大量检索任务是 symbol lookup不是 semantic search。第二类找入口。比如登录逻辑在哪。这时你可能不知道具体函数名但你会先搜login、auth、token、passport再看命中的文件。这是关键词探索不是一次向量召回就结束。第三类找关系。比如这个字段从接口进来以后在哪里校验、在哪里入库、哪里返回给前端。这就不是找一个片段而是找一条路径。你要沿着 controller、service、dao、model、schema 一路读下去。第四类找变化。比如刚才改了支付状态为什么测试挂了。这时最重要的是最新文件内容、git diff、最近修改的文件。RAG 索引如果没更新召回的就是旧代码。旧代码拿来修新 bug这不是帮忙是添乱。所以代码检索的核心不是找相似内容而是在一个不断变化的结构化工程里快速定位当前任务真正需要的最小上下文。这句话很重要。最小上下文不是越多越好。很多录友用 AI 写代码效果差就是喜欢把一堆无关文件塞给模型。模型看得越多注意力越散。你以为是在补充信息其实是在制造噪声。三、RAG 检索代码的四个硬伤RAG 能不能检索代码能。但如果你把传统文档 RAG 直接搬到代码库问题会非常明显。1. Chunk 很容易破坏代码结构RAG 的第一步是切块。文档切块主要考虑语义段落。代码切块就麻烦了。按固定行数切函数会被切断。按函数切类上下文可能丢了。按类切文件又可能太大。按 AST 切语言多了以后工程复杂度直接上来。更要命的是代码片段不是孤立的。一个函数的意义往往来自参数类型返回类型调用方被调用函数配置项数据库 schema测试用例传统 RAG 召回一个函数片段看起来相关但上下文可能是残的。模型基于残缺上下文改代码幻觉概率就上来了。2. 向量相似不等于代码正确向量检索擅长找意思相近。但代码场景经常要找名字相同。你让系统找validateToken向量库可能召回verifyTokendecodeTokenrefreshTokenvalidateSession这些语义都很像。但你要改的是validateToken。别的函数再像也不是目标。这就是代码场景里最典型的问题语义相似是优势但精确匹配是底线。向量召回相似函数和 grep 精确命中目标函数的区别没有底线召回越多越乱。3. 索引滞后会伤害实时开发知识库 RAG 可以每天更新一次。代码不行。你让 Claude Code 改一个文件它刚写完下一步就要读这个文件验证。如果走 RAG就有一个尴尬问题索引更新了吗没更新查到旧代码。更新谁来决定哪些 chunk 失效跨文件引用怎么同步刚改了函数签名调用方 chunk 要不要重算这些都能做。但代价很大。而 grep 和 Read 是现读磁盘。文件是什么样它看到的就是什么样。这里没有缓存一致性问题。RAG索引滞后和Read实时读取磁盘的差异4. Top-K 是一次性下注Agent 需要边走边看传统 RAG 的核心流程是一次召回用户问问题系统召回 Top-K模型基于 Top-K 回答。如果 Top-K 召回错了后面就全歪。代码开发不是这样。程序员找问题一般是这样的先搜一个关键词。没搜到换个词。搜到太多缩小目录。看到一个文件发现它调用另一个函数。再跟过去看。看到测试报错再回头查实现。这是一串动态决策。不是一次性把材料发完。RAG 更像发试卷Agent 检索更像现场排查。写代码需要的是后者。RAG Chunking 会把代码函数结构切碎四、Claude Code 为什么把检索拆成三件套Anthropic 官方文档里列出的 Claude Code 工具能看到Glob、Grep、Read、Task这些工具。其中Glob是按模式找文件Grep是搜文件内容Read是读取文件Task是跑子 Agent 处理复杂多步任务。这几个工具合起来就是 Claude Code 代码理解的底层动作。为什么不直接开放一个万能 Bash让模型自己跑grep、find、cat因为产品级 Agent 不能这么粗。Claude Code 把这几个动作拆成专用工具至少有三层考虑。第一权限边界清楚。Grep和Read是只读工具。Write、Edit是会改文件的工具。这种边界对安全非常关键。如果都塞进 Bash模型到底只是搜索还是顺手执行了危险命令就不好控制。第二返回结果可控。普通 shell 输出是纯文本。工具可以控制输出结构比如文件路径、行号、匹配内容、截断策略。这对模型很重要。模型不是人眼看终端它需要干净、稳定、可预测的观察结果。第三提示词可以教模型怎么用。工具不是 API 那么简单。工具描述会进入模型上下文告诉模型什么时候用、参数怎么填、什么情况不要用。也就是说工具定义本身就是 Agent 行为的一部分。所以别把Grep理解成包装了一下 grep 命令。更准确的说法是Grep 是一个带权限、带输出约束、带使用规范的代码搜索能力。这才是工程化。专用Grep工具相比万能Bash的权限边界和输出控制五、Grep 不是简单 grep而是受控的代码搜索工具面试官如果继续追问“既然有 Bash为什么还要单独做 Grep 工具”你可以从四个角度答。1. 搜索是高频动作必须产品化编程 Agent 每完成一个任务可能会搜索很多次。找文件、找函数、找错误信息、找测试、找配置。如果每次都让模型自由拼 shell 命令风险和噪声都会增加。把高频动作做成专用工具就是把最常用的路径铺平。2. grep 的确定性适合代码符号代码里很多东西就是字面符号。函数名、类名、变量名、路由路径、错误码、配置 key。这些东西用正则和关键词搜效果非常好。比如rg getUserByIdrg POST /loginrg JWT_SECRETrg ORDER_STATUS_PAID这种任务向量检索没有优势。你要的是确定命中不是语义相似。3. grep 结果天然可解释grep 命中了哪一行一眼就能看出来。模型也能继续基于这个结果推理“这个文件命中了login我需要 Read 它附近 80 行。”“命中太多了我要限定到src/server目录。”“这个关键词没搜到我换成signin。”RAG 的 Top-K 召回则比较黑盒。你很难解释为什么这五个 chunk 排在前面。一旦答错排查也麻烦是 Embedding 不行是 chunk 切错是 Top-K 太小是 Rerank 误排是生成阶段没看链路长了定位问题就难。4. grep 可以和目录约束组合真实代码搜索里在哪搜和搜什么同样重要。你不会每次都全仓库搜。你会先判断前端逻辑去src/pages、src/components后端逻辑去server、api、controller测试去__tests__、tests配置去.env、configGrep 和 Glob 配合就能让模型逐步缩小范围。这比一次 Top-K 更像真实开发。Glob、Grep、Read三件套逐步收敛代码上下文六、Glob 和 Read 解决的是文件入口和上下文边界只讲 grep 还不够。Claude Code 不是只靠 grep。它靠的是三件套。Glob先找可能相关的文件Glob 解决的是文件入口问题。有时候你不知道内容关键词只知道文件形态。比如找所有路由文件**/*route*.ts找所有测试文件**/*.test.ts找所有 Vue 组件**/*.vue找所有配置文件**/*config*这类检索用向量库很别扭。因为你不是在问语义你就是在找文件名模式。文件名本身就是工程约定。项目越规范Glob 越好用。Read只读需要的上下文Read 解决的是上下文边界问题。很多人让 AI 读文件一上来就整文件塞进去。这很浪费。真正合理的方式是先 Grep 命中行号。再 Read 命中行附近几十行。如果发现需要函数定义再扩大一点。如果发现调用另一个文件再跳过去读。这叫按需读取。代码理解不是把仓库倒进模型而是把模型需要的证据逐步拿出来。这个思路非常重要。面试里你说出来面试官基本能听出你真的用过 AI 编程工具而不是只背概念。三件套的标准路径举个例子。用户说“登录接口加一个验证码校验。”Claude Code 大概率不是直接写代码。它会先探索用 Glob 找路由和登录相关文件比如**/*auth*、**/*login*用 Grep 搜login、signin、token、password用 Read 读取命中文件附近逻辑发现登录调用了AuthService再 GrepAuthServiceRead service 实现找到测试文件修改代码跑测试或读取测试逻辑验证你看这不是一次检索。这是一个不断收敛的链路。每一步都在问“我现在知道了什么下一步最该看哪里”这就是 Agent。登录接口加验证码任务的代码检索轨迹七、真正关键的是多轮循环不是某个工具如果只说 Claude Code 用 grep所以不用 RAG这个答案还不够。真正核心是Claude Code 的检索发生在 Agent Loop 里。之前写 Claude Code大厂面试题汇总 的时候讲过Claude Code 的底层形态就是多轮循环模型思考下一步调用工具拿到工具结果再继续判断。代码检索放进这个循环以后就变成了动态搜索。动态搜索和 RAG 的差别很大。RAG 是一次性给材料典型 RAG 是用户问题 → 向量召回 Top-K → 拼 Prompt → 模型回答。它的问题是召回阶段一旦选错模型没有机会修正检索策略。当然Agentic RAG 可以多轮检索。但传统 RAG 面试里大家讲的那套核心还是先召回再生成。Agent 检索是边看边改方向Agent 检索是用户问题 → 模型决定先搜什么 → 工具返回结果 → 模型看结果 → 决定下一步读哪里或换什么关键词。这更接近人类程序员的工作方式。比如搜login结果太多。模型会缩小目录。搜captcha没结果。模型会试verifyCode、smsCode、validateCode。读到AuthService.login()发现调用了issueToken()。模型会继续跟进去。读到测试用例发现已有登录测试。模型会优先修改测试覆盖。这就是多轮循环的价值工具结果不是答案而是下一轮决策的证据。这句话可以直接放进面试回答。RAG一次性Top-K和Agent多轮检索的差异八、子 Agent把探索过程隔离出去还有一个面试官很爱追问的点“如果让主 Agent 一直 Grep、Read上下文不会爆吗”会。所以 Claude Code 还有Task工具也就是让子 Agent 去处理复杂、多步的探索任务。Anthropic 官方文档也明确讲了 subagents 的价值子 Agent 有独立的上下文窗口可以避免污染主对话并且能限制工具权限。这点非常关键。什么叫上下文污染你让 Agent 调研一个项目的鉴权流程。它可能要搜auth搜login搜jwt搜middleware读路由读 service读配置读测试读拦截器中间会产生大量搜索结果和文件片段。这些信息有用吗对探索过程有用。对最终写代码不一定都有用。如果全塞进主 Agent 上下文主 Agent 后面真正要修改代码时注意力就会被一堆中间过程占满。这就是上下文污染。子 Agent 怎么解决主 Agent 可以派一个探索型子 Agent“你去调研登录链路给我返回关键文件、核心流程、修改点。”子 Agent 在自己的上下文里随便 Grep、Read。它可以看很多文件做很多中间判断。最后只把压缩后的结论返回给主 Agent。主 Agent 不需要记住所有 grep 输出。它只需要知道登录入口在哪个文件验证逻辑在哪个函数token 在哪里生成测试应该改哪里需要注意什么边界这就是上下文治理。子 Agent 的价值不是更聪明而是把探索过程和执行上下文隔离开。这比多开几个 Agent 并行干活更本质。并行只是收益之一。隔离才是核心。子 Agent 也要控制权限生产级 Agent 里子 Agent 不能随便拥有所有工具。探索型子 Agent 最好只给只读工具。比如 Glob、Grep、Read。它负责调研不负责改代码。主 Agent 拿到结论后再决定是否 Edit。这个设计能降低误操作风险。面试里可以这么说复杂探索用子 Agent简单定向搜索用 Grep/Glob/Read。子 Agent 最好限制为只读工具把上下文污染和权限风险都隔离出去。这就是很工程化的回答。子Agent隔离搜索噪声并向主Agent返回压缩结论九、grep 方案也有边界什么时候 RAG 仍然有价值写到这里录友别误会。不是说 RAG 没用。更不是说做代码检索就只能 grep。技术选型最忌讳站队应该看场景。Claude Code 的选择适合它的主战场本地或单仓代码库、实时开发、精确修改、需要多轮探索。但下面这些场景RAG 或混合检索仍然有价值。1. 超大规模跨仓库检索如果是公司级代码搜索几十个仓库、几亿行代码。只靠 grep 不一定合适。这时候需要索引。但注意索引不一定就是纯向量。更常见的是关键词倒排索引符号索引AST 索引调用图索引向量索引组合起来用。代码检索最强的形态往往不是纯 RAG而是混合检索。2. 模糊需求探索用户问“找一下项目里和权限收敛相关的逻辑。”“有没有类似限流熔断的实现”“哪里处理了用户风险等级”这类问题不一定有明确关键词。向量检索可以帮你找到语义相近的代码和文档。然后再用 grep 精确追踪。所以比较好的路径是语义检索做发现grep 做确认Read 做证据。这个说法比RAG 不行高级得多。3. 代码加文档的综合问答很多企业内部问题不只在代码里。还在设计文档、接口文档、ADR、Wiki、故障复盘里。比如“为什么订单状态这里要分成 PAID 和 CONFIRMED”答案可能不在代码里而在历史设计文档里。这种场景 RAG 很适合。因为它检索的是知识背景不是当前文件的精确修改点。4. 长期记忆和团队知识沉淀Claude Code 读当前代码库很强。但如果你要做的是团队级知识助手长期积累常见故障原因历史架构决策代码规范业务词表工程实践经验那 RAG 仍然很重要。grep 只能搜当前文件。RAG 可以承载长期知识。所以最终答案应该是代码实时修改主路径用 grep/Glob/Read跨仓语义发现和知识背景用 RAG 或混合检索。这才是成熟架构师的判断。grep、RAG和混合检索的适用场景决策图十、面试怎么答最后我们把这道题收回来。面试官问“为什么 Claude Code 不用 RAG 检索代码而是直接用 grep”不要上来就说“因为 grep 快。”太简单了。你可以分三层答。第一层代码检索不是普通文档检索可以这么说“代码检索和知识库文档检索不一样。文档 RAG 更关注语义相关但代码检索经常是符号定位、文件入口、调用链追踪和最新内容读取。比如我找一个函数名或配置 key精确匹配比语义相似更重要。”这一层回答的是场景差异。第二层传统 RAG 在代码场景有结构性问题接着说“如果把传统 RAG 直接用到代码库会遇到几个问题。第一chunking 容易破坏函数、类、调用链这些结构。第二向量召回是近似匹配容易把相似函数召回来但代码修改要的是准确目标。第三代码每天都在变索引容易滞后。第四Top-K 是一次性召回写代码更需要根据搜索结果不断调整方向。”这一层回答的是 RAG 的短板。第三层Claude Code 的关键不是 grep而是 Agent Loop最后升维“Claude Code 的设计不是简单用 grep 替代 RAG而是把 Grep、Glob、Read 放进 Agent Loop 里。模型先搜再读再根据结果决定下一步。这种多轮检索更像程序员现场排查问题。复杂探索还可以交给子 Agent在独立上下文里搜索和总结避免污染主 Agent 上下文。”这一层回答的是 Agent 设计哲学。如果想再加一句可以这样收尾“所以这不是 grep 和 RAG 谁高级的问题而是主路径选型。实时、精确、可解释的代码修改grep/Read 更合适跨仓语义发现、代码加文档的知识问答RAG 或混合检索仍然有价值。”这套回答就完整了。高频追问追问1那 grep 搜不到语义怎么办答“grep 不擅长纯语义搜索所以 Claude Code 这类工具通常会通过多轮关键词改写、文件结构探索、调用链阅读来弥补。如果是跨仓库的模糊语义发现我会引入混合检索用向量召回做发现用 grep 和 Read 做确认。”关键词是向量做发现grep 做确认。追问2为什么不用 AST 索引答“AST 索引对代码结构理解很有价值尤其适合符号跳转、引用查找、调用关系分析。但它的工程成本更高多语言支持复杂实时更新也麻烦。Claude Code 的核心场景是快速适配任意项目所以用通用的文件模式搜索和内容搜索作为基础能力更轻量。理想情况下AST 索引可以作为增强能力不一定替代 Grep。”这回答比较稳。不要把 AST 贬低它很有用。但要讲清楚成本和适用范围。追问3RAG 能不能做增量更新答“能做但增量更新本身就是复杂工程。代码改动会影响 chunk、符号引用、调用链和测试上下文单纯替换某个向量不一定够。对于实时编码场景现读磁盘天然避免索引一致性问题。对于公司级知识库或跨仓检索再做增量索引是合理的。”追问4子 Agent 为什么能减少上下文污染答“因为子 Agent 有独立上下文。它可以在自己的上下文里做大量 Grep 和 Read最后只把压缩后的结论返回给主 Agent。主 Agent 不需要承载所有中间搜索结果后续修改代码时注意力更集中。”追问5一句话总结 Claude Code 的设计哲学答“把确定性工具交给模型把检索决策权还给模型让模型在多轮工具反馈中逐步逼近答案。”这句话就够狠。最后这道题表面问的是“Claude Code 为什么不用 RAG”实际问的是你能不能根据任务特点做检索架构选型。RAG 很重要但不要把 RAG 当万能钥匙。代码检索最怕的不是搜不到很多相关内容。最怕的是搜到一堆看起来相关、实际上不能改的内容。AI 编程工具的核心不是把整个仓库喂给模型。而是让模型像一个靠谱工程师一样先找入口再看证据再跟调用链再动手改。别迷信复杂架构。能用简单工具解决的问题先把简单工具用到极致。这也是工程能力。学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%免费】