总结来说，纯grep方案主要有三大问题：

信息过载：现代代码库动辄数万文件，grep 搜索结果中 99% 为无关噪音，AI 易被洪流淹没；语义盲目：仅匹配字符组合，无法理解代码功能 —— 例如找不到compute_final_cost()与calculate_total_price()的语义关联；上下文失忆：仅返回匹配行，缺失函数所属类、依赖关系等关键上下文，AI 难以判断代码作用。

而之所以知道问题所在，但还是坚持使用grep，对Claude Code来说，一方面是技术路线的选择问题，另一方面，要搞好代码检索，里面有大量工程细节需要处理。如，代码如何切分？代码变动了怎么办？索引和检索速度怎么保证？怎么为海量的代码的 embedding 建立索引？

显然，这些都与 Claude Code 【简单】【无界面的 CLI】的定位相违背。更关键的是，embedding 模型和向量数据库也不是 Anthropic 的强项。

这也是我们为什么要做Claude Context，并且把它开源的原因：

https://github.com/zilliztech/claude-context

这是一个集成了向量数据库和 embedding 模型的开源代码检索 MCP 工具，可以无缝集成到 Claude Code 中，同时也兼容其他 AI Coding IDE，让 LLM 获得更优质、更准确、更低成本的上下文信息。

此外，针对纯grep方案的三大致命缺陷，Claude Context 分别做了专项突破

智能过滤：通过向量相似度排序，将最相关的代码片段置顶，排除无关干扰；概念理解：基于 embedding 技术理解代码语义，即使函数名不同，只要功能相似就能精准匹配；上下文召回：每个搜索结果均包含完整的代码上下文（类、函数、依赖），让 AI 像人类程序员一样理解代码逻辑。02 技术解读：Claude Context实现全过程

以下是个Claude Context方案实现全过程

（1）技术选型

接口层面：MCP

MCP 就像是 LLM 与外界交互的USB，可以把产品能力以 MCP server 的方式提供出来，这样不仅是 Claude Code，甚至其他 AI IDE 比如 Gemini CLI、Qwen Code 等都能用。

向量数据库：选择 Zilliz Cloud

Zilliz Cloud 是全托管的 Milvus 向量数据库服务，具备高性能向量搜索、高 QPS 与低延时、云原生架构带来的弹性扩展和无限存储等特性，还有多副本增强可用性，简直是为 Codebase Indexing 量身定制的。

Embedding 模型：多种选择OpenAI 的 embedding model：经过广泛使用和验证，稳定可靠Voyage embedding：在 Code 领域有专用模型，效果更好Ollama：适合本地部署，隐私性更强

其他 embedding 模型，持续支持

⌨️ 编程语言：TypeScript

在 Python 和 TypeScript 之间纠结了一下，最终选择 TypeScript。原因很简单：它更兼容应用层，开发的模块可以无缝集成到高层的 TypeScript 应用中，比如 VSCode 插件等。而且 Claude Code、Gemini CLI 等也都是用 TypeScript 写的，生态更友好。

（2）架构设计

从解耦、分层的设计原则角度来看，它的架构被设计成了两层：

核心模块：包含所有核心逻辑，里面每块的逻辑也是分开设计的，比如代码解析、向量化索引、语义检索、同步更新等。

上层模块：包含 MCP、vscode 插件等集成。它基于核心模块，更多是包含一些应用层的逻辑，尤其是 MCP，它是与 Claude Code 等 AI IDE 交互的最佳方式。

这样设计的好处是，核心模块可以被上层模块复用，后续不管是横向还是纵向，都很容易扩展其他模块。

更多测试细节已经在 github 仓库中更新。claude-context 也已经开源，并在GitHub上获得了九千 star，如果对你有帮助，欢迎使用和推荐。

https://github.com/zilliztech/claude-context

https://www.npmjs.com/package/@zilliz/claude-context-mcp

05 对比展示

这里选择了两个案例，来展示下纯grep 方法与基于混合检索的RAG方案的能力差。

案例一：Django YearLookup Bug

Issue 地址为

问题描述：Django 框架中，YearLookup 查询优化破坏了 __iso_year 过滤功能。当使用 __iso_year 过滤器时，YearLookup 类错误地应用了标准的 BETWEEN 优化，这对日历年有效，但对 ISO 周编号年无效。

#这应该使用 EXTRACT('isoyear' FROM ...) 但错误地使用了 BETWEENDTModel.objects.filter(start_date__iso_year=2020)

# 生成: WHERE "start_date" BETWEEN 2020-01-01 AND 2020-12-31

# 应该是: WHERE EXTRACT('isoyear' FROM "start_date") = 2020

Baseline grep 方法的过程日志分析：

directory_tree()⚙️ 结果: 检索了 3000  行目录结构 (~50k tokens)   问题: 大量信息过载，没有直接相关性 search_text('ExtractIsoYear')⚙️ 结果: 在多个文件中找到 21 个匹配项:   - django/db/models/functions/__init__.py:5 (导入语句)   - django/db/models/functions/__init__.py:31 (导出列表)     - django/db/models/functions/datetime.py:93 (ExtractIsoYear 类)   问题: 大多数都是无关的导入和注册 edit_file('django/db/models/functions/datetime.py')⚙️ 修改了多个注册语句，但这是错误的解决方向

关键问题：文本搜索专注于错误的组件（ExtractIsoYear 注册），而不是实际的优化逻辑（YearLookup 类）。

Claude Context 方法的过程日志分析：

search_code('YearLookup')⚙️ 为查询找到 10 个结果: "YearLookup" 在代码库中   1. 代码片段 (python) [repo__django__django]      位置: django/db/models/lookups.py:568-577      上下文: YearExact 类与 get_bound_params 方法   2. 代码片段 (python) [repo__django__django]        位置: django/db/models/lookups.py:538-569      上下文: YearLookup 基类与 year_lookup_bounds 方法 edit_file(django/db/models/lookups.py)⚙️ 成功修改了核心优化逻辑，添加 ISO 年处理

关键成功逻辑：语义搜索立即理解了"YearLookup"作为核心概念，找到了需要修改的确切类。

效率对比：

Baseline 方法：8 次工具调用，消耗 130,819 tokens，0% 命中率

Claude Context：3 次工具调用，消耗 9,036 tokens，50% 命中率，节省了 93% 的 Token！

案例二：Xarray swap_dims Bug

Issue 地址为

问题描述：Xarray 库的 .swap_dims() 方法意外修改了原始对象，违反了不可变性期望。在某些情况下，.swap_dims() 修改原始对象而不是返回新对象。

import numpy as npimport xarray as xrnz = 11ds = xr.Dataset({ "y": ("z", np.random.rand(nz)), "lev": ("z", np.arange(nz) * 10),})

这不应该修改 ds，但实际上修改了

ds2 = ds.swap_dims(z="lev").rename_dims(lev="z").reset_index("lev").reset_coords()

ds2.swap_dims(z='lev') # 这意外地修改了 ds2['lev']

# ds2['lev'] 现在有维度 'lev' 而不是 'z'

Baseline grep 方法的过程日志分析：

list_directory('repo__pydata__xarray')⚙️ 结果: 检索了多个子目录的目录结构   问题: 基本的目录导航，没有目标搜索 search_text('swap_dims')⚙️ 结果: 在核心文件中找到 21 个匹配项:   - xarray/core/common.py:600 (Dataset.swap_dims 引用)   - xarray/core/dataarray.py:753 (".rename() or .swap_dims() instead.")   - xarray/core/dataarray.py:2026 (DataArray.swap_dims 引用)   - xarray/core/dataarray.py:2044 (def swap_dims 方法)   问题: 在不同上下文中有许多匹配项 read_file('xarray/core/dataarray.py', offset=2000, limit=40)⚙️ 结果: 读取了显示 rename 方法文档的第 2001-2040 行 read_file('xarray/core/dataset.py', offset=3600, limit=40) ⚙️ 结果: 读取了显示 rename_dims 方法的第 3601-3640 行

低效原因：使用了大量的 list_directory 和 read_file 操作，而不是专注于相关方法。

Claude Context 方法的过程日志分析：

search_code('.swap_dims()')⚙️ 为查询找到 10 个结果: ".swap_dims()" 在代码库中   1. 代码片段 (python) [repo__pydata__xarray]      位置: xarray/tests/test_formatting_html.py:67-76   2. 代码片段 (python) [repo__pydata__xarray]      位置: xarray/tests/test_dataset.py:2926-2979 edit_file('xarray/core/dataset.py')⚙️ 成功修改文件，添加了维度处理逻辑 edit_file('xarray/core/dataarray.py')⚙️ 成功修改文件，确保不修改原始 DataArray

关键成功逻辑：语义搜索立即定位了实际的swap_dims()实现并理解了功能上下文。

效率对比：

Baseline 方法：11 次工具调用，消耗 41,999 tokens，50% 命中率Claude Context：3 次工具调用，消耗 15,826 tokens，50% 命中率，节省了 62% 的 Token！尾声

Claude Context不仅适用于Claude Code，同样适用于 Codex、 Gemini CLI、Cline在内几乎所有AI coding产品，欢迎大家多多体验与反馈。

https://github.com/zilliztech/claude-context

完整的实验数据、代码和复现方法都在项目的 evaluation/ 目录中开放。

作者介绍张晨Zilliz Algorithm Engineer

阅读推荐官宣：Zilliz Cloud&Milvus发布CLI工具与官方Skill，让AI Agent成为专业VDB运维与开发助手Vector Graph RAG 开源！一套向量数据库同时搞定语义检索 RAG多跳Harness的Managed Agents好在哪里？如何解决它的经验复用短板

黄仁勋GTC演讲上，Milvus为什么能够站稳非结构化数据处理C位

2026年，Embedding要怎么选？（实测Gemini 、jina、Qwen、BGE、OpenAI十大模型）

用RAG的思路做agent知识管理，为什么跑不通