ClaudeCode 为什么放弃了 RAG？
Claude Code 的代码检索不靠 RAG，靠 grep。这是 Anthropic 工程师 Boris 在 2025 年 5 月 Latent Space 博客里公开承认的工程决策。
- 事实层：Boris 公开承认过，Claude Code 早期试过 RAG，发现效果不行就切到了 grep
- 技术层：三个根本原因——embedding 对代码失效、管线准确率乘性效应、索引时效性漂移
- 哲学层：无状态设计 + Everything is the model，对应 Bitter Lesson
- 辩证层：承认 token 成本和概念搜索的局限，业界正走向混合方案
核心结论：代码场景下 RAG 的三个根本缺陷——embedding 对标识符失效、管线乘性准确率、索引时效性漂移——叠加架构哲学上的无状态原则，共同把 Claude Code 推向了 grep。
事实：Claude Code 真的没用 RAG
2025 年 5 月，Anthropic 工程师 Boris Cherny 在 Latent Space 播客中明确说过：
Cloud Code 早期确实试过 RAG，标准方案——本地向量数据库加 embedding 检索。但他们很快发现效果不行，最终切换到了他们叫 "Egics" 的方式。说白了就是让模型自己调用 grep、glob、find 这些 Linux 命令做实时搜索。Boris 原话是 "It outperformed everything by a lot"。
被追问用的是什么 benchmark 评估时，他说 "mostly vibes，主要靠体感"。这个回答本身就有意思——说明代码检索的质量很难用传统 benchmark 衡量，更像是一个综合的工程判断。
一句话总结：Claude Code 不用 RAG，让模型自己 grep。
三个技术上的根本原因
原因 1：Embedding 对代码标识符几乎失效
这是最致命的问题。看这两个函数名：
getUserById
deleteUserById
在 embedding 向量空间里，它们共享大量 token，距离非常近。但它们的功能完全相反——一个是查询，一个是删除。
代码不是自然语言。函数名、类名、变量名本身就是结构化的精确标识符，不需要语义匹配，精确匹配天然更可靠。
实际表现：RAG 搜 process payment 经常命中一堆不相关的代码——processImage、paymentCallback 这些 token 共享的函数被拉过来。grep 搜 process_payment 则精准命中定义位置。
原因 2：管线准确率是乘法关系
整个 RAG 链路：文档切分 → embedding 生成 → 向量检索 → 重排序 → 上下文组装 → 生成回答。每个环节 90% 的准确率，五个环节乘下来只剩 60%。
更可怕的是，60% 准确率的失败是噩梦级别的——你根本不知道是 chunk 切得不好，还是 embedding 质量差，还是 Rerank 模型偏了。调试无从下手。
grep 失败的原因只有一个：关键词没匹配上。这种确定性在工程上的价值巨大。
原因 3：索引永远会过时
代码仓库变化极快。上午建的索引下午就可能过时——有人新提交了代码、重构了文件结构，索引跟实际代码就产生了漂移。
你只有两个选择：
- 频繁重建索引 → 付出巨大的计算开销
- 忍受过时索引 → 带来错误结果
grep 不存在这个问题。它实时搜索文件，拿到的永远是当前最新的代码状态。
架构哲学：为什么 grep 是更优雅的设计
讲完技术细节，再往深一层看——这其实是一个反复被验证的工程哲学问题。
无状态设计原则
从 Unix 管道到 REST API 到 Serverless，计算机史上反复验证过一条原则：不维护状态意味着零运维负担。
- 不建索引 → 零配置，用户克隆完代码就能直接用，不用等几分钟构建 embedding
- 不维护状态 → 零运维负担，没有索引卡住、缓存损坏这类问题
Everything is the model：Anthropic 内部有个原则叫 "Everything is the model"——尽量让模型本身去驱动决策，而不是在模型外面搭一套复杂的工程管线。模型每变强一分，整个系统就自动变好一分。
这其实就是 Rich Sutton 说的 Bitter Lesson 在工程上的体现——短期看，精心设计的工程系统可能跑得更好；长期看，只要模型能力上去了，那些工程技巧都会被淘汰。
安全性加分项
容易被忽略的一点：RAG 方案需要把代码做 embedding 存到某个地方（不管本地 还是云端），这个向量表示本身就是信息泄露的风险。学术上已经有研究证明，可以从 embedding 反推原始内容。
grep 完全在本地执行，从架构上就杜绝了这个问题。
不是银弹：纯 grep 的代价
辩证地看，Claude Code 的方案也有明显代价。
代价 1：Token 消耗高
每次搜索都是让模型实时执行命令：列目录、读文件、做多轮探索。token 用量远高于一次性的向量检索。Cursor 团队就公开批评过这一点，说"这是在烧 token"。
代价 2：概念级搜索有短板
对于超大型代码库，grep 在概念级搜索上确实有短板。比如你想找"所有跟权限校验相关的逻辑"，grep 不一定能覆盖所有变体写法（authCheck、verifyPermission、checkRole 这些语义相近但写法分散的函数）。
业界共识：走向混合方案
目前的行业共识是纯 RAG 和纯 grep 都不是终局，走向混合方案：
| 检索场景 | 适用方法 |
|---|---|
| 标识符级别查找（函数名、类名、变量名） | 精确搜索（grep/glob） |
| 概念级别探索（"权限校验相 关逻辑"） | 语义检索（embedding） |
两者互补。Claude Code 选择了极简的那一端，Cursor 选择了向量索引的那一端，未来大概率会在中间某个位置汇合。
References
- Latent Space Podcast: Boris Cherny on Claude Code —— Boris Cherny, 2025
- The Bitter Lesson —— Rich Sutton, 2019
- Claude Code 源码结构与设计理念 —— Kimi Gao, 2026