Claude Context 语义代码搜索实战Django YearLookup __iso_year 缺陷定位案例深度解析【免费下载链接】claude-contextCode search MCP for Claude Code. Make entire codebase the context for any coding agent.项目地址: https://gitcode.com/GitHub_Trending/co/claude-context本文以claude-context开源仓库评测套件中的真实案例django__django-14170为蓝本逐行还原grep 语义搜索与纯 grep两条 Agent 检索路径在定位同一个 Django ORM 历史缺陷时的完整决策过程。读完本文你将掌握语义代码检索search_code与正则文本搜索search_text在复杂缺陷定位中的本质差异、两套评测指标Token 用量 / 工具调用次数的读取方法以及如何在本仓库的 evaluation 目录下复现这一对照实验。案例背景一个被隐藏了多个版本的 Django ORM 缺陷本案例取自 SWE-bench_Verified 数据集的django__django-14170实例缺陷全称是Query optimization in YearLookup breaks filtering by __iso_year。原 Issue 的描述要点如下YearLookup 中用 BETWEEN 替代 EXTRACT 操作的优化同样被注册到了__iso_year这个 lookup 上从而破坏了通过 lookup 使用ExtractIsoYear的功能。该问题自 Django 2.2 引入ExtractIsoYearticket #28649起就一直存在且极难定位ExtractIsoYear单独用于 annotation 时完全正常只有把它用于 filter 时优化逻辑才会被触发。用原 Issue 提供的三条 SQL 对比可以直观看到问题# annotation 单独使用时正常工作生成 EXTRACT(isoyear ...) qs DTModel.objects.annotate(extractedExtractIsoYear(start_date)).only(id) print(qs.query) SELECT db_functions_dtmodel.id, EXTRACT(isoyear FROM db_functions_dtmodel.start_date) AS extracted FROM db_functions_dtmodel # 显式 annotation 用于 filter 时未复用 extracted反而叠加了 BETWEEN print(qs.filter(extracted2020).query) SELECT db_functions_dtmodel.id, EXTRACT(isoyear FROM db_functions_dtmodel.start_date) AS extracted FROM db_functions_dtmodel WHERE db_functions_dtmodel.start_date BETWEEN 2020-01-01 AND 2020-12-31 # 隐式 lookup 直接使用 BETWEEN print(DTModel.objects.filter(start_date__iso_year2020).only(id).query) SELECT db_functions_dtmodel.id FROM db_functions_dtmodel WHERE db_functions_dtmodel.start_date BETWEEN 2020-01-01 AND 2020-12-31问题本质是ISO 8601 周编号年ISO week-numbering year与公历年calendar year的边界并不重合——公历 2020 年 1 月 1 日可能仍属于 ISO 2019 年。因此用BETWEEN 2020-01-01 AND 2020-12-31代替EXTRACT(isoyear FROM ...) 2020会把跨年周的记录错误过滤掉导致__iso_year过滤器返回错误数据。与该缺陷相关的两个oracle 文件即官方修复 patch 实际涉及的文件为django/db/models/lookups.pydjango/db/backends/base/operations.py注意以上涉及的文件路径均位于评测过程中克隆的 Django 源码仓库内并不在本仓库中本仓库只保存评测脚本与结果。完整的 Issue 描述、两条 Agent 的真实交互日志见 evaluation/case_study/django_14170/README.md 及同目录下的两个*_conversation.log文件。实验设计同一缺陷两条检索路径按照 evaluation/README.md 的说明该对照实验的总体设计是控制变量——两个编码 Agent 执行完全相同的检索任务基于同一 SWE-bench 实例、同一 LLM、同一代码仓库唯一差别是工具集合维度Baseline纯 grepEnhancedgrep Claude Context MCP基础工具read / grep / editread / grep / edit相同基础附加工具无search_code语义检索实现框架LangGraph MCP ReActLangGraph MCP ReAct相同工具注册逻辑在 evaluation/retrieval/custom.py 的_create_mcp_client()中filesystem读文件、edit改文件为公共服务器claude-context服务器通过npx -y zilliz/claude-context-mcp0.1.0启动并注入OPENAI_API_KEY、MILVUS_ADDRESS、EMBEDDING_BATCH_SIZE环境变量默认 100grep服务器则运行 evaluation/servers/grep_server.py。两种模式分别通过--retrieval_types grep与--retrieval_types cc,grep启用cc即 Claude Context。对django_14170这一实例评测脚本首先克隆 Django 仓库并回退到base_commit然后Both 方法先用index_codebase建立向量索引AST splitter再让 Agent 携带search_code等工具检索并编辑Grep 方法不建索引Agent 只拥有directory_tree、search_text等文本工具。两份结果的 JSON 指标由 evaluation/run_evaluation.py 落盘分别为 evaluation/case_study/django_14170/both_result.json 与 evaluation/case_study/django_14170/grep_result.json。量化结果Token 省 93%工具调用省 62%原文档给出的核心指标表如下其中命中率指 Agent 最终编辑命中 oracle 文件的比例两个 oracle 文件各占 50%指标Both 方法grep 语义搜索Grep 方法提升幅度Token 用量9,036130,819减少 93%工具调用次数38减少 62%成功率50% 命中命中 1/2 个 oracle 文件0% 命中未命中任何 oracle 文件显著更优两份 JSON 提供了更细粒度的证据Both 方法both_result.json{ hits: [django/db/models/lookups.py], oracles: [django/db/models/lookups.py, django/db/backends/base/operations.py], token_usage: { input_tokens: 8582, output_tokens: 454, total_tokens: 9036, max_single_turn_tokens: 3829 }, tool_stats: { tool_call_counts: { search_code: 1, edit: 2 }, total_tool_calls: 3 }, retrieval_types: [cc, grep] }Grep 方法grep_result.json{ hits: [django/db/models/functions/datetime.py, tests/db_functions/datetime/test_extract_trunc.py], oracles: [django/db/backends/base/operations.py, django/db/models/lookups.py], token_usage: { input_tokens: 130064, output_tokens: 755, total_tokens: 130819, max_single_turn_tokens: 26750 }, tool_stats: { tool_call_counts: { directory_tree: 1, search_text: 1, edit: 6 }, total_tool_calls: 8 }, retrieval_types: [grep] }两组数据有两个值得注意的细节单轮峰值 Token 差 7 倍Both 方法单轮最多 3,829 tokens而 Grep 方法单轮峰值高达 26,750 tokens——这正是 Grep 方法第一次调用directory_tree拉取 3000 行目录结构、约 5 万 token 输出所造成的信息爆炸命中与误伤Both 方法唯一一次命中lookups.py恰好是根因所在的核心 oracle 文件Grep 方法命中与编辑的datetime.py、test_extract_trunc.py均不在 oracle 之列——它把力气全部花在了错误文件上。路径一grep 语义搜索如何直击根因以下是 both_conversation.log 中 Both 方法 Agent 的完整行动序列 search_code(YearLookup) ← 唯一的检索调用 Arguments: {path: repo, query: YearLookup, limit: 10} Result: Found 10 results 1. django/db/models/lookups.py:568-577 Context: YearExact.get_direct_rhs_sql → return BETWEEN %s AND %s 2. django/db/models/lookups.py:538-569 Context: YearLookup.year_lookup_bounds → isinstance(output_field, DateTimeField) ... edit_file(django/db/models/lookups.py) old_string: def get_direct_rhs_sql(self, connection, rhs):\n return connection.operators[self.lookup_name] % rhs new_string: def get_direct_rhs_sql(self, connection, rhs):\n if self.lookup_name __iso_year:\n return EXTRACT(ISOYEAR FROM %s) % rhs\n return connection.operators[self.lookup_name] % rhs edit_file(django/db/models/lookups.py) old_string: def year_lookup_bounds(self, connection, year): new_string: def year_lookup_bounds(self, connection, year):\n if self.lookup_name __iso_year:\n return (year - 1, year)整个过程只有3 次工具调用1 次检索 2 次编辑且两次编辑都落在根因文件lookups.py上。原文档将其成功原因概括为三点概念理解Agent 把 YearLookup 识别为造成该问题的优化机制本身而非仅仅一个字符串直接导航search_code返回的 Top-2 结果直接就是YearExact与YearLookup两个需要修改的类几乎没有噪声根因聚焦语义检索暴露出的代码片段里get_direct_rhs_sql返回BETWEEN %s AND %s这一优化逻辑清晰可见Agent 据此判断需要让__iso_year绕过 BETWEEN、回到EXTRACT(ISOYEAR FROM ...)同时修正year_lookup_bounds的边界计算——即让边界计算具备 ISO 年意识。路径二纯 Grep 方法为何迷失方向对比 grep_conversation.log 中 Grep 方法 Agent 的行动序列 directory_tree(repo) ← 第一步就拉取全量目录树 Result: 3000 行目录结构约 5 万 token Problem: 信息过载与缺陷无直接关联 search_text(ExtractIsoYear) ← 检索关键词选偏 Result: 21 处匹配绝大多数是无关内容 - functions/__init__.py:5 import 语句 - functions/__init__.py:31 导出列表 - functions/datetime.py:93 class ExtractIsoYear - functions/datetime.py:150 DateField.register_lookup Problem: 匹配到的几乎全是 import 与注册语句 edit_file(datetime.py) × 5 ← 注释掉 5 行 register_lookup edit_file(test_extract_trunc.py) ← 注释掉 1 行测试断言Grep 方法共8 次工具调用1 次目录树 1 次文本检索 6 次编辑其失败原因原文档总结为四条信息过载directory_tree一次灌入约 5 万 token 的目录结构挤占了推理空间表层匹配把检索目标定在ExtractIsoYear字符串上抓到的是 import、注册、导出列表而不是真正出问题的YearLookup优化逻辑错误方案最终用注释掉register_lookup注册行 注释测试断言这种表面修补代替了对核心边界逻辑的修复——甚至把官方测试直接禁用属于典型的方向性误判缺乏上下文无法建立YearLookup 的 BETWEEN 优化与ISO 年边界之间的因果联系。为什么语义搜索能赢两种检索机制的本质差异从本仓库源码看两条路径的检索机制完全不同语义检索search_code的底层实现在 packages/mcp/src/handlers.ts 的handleSearchCode()先将自然语言 query 通过 Embedding 模型向量化再对已建立向量索引的代码块执行context.semanticSearch()按向量相似度打分排序默认limit10、单次上限 50并支持extensionFilter按文件后缀过滤如[.ts, .py]会被翻译成 Milvus 过滤表达式fileExtension in [...]。它检索的是语义单元函数、类、方法级别的代码块因此YearLookup能直接关联到YearExact、year_lookup_bounds这些真正相关的实现。文本检索search_text的实现在 evaluation/servers/grep_server.py优先调用git grep -n -E失败后回退系统grep -n -r -E排除.git、node_modules等目录与二进制文件。它做的是字面正则匹配——ExtractIsoYear出现在 import 行、导出列表、类定义、注册调用等 21 处但对 Agent 而言这些匹配没有相关性排序噪音与信号混杂在一起。可以推断两种方法在 Token 效率上的巨大差距正源于此grep 把检索的成本海量无关匹配转嫁给了 LLM 上下文而语义检索把筛选提前到向量检索阶段完成LLM 拿到的已经是高相关性的代码片段。原文档对该案例的结论是该问题本质是优化逻辑YearLookup 的 BETWEEN 优化误伤 ISO 年而非ISO 年功能本身的缺陷语义搜索对概念的把握使其直接锁定了正确的架构修复点。需要客观指出的是Both 方法命中率为 50%命中lookups.py未命中operations.py说明语义检索也并非完美但相对 Grep 方法的 0% 命中其定位能力与成本效率的优势是数据可证的。如何在本仓库复现该评测django_14170是评测套件选出的 30 个 SWE-bench_Verified 实例之一筛选条件为 15–60 分钟难度、恰好修改 2 个文件的子集见 evaluation/generate_subset_json.py。复现步骤如下依赖安装细节见 evaluation/README.md# 1. Python 环境建议 uv cd evaluation uv sync source .venv/bin/activate # Node 环境要求Node.js 20.0.0 且 24.0.0 # 2. 环境变量 export OPENAI_API_KEYyour_openai_api_key export MILVUS_ADDRESSyour_milvus_address export GITHUB_TOKENyour_github_token # 用于自动克隆评测仓库 # 3. 生成子集数据集 python generate_subset_json.py # 4. 基线纯 grep评测 python run_evaluation.py --retrieval_types grep --output_dir retrieval_results_grep # 5. 增强grep Claude Context评测 python run_evaluation.py --retrieval_types cc,grep --output_dir retrieval_results_both # 6. 结果分析与绘图 python analyze_and_plot_mcp_efficiency.py其中run_evaluation.py会对每个实例依次执行克隆仓库clone_repo、回退到 base commitContextManager、如启用 cc调用index_codebase建索引并轮询get_indexing_status直到就绪、执行检索与编辑最后将命中文件列表、oracle 文件列表、Token 用量、工具调用统计写入result.json并把 Agent 对话摘要写入conversation.log——本案例目录下的两份 JSON 与两份日志即是该流程的产物。注意评测所用 LLM 为 GPT-4o-mini每个方法独立运行 3 次取统计由于 LLM 的随机性精确数值无法保证完全复现但语义检索显著降低 Token 与工具调用、提升定位精度的核心结论在不同运行间保持一致。小结django_14170案例给出了一个很有代表性的对照样本同一个隐藏多年的 Django ORM 缺陷纯 grep 路径因信息过载与字面匹配而将 13 万 token、8 次工具调用消耗在错误文件上grep 语义搜索路径则以 9 千 token、3 次调用直击根因文件。结合 evaluation/case_study/README.md 中另一例 pydata_xarray_6938swap_dims()变异缺陷语义方法节省 62% Token、73% 工具调用可以确认对于需要理解概念关系与因果逻辑的复杂缺陷把整库语义检索接入编码 Agent如 Claude Code 的 MCP 工具能显著提升定位效率与成功率——这正是claude-context项目Make entire codebase the context for any coding agent的核心价值所在。【免费下载链接】claude-contextCode search MCP for Claude Code. Make entire codebase the context for any coding agent.项目地址: https://gitcode.com/GitHub_Trending/co/claude-context创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Claude Context 语义代码搜索实战：Django YearLookup __iso_year 缺陷定位案例深度解析
Claude Context 语义代码搜索实战Django YearLookup __iso_year 缺陷定位案例深度解析【免费下载链接】claude-contextCode search MCP for Claude Code. Make entire codebase the context for any coding agent.项目地址: https://gitcode.com/GitHub_Trending/co/claude-context本文以claude-context开源仓库评测套件中的真实案例django__django-14170为蓝本逐行还原grep 语义搜索与纯 grep两条 Agent 检索路径在定位同一个 Django ORM 历史缺陷时的完整决策过程。读完本文你将掌握语义代码检索search_code与正则文本搜索search_text在复杂缺陷定位中的本质差异、两套评测指标Token 用量 / 工具调用次数的读取方法以及如何在本仓库的 evaluation 目录下复现这一对照实验。案例背景一个被隐藏了多个版本的 Django ORM 缺陷本案例取自 SWE-bench_Verified 数据集的django__django-14170实例缺陷全称是Query optimization in YearLookup breaks filtering by __iso_year。原 Issue 的描述要点如下YearLookup 中用 BETWEEN 替代 EXTRACT 操作的优化同样被注册到了__iso_year这个 lookup 上从而破坏了通过 lookup 使用ExtractIsoYear的功能。该问题自 Django 2.2 引入ExtractIsoYearticket #28649起就一直存在且极难定位ExtractIsoYear单独用于 annotation 时完全正常只有把它用于 filter 时优化逻辑才会被触发。用原 Issue 提供的三条 SQL 对比可以直观看到问题# annotation 单独使用时正常工作生成 EXTRACT(isoyear ...) qs DTModel.objects.annotate(extractedExtractIsoYear(start_date)).only(id) print(qs.query) SELECT db_functions_dtmodel.id, EXTRACT(isoyear FROM db_functions_dtmodel.start_date) AS extracted FROM db_functions_dtmodel # 显式 annotation 用于 filter 时未复用 extracted反而叠加了 BETWEEN print(qs.filter(extracted2020).query) SELECT db_functions_dtmodel.id, EXTRACT(isoyear FROM db_functions_dtmodel.start_date) AS extracted FROM db_functions_dtmodel WHERE db_functions_dtmodel.start_date BETWEEN 2020-01-01 AND 2020-12-31 # 隐式 lookup 直接使用 BETWEEN print(DTModel.objects.filter(start_date__iso_year2020).only(id).query) SELECT db_functions_dtmodel.id FROM db_functions_dtmodel WHERE db_functions_dtmodel.start_date BETWEEN 2020-01-01 AND 2020-12-31问题本质是ISO 8601 周编号年ISO week-numbering year与公历年calendar year的边界并不重合——公历 2020 年 1 月 1 日可能仍属于 ISO 2019 年。因此用BETWEEN 2020-01-01 AND 2020-12-31代替EXTRACT(isoyear FROM ...) 2020会把跨年周的记录错误过滤掉导致__iso_year过滤器返回错误数据。与该缺陷相关的两个oracle 文件即官方修复 patch 实际涉及的文件为django/db/models/lookups.pydjango/db/backends/base/operations.py注意以上涉及的文件路径均位于评测过程中克隆的 Django 源码仓库内并不在本仓库中本仓库只保存评测脚本与结果。完整的 Issue 描述、两条 Agent 的真实交互日志见 evaluation/case_study/django_14170/README.md 及同目录下的两个*_conversation.log文件。实验设计同一缺陷两条检索路径按照 evaluation/README.md 的说明该对照实验的总体设计是控制变量——两个编码 Agent 执行完全相同的检索任务基于同一 SWE-bench 实例、同一 LLM、同一代码仓库唯一差别是工具集合维度Baseline纯 grepEnhancedgrep Claude Context MCP基础工具read / grep / editread / grep / edit相同基础附加工具无search_code语义检索实现框架LangGraph MCP ReActLangGraph MCP ReAct相同工具注册逻辑在 evaluation/retrieval/custom.py 的_create_mcp_client()中filesystem读文件、edit改文件为公共服务器claude-context服务器通过npx -y zilliz/claude-context-mcp0.1.0启动并注入OPENAI_API_KEY、MILVUS_ADDRESS、EMBEDDING_BATCH_SIZE环境变量默认 100grep服务器则运行 evaluation/servers/grep_server.py。两种模式分别通过--retrieval_types grep与--retrieval_types cc,grep启用cc即 Claude Context。对django_14170这一实例评测脚本首先克隆 Django 仓库并回退到base_commit然后Both 方法先用index_codebase建立向量索引AST splitter再让 Agent 携带search_code等工具检索并编辑Grep 方法不建索引Agent 只拥有directory_tree、search_text等文本工具。两份结果的 JSON 指标由 evaluation/run_evaluation.py 落盘分别为 evaluation/case_study/django_14170/both_result.json 与 evaluation/case_study/django_14170/grep_result.json。量化结果Token 省 93%工具调用省 62%原文档给出的核心指标表如下其中命中率指 Agent 最终编辑命中 oracle 文件的比例两个 oracle 文件各占 50%指标Both 方法grep 语义搜索Grep 方法提升幅度Token 用量9,036130,819减少 93%工具调用次数38减少 62%成功率50% 命中命中 1/2 个 oracle 文件0% 命中未命中任何 oracle 文件显著更优两份 JSON 提供了更细粒度的证据Both 方法both_result.json{ hits: [django/db/models/lookups.py], oracles: [django/db/models/lookups.py, django/db/backends/base/operations.py], token_usage: { input_tokens: 8582, output_tokens: 454, total_tokens: 9036, max_single_turn_tokens: 3829 }, tool_stats: { tool_call_counts: { search_code: 1, edit: 2 }, total_tool_calls: 3 }, retrieval_types: [cc, grep] }Grep 方法grep_result.json{ hits: [django/db/models/functions/datetime.py, tests/db_functions/datetime/test_extract_trunc.py], oracles: [django/db/backends/base/operations.py, django/db/models/lookups.py], token_usage: { input_tokens: 130064, output_tokens: 755, total_tokens: 130819, max_single_turn_tokens: 26750 }, tool_stats: { tool_call_counts: { directory_tree: 1, search_text: 1, edit: 6 }, total_tool_calls: 8 }, retrieval_types: [grep] }两组数据有两个值得注意的细节单轮峰值 Token 差 7 倍Both 方法单轮最多 3,829 tokens而 Grep 方法单轮峰值高达 26,750 tokens——这正是 Grep 方法第一次调用directory_tree拉取 3000 行目录结构、约 5 万 token 输出所造成的信息爆炸命中与误伤Both 方法唯一一次命中lookups.py恰好是根因所在的核心 oracle 文件Grep 方法命中与编辑的datetime.py、test_extract_trunc.py均不在 oracle 之列——它把力气全部花在了错误文件上。路径一grep 语义搜索如何直击根因以下是 both_conversation.log 中 Both 方法 Agent 的完整行动序列 search_code(YearLookup) ← 唯一的检索调用 Arguments: {path: repo, query: YearLookup, limit: 10} Result: Found 10 results 1. django/db/models/lookups.py:568-577 Context: YearExact.get_direct_rhs_sql → return BETWEEN %s AND %s 2. django/db/models/lookups.py:538-569 Context: YearLookup.year_lookup_bounds → isinstance(output_field, DateTimeField) ... edit_file(django/db/models/lookups.py) old_string: def get_direct_rhs_sql(self, connection, rhs):\n return connection.operators[self.lookup_name] % rhs new_string: def get_direct_rhs_sql(self, connection, rhs):\n if self.lookup_name __iso_year:\n return EXTRACT(ISOYEAR FROM %s) % rhs\n return connection.operators[self.lookup_name] % rhs edit_file(django/db/models/lookups.py) old_string: def year_lookup_bounds(self, connection, year): new_string: def year_lookup_bounds(self, connection, year):\n if self.lookup_name __iso_year:\n return (year - 1, year)整个过程只有3 次工具调用1 次检索 2 次编辑且两次编辑都落在根因文件lookups.py上。原文档将其成功原因概括为三点概念理解Agent 把 YearLookup 识别为造成该问题的优化机制本身而非仅仅一个字符串直接导航search_code返回的 Top-2 结果直接就是YearExact与YearLookup两个需要修改的类几乎没有噪声根因聚焦语义检索暴露出的代码片段里get_direct_rhs_sql返回BETWEEN %s AND %s这一优化逻辑清晰可见Agent 据此判断需要让__iso_year绕过 BETWEEN、回到EXTRACT(ISOYEAR FROM ...)同时修正year_lookup_bounds的边界计算——即让边界计算具备 ISO 年意识。路径二纯 Grep 方法为何迷失方向对比 grep_conversation.log 中 Grep 方法 Agent 的行动序列 directory_tree(repo) ← 第一步就拉取全量目录树 Result: 3000 行目录结构约 5 万 token Problem: 信息过载与缺陷无直接关联 search_text(ExtractIsoYear) ← 检索关键词选偏 Result: 21 处匹配绝大多数是无关内容 - functions/__init__.py:5 import 语句 - functions/__init__.py:31 导出列表 - functions/datetime.py:93 class ExtractIsoYear - functions/datetime.py:150 DateField.register_lookup Problem: 匹配到的几乎全是 import 与注册语句 edit_file(datetime.py) × 5 ← 注释掉 5 行 register_lookup edit_file(test_extract_trunc.py) ← 注释掉 1 行测试断言Grep 方法共8 次工具调用1 次目录树 1 次文本检索 6 次编辑其失败原因原文档总结为四条信息过载directory_tree一次灌入约 5 万 token 的目录结构挤占了推理空间表层匹配把检索目标定在ExtractIsoYear字符串上抓到的是 import、注册、导出列表而不是真正出问题的YearLookup优化逻辑错误方案最终用注释掉register_lookup注册行 注释测试断言这种表面修补代替了对核心边界逻辑的修复——甚至把官方测试直接禁用属于典型的方向性误判缺乏上下文无法建立YearLookup 的 BETWEEN 优化与ISO 年边界之间的因果联系。为什么语义搜索能赢两种检索机制的本质差异从本仓库源码看两条路径的检索机制完全不同语义检索search_code的底层实现在 packages/mcp/src/handlers.ts 的handleSearchCode()先将自然语言 query 通过 Embedding 模型向量化再对已建立向量索引的代码块执行context.semanticSearch()按向量相似度打分排序默认limit10、单次上限 50并支持extensionFilter按文件后缀过滤如[.ts, .py]会被翻译成 Milvus 过滤表达式fileExtension in [...]。它检索的是语义单元函数、类、方法级别的代码块因此YearLookup能直接关联到YearExact、year_lookup_bounds这些真正相关的实现。文本检索search_text的实现在 evaluation/servers/grep_server.py优先调用git grep -n -E失败后回退系统grep -n -r -E排除.git、node_modules等目录与二进制文件。它做的是字面正则匹配——ExtractIsoYear出现在 import 行、导出列表、类定义、注册调用等 21 处但对 Agent 而言这些匹配没有相关性排序噪音与信号混杂在一起。可以推断两种方法在 Token 效率上的巨大差距正源于此grep 把检索的成本海量无关匹配转嫁给了 LLM 上下文而语义检索把筛选提前到向量检索阶段完成LLM 拿到的已经是高相关性的代码片段。原文档对该案例的结论是该问题本质是优化逻辑YearLookup 的 BETWEEN 优化误伤 ISO 年而非ISO 年功能本身的缺陷语义搜索对概念的把握使其直接锁定了正确的架构修复点。需要客观指出的是Both 方法命中率为 50%命中lookups.py未命中operations.py说明语义检索也并非完美但相对 Grep 方法的 0% 命中其定位能力与成本效率的优势是数据可证的。如何在本仓库复现该评测django_14170是评测套件选出的 30 个 SWE-bench_Verified 实例之一筛选条件为 15–60 分钟难度、恰好修改 2 个文件的子集见 evaluation/generate_subset_json.py。复现步骤如下依赖安装细节见 evaluation/README.md# 1. Python 环境建议 uv cd evaluation uv sync source .venv/bin/activate # Node 环境要求Node.js 20.0.0 且 24.0.0 # 2. 环境变量 export OPENAI_API_KEYyour_openai_api_key export MILVUS_ADDRESSyour_milvus_address export GITHUB_TOKENyour_github_token # 用于自动克隆评测仓库 # 3. 生成子集数据集 python generate_subset_json.py # 4. 基线纯 grep评测 python run_evaluation.py --retrieval_types grep --output_dir retrieval_results_grep # 5. 增强grep Claude Context评测 python run_evaluation.py --retrieval_types cc,grep --output_dir retrieval_results_both # 6. 结果分析与绘图 python analyze_and_plot_mcp_efficiency.py其中run_evaluation.py会对每个实例依次执行克隆仓库clone_repo、回退到 base commitContextManager、如启用 cc调用index_codebase建索引并轮询get_indexing_status直到就绪、执行检索与编辑最后将命中文件列表、oracle 文件列表、Token 用量、工具调用统计写入result.json并把 Agent 对话摘要写入conversation.log——本案例目录下的两份 JSON 与两份日志即是该流程的产物。注意评测所用 LLM 为 GPT-4o-mini每个方法独立运行 3 次取统计由于 LLM 的随机性精确数值无法保证完全复现但语义检索显著降低 Token 与工具调用、提升定位精度的核心结论在不同运行间保持一致。小结django_14170案例给出了一个很有代表性的对照样本同一个隐藏多年的 Django ORM 缺陷纯 grep 路径因信息过载与字面匹配而将 13 万 token、8 次工具调用消耗在错误文件上grep 语义搜索路径则以 9 千 token、3 次调用直击根因文件。结合 evaluation/case_study/README.md 中另一例 pydata_xarray_6938swap_dims()变异缺陷语义方法节省 62% Token、73% 工具调用可以确认对于需要理解概念关系与因果逻辑的复杂缺陷把整库语义检索接入编码 Agent如 Claude Code 的 MCP 工具能显著提升定位效率与成功率——这正是claude-context项目Make entire codebase the context for any coding agent的核心价值所在。【免费下载链接】claude-contextCode search MCP for Claude Code. Make entire codebase the context for any coding agent.项目地址: https://gitcode.com/GitHub_Trending/co/claude-context创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考