原创 张晨 2025-09-11 18:43 上海
一半人在吐槽Claude Code，另一半打算改完手里的bug再吐槽
最近，无论国内海外开发者，一半都在吐槽Claude Code，另一半则打算改完手里的bug再吐槽Claude Code。
国内用户的不满集中在无端账号封禁上，而海外用户则对Code 功能的 Token 消耗过快怨声载道。
更关键的是，从技术层面来看，降低 Token 消耗对 Claude 并非难事，但它却选择单一的 grep 方案做代码检索，由此产生了大量不必要的 Token 浪费
为此，我们前段时间开源了Claude Context—— 通过 MCP模式，让 Claude Code 等 AI IDE 具备一键搞定代码上下文检索的能力，可直接减少约 40% 的 Token 消耗。
https://github.com/zilliztech/claude-context
但这个方案，也在各大技术论坛引发了激烈讨论。
有人认为grep足够用，引入向量数据库和embedding，会导致过度工程化！
也有人认为，grep 只能字面匹配，根本理解不了代码语义，Claude Context 能大幅提升检索精度和效率。
双方观点看似各有道理，不如用实测数据一较高下
01
实验设计思路
对比双方：
Baseline 方法：纯 grep + read + edit 工具的基础 Agent
增强方法：基础 Baseline 工具 + Claude Context MCP 的增强 Agent
评估指标：
检索质量：F1-Score、精确率、召回率
效率指标：Token 消耗、工具调用次数
成本效益：单任务处理成本
实验条件（控制变量）
为排除无关变量干扰，两种方法使用完全一致的实验环境：
相同 LLM：GPT-4o-mini
相同数据集：Princeton NLP 的 SWE-bench Verified 数据集（含 500 个经专业审查的高质量样本，专为评估 AI 解决真实软件工程问题设计）
相同框架：ReAct Agent 框架
相同任务：30 个难度适中（15-60 分钟）、标准化（每个任务需修改 2 个文件）的任务实例
每种方法均运行 3 轮独立实验，取平均值后进行对比，总计完成 6 次完整测试。
02
实验结果
实验结果直接验证了我们的初始设想 ——Claude Context 的增强方法在效率、成本、精度上全面优于纯 grep 的 Baseline 方法。核心结论有三
Token 消耗大幅降低：相比 Baseline，增强方法 Token 消耗减少近 40%，单个任务平均节省 28,924 个 Token；重度 AI 编程用户每月可节省几十到几百美元 API 费用；
工具调用更高效、响应更快：工具调用次数减少超过 1/3，避免了无效操作的资源浪费；原本 5 分钟的代码定位任务，现在 3 分钟即可完成；
检索精度更优：精准定位核心代码上下文，让后续的AI生成更精准
03
案例解读，纯 grep 的缺陷是什么？
这里选择了两个案例，分析他们的日志，来说明为什么纯 grep 方法效率低下。
案例一：Django YearLookup Bug
Issue 地址为 https://github.com/django/django/pull/14170
问题描述：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 地址为 https://github.com/pydata/xarray/pull/6938
问题描述：Xarray 库的 .swap_dims() 方法意外修改了原始对象，违反了不可变性期望。在某些情况下，.swap_dims() 修改原始对象而不是返回新对象。
import numpy as np
import xarray as xr
nz = 11
ds = 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-762. 代码片段 (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！
04
两种方法的工作流程对比
我们可以用流程图来直观对比两种方法的差异：
Baseline grep 方法的工作流程
Claude Context 语义搜索工作流程
不难发现，纯grep 的局限性源于其 “字面匹配” 的本质，这带来了三大致命缺陷
信息过载：现代代码库动辄数万文件，grep 搜索结果中 99% 为无关噪音，AI 易被洪流淹没；
语义盲目：仅匹配字符组合，无法理解代码功能 —— 例如找不到compute_final_cost()与calculate_total_price()的语义关联；
上下文失忆：仅返回匹配行，缺失函数所属类、依赖关系等关键上下文，AI 难以判断代码作用。
也是针对这三大局限，Claude Context 针对三大核心能力做了突破
智能过滤：通过向量相似度排序，将最相关的代码片段置顶，排除无关干扰；
概念理解：基于 embedding 技术理解代码语义，即使函数名不同，只要功能相似就能精准匹配；
上下文召回：每个搜索结果均包含完整的代码上下文（类、函数、依赖），让 AI 像人类程序员一样理解代码逻辑。
尾声
Claude Context不仅适用于Claude Code，同样适用于 Codex、 Gemini CLI、Cline在内几乎所有AI coding产品，欢迎大家多多体验与反馈。
项目地址：
https://github.com/zilliztech/claude-context
实验详情
完整的实验数据、代码和复现方法都在项目的 evaluation/ 目录中开放。
作者介绍
张晨
Zilliz Algorithm Engineer
推荐阅读
国内首个 LangGraph Agent 模板！Multi-Agent框架最优解
Hugging Face轻量化框架Candle实战｜基于Rust，比PyTorch配置简单
Word2Vec、 BERT、BGE-M3、LLM2Vec，embedding模型选型指南｜最全
