基于CodeGraph的LLM代码分析：Token消耗优化策略与实践

在大型语言模型LLM应用开发中尤其是在处理复杂代码库分析、智能代码补全或生成任务时Token消耗是一个绕不开的核心成本与性能瓶颈。无论是调用OpenAI API、Claude API还是部署本地模型每一次请求的Token数量都直接关系到响应速度、费用开销以及模型处理复杂问题的能力上限。当我们需要分析一个庞大的项目源码时简单的文件拼接和发送很快就会触及模型的上下文窗口限制导致分析不完整或请求被拒绝。CodeGraph代码图技术正是应对这一挑战的利器。它通过将源代码抽象为结构化的图数据如抽象语法树AST、控制流图CFG、数据流图DFG、调用关系等使得LLM能够以更高阶、更紧凑的“理解”而非“背诵”的方式来处理代码。然而如何构建一个高效的CodeGraph并基于此设计出真正能大幅降低Token消耗、提升分析深度的增强策略是当前开发者面临的实际难题。本文将围绕“Token消耗优化”这一核心目标深入探讨如何利用和增强CodeGraph分析能力。我们将从概念入手逐步拆解CodeGraph的构建方法并重点分享几种经过实践验证的Token优化策略包括代码语义压缩、增量式分析、分层摘要生成等。无论你是正在开发AI编程助手、代码安全审计工具还是希望优化现有基于LLM的代码理解流水线本文提供的思路和示例代码都能为你带来直接的参考价值。1. 理解Token消耗与CodeGraph的核心价值在深入技术方案之前我们有必要厘清两个基本概念Token消耗为何成为瓶颈以及CodeGraph如何从根本上改变游戏规则。1.1 Token消耗成本与能力的双重约束在LLM语境下Token是文本处理的基本单位。对于英文一个Token大约对应0.75个单词对于中文一个字可能对应1-2个Token。当我们向模型发送一个请求时输入的提示词Prompt和模型返回的答案Completion共同消耗Token。约束主要体现在三个方面成本绝大多数商用API按Token数量计费。输入Input和输出Output通常分开计价。分析一个大型项目意味着极高的输入Token消耗。上下文长度每个模型都有固定的上下文窗口上限如4K、8K、16K、32K、128K甚至更长。即使不计成本超过这个限制的请求也无法被处理。性能与精度过长的输入会降低模型处理速度并可能因信息过载导致模型忽略关键细节影响分析结果的准确性。例如直接将一个包含100个文件、总计10万行代码的项目源码作为Prompt发送给一个上下文窗口为8K的模型是根本行不通的。1.2 CodeGraph从“文本序列”到“知识结构”传统方法将代码视为纯文本序列送入LLM这种方式效率低下因为它迫使模型重新“解析”代码结构。CodeGraph则预先完成了这一步解析工作。一个典型的CodeGraph可以包含以下节点和边节点包Package、模块Module、类Class、函数/方法Function/Method、变量Variable、字面量Literal等。边继承Inherits、实现Implements、包含Contains、调用Calls、被调用Called By、引用References、被引用Referenced By、赋值Assigns To等。通过构建CodeGraph我们可以压缩信息用“函数A调用函数B”这条边几个Token替代两个函数的完整源码可能上百个Token。精准定位当模型需要理解某个函数的逻辑时我们可以只提供该函数节点及其直接关联的子图如函数体、它调用的函数签名而非整个文件。支持复杂查询可以执行图查询例如“找到所有未被调用的函数”、“分析从入口点到敏感API的数据流路径”这些查询结果可以转化为极简的描述再喂给LLM。简单来说CodeGraph将代码的“结构知识”外化让LLM专注于需要“推理”和“理解”的部分从而避免了在重复解析代码结构上浪费宝贵的Token。2. 环境准备与工具选型要实现CodeGraph分析增强我们需要一套工具链来解析代码、构建图数据、执行查询和与LLM交互。2.1 核心工具与库以下是一个基于Python的推荐工具栈它平衡了能力与易用性编程语言Python 3.8代码解析与AST生成tree-sitter一个高效的增量式解析器生成工具和解析库支持多种语言Python, Java, JavaScript, Go, Rust等速度快适合构建生产级工具。libcst(用于Python)保留格式的Python源码解析器适合需要修改代码并保持格式的场景。标准库ast(用于Python)Python内置模块轻量但功能强大适合快速原型。图数据库/图计算库networkx纯Python的图论与复杂网络库易于上手适合中小规模代码库的分析和算法实验。Neo4j(通过py2neo驱动)专业的图数据库适合超大规模、需要持久化存储和复杂图查询的代码库分析。LLM交互openai/anthropic官方SDK用于调用商业API。langchain框架提供了与CodeGraph结合的高级抽象如GraphIndexCreator、GraphCypherQAChain等社区可能有相关实现或可借鉴思路。项目与依赖管理pip,venv,requirements.txt或poetry。2.2 项目初始化创建一个新的项目目录并安装核心依赖。# 创建项目目录 mkdir codegraph-token-optimizer cd codegraph-token-optimizer # 创建虚拟环境可选但推荐 python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # Linux/Mac: source venv/bin/activate # 创建 requirements.txt 并安装依赖 cat requirements.txt EOF tree-sitter networkx2.6 openai1.0.0 # 或其他LLM SDK python-dotenv # 用于管理API密钥 EOF pip install -r requirements.txt # 此外还需要下载 tree-sitter 的语言解析库以Python为例 git clone https://github.com/tree-sitter/tree-sitter-python # 后续代码中会演示如何加载3. 构建基础CodeGraph从源码到图结构我们以分析一个Python项目为例演示如何使用tree-sitter和networkx构建一个基础的调用关系图Call Graph。这是最常用的一种CodeGraph。3.1 使用Tree-sitter解析代码首先我们需要编写一个解析器它能从源代码中提取出函数定义和函数调用关系。# file: code_parser.py import os from tree_sitter import Language, Parser import networkx as nx # 加载Tree-sitter Python语言库 # 假设你已经将 tree-sitter-python 克隆到了项目根目录的 vendor 文件夹下 PYTHON_LANGUAGE_PATH ./vendor/tree-sitter-python PYTHON_LANGUAGE Language(PYTHON_LANGUAGE_PATH, python) class CodeGraphBuilder: def __init__(self): self.parser Parser() self.parser.set_language(PYTHON_LANGUAGE) self.graph nx.DiGraph() # 使用有向图 def parse_file(self, file_path): 解析单个文件提取函数定义和调用添加到图中 with open(file_path, r, encodingutf-8) as f: source_code f.read() tree self.parser.parse(bytes(source_code, utf-8)) root_node tree.root_node # 获取当前文件的模块名用于标识函数 module_name os.path.splitext(os.path.basename(file_path))[0] # 提取所有函数定义 function_defs self._extract_functions(root_node, source_code, module_name) # 将函数定义作为节点加入图 for func_name, func_info in function_defs.items(): node_id f{module_name}.{func_name} self.graph.add_node(node_id, **func_info) # 在每个函数定义节点内查找调用关系 for func_name, func_info in function_defs.items(): caller_id f{module_name}.{func_name} calls self._extract_calls_from_function(func_info[node], source_code, module_name, function_defs) for callee_id in calls: # 添加一条从调用者到被调用者的边 self.graph.add_edge(caller_id, callee_id, relationcalls) def _extract_functions(self, root_node, source_code, module_name): 从AST中提取函数定义 functions {} query PYTHON_LANGUAGE.query( (function_definition name: (identifier) func_name parameters: (parameters) params body: (block) body) func_def ) captures query.captures(root_node) func_def_node None for node, tag in captures: if tag func_def: func_def_node node elif tag func_name and func_def_node: func_name source_code[node.start_byte:node.end_byte] # 获取函数体文本用于后续可能的摘要生成 body_node func_def_node.child_by_field_name(body) body_text source_code[body_node.start_byte:body_node.end_byte] if body_node else functions[func_name] { name: func_name, module: module_name, node: func_def_node, body_preview: body_text[:200] ... if len(body_text) 200 else body_text, # 预览 start_line: func_def_node.start_point[0] 1, end_line: func_def_node.end_point[0] 1, } func_def_node None return functions def _extract_calls_from_function(self, func_node, source_code, module_name, local_functions): 从一个函数定义节点中提取它调用的其他函数 calls set() # 查询函数调用表达式 query PYTHON_LANGUAGE.query( (call function: (identifier) func_name) call_expr ) captures query.captures(func_node) for node, tag in captures: if tag func_name: called_func_name source_code[node.start_byte:node.end_byte] # 判断被调用函数是否在当前文件已定义 if called_func_name in local_functions: callee_id f{module_name}.{called_func_name} else: # 对于外部函数我们用一个通用标识符实际项目中需要更复杂的解析如导入分析 callee_id fexternal.{called_func_name} calls.add(callee_id) return list(calls) def build_graph_from_directory(self, directory_path): 递归遍历目录解析所有.py文件 for root, dirs, files in os.walk(directory_path): for file in files: if file.endswith(.py): file_path os.path.join(root, file) print(fParsing: {file_path}) try: self.parse_file(file_path) except Exception as e: print(fError parsing {file_path}: {e}) return self.graph def get_graph_info(self): 打印图的基本信息 print(fNumber of nodes (functions): {self.graph.number_of_nodes()}) print(fNumber of edges (calls): {self.graph.number_of_edges()}) # 可以计算入度/出度来分析函数重要性 print(\nTop 5 functions with most outgoing calls (fan-out):) out_degree dict(self.graph.out_degree()) for node, degree in sorted(out_degree.items(), keylambda x: x[1], reverseTrue)[:5]: print(f {node}: {degree} calls)3.2 构建并查看图创建一个示例项目目录和Python文件进行测试。# file: demo_project/main.py def entry_point(): 程序入口 data fetch_data() processed process_data(data) save_result(processed) def fetch_data(): return [1, 2, 3, 4, 5] def process_data(numbers): total sum_numbers(numbers) avg calculate_average(total, len(numbers)) return {total: total, average: avg} def sum_numbers(nums): return sum(nums) def calculate_average(total, count): if count 0: return 0 return total / count def save_result(result): print(fResult saved: {result})# file: demo_project/utils.py def helper_function(): print(Im a helper.) def another_helper(): helper_function() print(Another helper done.)现在运行我们的解析器来构建图。# file: build_demo_graph.py from code_parser import CodeGraphBuilder if __name__ __main__: builder CodeGraphBuilder() graph builder.build_graph_from_directory(./demo_project) builder.get_graph_info() # 可以简单可视化或导出图数据 # 1. 导出为GEXF格式可用Gephi等工具打开 nx.write_gexf(graph, code_graph.gexf) print(\nGraph exported to code_graph.gexf) # 2. 打印某个函数的调用链 print(\nCall chain for demo_project.main.process_data:) if demo_project.main.process_data in graph: print( Calls:, list(graph.successors(demo_project.main.process_data))) # 它调用了谁 print( Called by:, list(graph.predecessors(demo_project.main.process_data))) # 谁调用了它运行python build_demo_graph.py你会看到类似以下输出Parsing: ./demo_project/main.py Parsing: ./demo_project/utils.py Number of nodes (functions): 7 Number of edges (calls): 6 Top 5 functions with most outgoing calls (fan-out): demo_project.main.process_data: 2 calls demo_project.main.entry_point: 2 calls demo_project.utils.another_helper: 1 calls demo_project.main.save_result: 0 calls demo_project.main.fetch_data: 0 calls Graph exported to code_graph.gexf Call chain for demo_project.main.process_data: Calls: [demo_project.main.sum_numbers, demo_project.main.calculate_average] Called by: [demo_project.main.entry_point]至此我们已经成功将一个小型代码库转换为了一个结构化的调用关系图。这个图本身的数据量节点和边的列表远小于原始源代码的文本量。4. Token消耗优化策略基于CodeGraph的增强分析拥有了CodeGraph我们就可以设计一系列策略来优化LLM交互时的Token消耗。核心思想是用图查询代替全文发送用结构摘要代替代码粘贴。4.1 策略一语义压缩与摘要生成当LLM需要理解一个函数时我们不发送其完整的、可能很冗长的源代码而是发送一个由CodeGraph生成的语义摘要。这个摘要可以包括函数签名名称、参数、返回值类型如果语言支持。功能描述用一句话描述该函数做什么可以尝试用小型LLM或规则生成。调用关系它调用了哪些核心函数来自图。关键代码片段只提取核心逻辑行如循环、条件判断的主体省略样板代码。# file: graph_summarizer.py class GraphSummarizer: def __init__(self, graph): self.graph graph def generate_function_summary(self, node_id): 为一个函数节点生成文本摘要 if node_id not in self.graph.nodes: return fNode {node_id} not found in graph. node_data self.graph.nodes[node_id] summary_parts [] # 1. 基本信息 summary_parts.append(fFunction: {node_id}) # 这里可以尝试从docstring提取描述示例中我们用预览代替 if body_preview in node_data: # 一个非常简单的“描述”生成看函数名猜功能 func_name node_id.split(.)[-1] guessed_desc fPerforms operations related to {func_name}. summary_parts.append(fDescription: {guessed_desc}) # 2. 调用关系来自图 outgoing list(self.graph.successors(node_id)) incoming list(self.graph.predecessors(node_id)) if outgoing: summary_parts.append(fCalls: {, .join(outgoing[:5])}) # 限制数量 if incoming: summary_parts.append(fCalled by: {, .join(incoming[:5])}) # 3. 关键代码预览来自解析时存储的预览 if body_preview in node_data and node_data[body_preview]: summary_parts.append(fCode Preview:\npython\n{node_data[body_preview]}\n) return \n.join(summary_parts) def summarize_for_llm_query(self, central_node_id, depth1): 为一个中心节点及其周边生成用于LLM查询的浓缩上下文。 depth1 表示包含中心节点及其直接邻居。 if central_node_id not in self.graph: return # 使用BFS获取指定深度的子图节点 visited set([central_node_id]) queue [(central_node_id, 0)] nodes_to_include set([central_node_id]) while queue: current_node, current_depth queue.pop(0) if current_depth depth: continue for neighbor in self.graph.successors(current_node): if neighbor not in visited: visited.add(neighbor) queue.append((neighbor, current_depth 1)) nodes_to_include.add(neighbor) for neighbor in self.graph.predecessors(current_node): if neighbor not in visited: visited.add(neighbor) queue.append((neighbor, current_depth 1)) nodes_to_include.add(neighbor) # 为这些节点生成摘要并拼接 context_parts [f# Code Context for analyzing {central_node_id} (Depth{depth})] for node in nodes_to_include: context_parts.append(---) context_parts.append(self.generate_function_summary(node)) full_context \n.join(context_parts) # 估算Token数近似值 estimated_tokens len(full_context) // 4 print(fGenerated context length: ~{estimated_tokens} tokens (approx).) print(fOriginal code for these functions would be much larger.) return full_context使用示例# file: test_summarizer.py from code_parser import CodeGraphBuilder from graph_summarizer import GraphSummarizer builder CodeGraphBuilder() graph builder.build_graph_from_directory(./demo_project) summarizer GraphSummarizer(graph) # 为 process_data 函数生成深度为1的上下文 context summarizer.summarize_for_llm_query(demo_project.main.process_data, depth1) print(context)输出将是一个结构化的文本摘要包含了process_data、sum_numbers、calculate_average和entry_point函数的关键信息但其文本量远小于这四个函数的完整源代码。这个摘要可以直接作为Prompt的一部分发送给LLM使其快速理解该函数的上下文。4.2 策略二增量式与聚焦式分析很多代码分析任务不需要一次性理解整个项目。CodeGraph支持我们进行增量式和聚焦式的交互。场景LLM作为助手回答开发者关于代码的特定问题。流程开发者提问“process_data函数里如果传入空列表会怎样”系统通过CodeGraph定位到process_data节点。系统发现process_data调用了calculate_average。系统查看calculate_average的摘要发现其中有if count 0:的判断。系统将process_data的摘要和calculate_average的摘要特别是条件判断部分组合成Prompt发送给LLM。LLM基于这个高度相关的、Token极少的上下文给出精准回答“会返回{total: 0, average: 0}因为calculate_average函数对count为0的情况做了处理返回0。”这种方式避免了将main.py甚至整个项目的代码都发送给LLM。4.3 策略三图查询先行LLM润色后行对于许多结构化问题完全可以先用图查询算法得出答案再让LLM将其转化为自然语言。问题“帮我找出项目中所有未被任何其他函数调用的‘死代码’函数。”传统LLM方式发送大量代码让LLM通读并判断。Token消耗巨大且可能出错。CodeGraph增强方式在图数据库如Neo4j中执行一个简单的Cypher查询MATCH (f:Function) WHERE NOT (:Function)-[:CALLS]-(f) RETURN f.name。或者用networkx计算入度为0的节点排除入口点等。瞬间得到结果列表[demo_project.utils.helper_function]假设只有它未被调用。将这个结果列表和问题一起用极少的Token发送给LLM“根据图分析以下函数是未被调用的helper_function。请为开发者生成一个清晰的报告说明这个发现并建议是否可以考虑删除或检查其用途。”LLM基于这个明确的结果生成友好、专业的回答。这种方法将计算密集型、确定性的代码结构分析交给专门的图算法LLM只负责最擅长的语言生成和解释工作分工明确效率极高。5. 与LLM集成实战构建一个智能代码问答系统我们将上述策略整合构建一个简单的命令行智能代码问答系统原型。# file: code_qa_system.py import os from typing import List from code_parser import CodeGraphBuilder from graph_summarizer import GraphSummarizer from openai import OpenAI # 示例使用OpenAI API需配置API_KEY from dotenv import load_dotenv load_dotenv() # 从 .env 文件加载环境变量 class CodeQASystem: def __init__(self, codebase_path): print(Building CodeGraph...) self.builder CodeGraphBuilder() self.graph self.builder.build_graph_from_directory(codebase_path) self.summarizer GraphSummarizer(self.graph) self.client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) print(CodeGraph ready.) def _find_relevant_nodes(self, question: str) - List[str]: 一个简单的基于关键词的节点查找。 在实际系统中这里应该用更高级的语义搜索如嵌入向量相似度。 question_lower question.lower() relevant_nodes [] for node in self.graph.nodes(): if question_lower in node.lower(): relevant_nodes.append(node) # 如果没找到返回一些中心节点如出度高的 if not relevant_nodes: # 简单返回图的前几个节点 relevant_nodes list(self.graph.nodes())[:3] return relevant_nodes[:3] # 限制返回数量 def answer_question(self, question: str) - str: 回答关于代码库的问题。 1. 找到相关问题节点。 2. 为这些节点生成浓缩上下文。 3. 组合Prompt调用LLM。 4. 返回答案。 # 1. 查找相关节点 central_nodes self._find_relevant_nodes(question) if not central_nodes: return I couldnt find any specific functions mentioned in your question. # 2. 为每个相关节点生成上下文深度1 all_context_parts [] for node in central_nodes: context self.summarizer.summarize_for_llm_query(node, depth1) all_context_parts.append(context) full_context \n\n.join(all_context_parts) # 3. 构建Prompt system_prompt You are an expert software engineer analyzing a codebase. Use the provided structured code context (function summaries, call relationships) to answer the users question accurately and concisely. If the context does not contain enough information to answer fully, state what is missing. user_prompt fCode Context: {full_context} Question: {question} Please answer based solely on the context above. # 估算Token并打印实际调用API前 total_chars len(system_prompt) len(user_prompt) print(f[DEBUG] Estimated prompt tokens: ~{total_chars // 4}) # 4. 调用LLM (这里模拟一个响应实际需要调用API) # 注意为了示例可运行我们模拟一个回答。实际使用时请取消注释下面的API调用。 # try: # response self.client.chat.completions.create( # modelgpt-4o-mini, # 或 gpt-3.5-turbo # messages[ # {role: system, content: system_prompt}, # {role: user, content: user_prompt} # ], # temperature0.2, # max_tokens500 # ) # answer response.choices[0].message.content # except Exception as e: # answer fError calling LLM API: {e} # 模拟回答 answer fBased on the provided context about functions like {central_nodes[0]}: The function process_data calls sum_numbers and calculate_average. The calculate_average function contains a guard clause if count 0: return 0, which prevents division by zero. Therefore, if an empty list is passed to process_data, the count will be 0, and calculate_average will return 0. The sum_numbers function will return 0 for an empty list. So the final result would be {{total: 0, average: 0}}. This indicates the code handles the edge case of empty input gracefully. return answer if __name__ __main__: # 假设代码库路径 CODEBASE_PATH ./demo_project qa_system CodeQASystem(CODEBASE_PATH) while True: user_question input(\nAsk a question about the codebase (or quit): ) if user_question.lower() in [quit, exit]: break if not user_question.strip(): continue print(\n *50) print(Thinking...) answer qa_system.answer_question(user_question) print(fAnswer:\n{answer}) print(*50)这个系统演示了核心工作流解析代码为图 - 根据问题定位相关子图 - 生成摘要上下文 - 构造高效Prompt - 获取LLM答案。整个过程中发送给LLM的文本是高度压缩和结构化的Token消耗得到有效控制。6. 常见问题与排查思路在实现CodeGraph分析和Token优化策略时你可能会遇到以下典型问题。问题现象常见原因解决思路Tree-sitter解析失败或报错1. 语言库未正确编译或加载。2. 源代码语法不符合规范语法错误。3. 使用了该语言不支持的语法特性新版本。1. 检查Language库路径是否正确确保.so/.dylib/.dll文件存在。2. 先用标准语法解析器如Python的ast检查代码是否有语法错误。3. 确认使用的tree-sitter语言库版本是否支持你的代码特性。构建的图缺失部分调用关系1. 解析查询Query编写不完整未能捕获所有调用类型如方法调用obj.method()、类调用Class()、属性调用等。2. 未处理跨文件/模块的导入import关系。1. 完善Tree-sitter查询覆盖更多语法模式。参考对应语言的官方查询文档。2. 增加导入分析阶段解析import语句建立跨文件的符号映射将调用与被调用函数正确关联到其定义的模块节点。LLM基于摘要的回答不准确1. 生成的摘要丢失了关键信息如复杂的条件逻辑、循环边界。2. 上下文深度depth设置过小遗漏了必要的间接关联函数。1. 优化摘要生成策略对于复杂函数不要只截取前几行可以尝试提取AST中的关键语句节点如if, for, while, return。2. 动态调整分析深度对于问题中提到的函数可以尝试 depth2或者实现一个启发式方法根据函数的复杂度如圈复杂度决定摘要的详细程度。图规模过大导致内存/性能问题分析超大型项目如Linux内核时全量图可能包含数百万个节点和边。1.分层/分模块分析不要一次性构建整个项目的图。按模块、包或目录分别构建子图按需加载。2.使用专业图数据库将图数据存储到Neo4j或JanusGraph中利用其索引和分布式能力。3.采样分析对于初步探索可以只分析入口点相关的子图。Token节省效果不明显1. 摘要生成得太冗长几乎等同于原代码。2. 问题本身就需要全局上下文如“请概括整个项目的架构”。1. 强化摘要的压缩性使用更简洁的模板用符号代替长名称省略无关紧要的细节。2. 对于全局性问题CodeGraph可以提供架构图摘要只发送模块/包级别的依赖图、主要类及其关系而不是所有函数细节。这依然比发送全部源码节省大量Token。7. 最佳实践与工程建议将CodeGraph分析集成到生产级应用中需要考虑更多工程细节。增量更新与缓存代码库是不断变化的。每次提交都重新解析整个项目成本高昂。实现增量解析利用tree-sitter的增量解析能力只解析发生变更的文件并增量更新图结构。建立缓存将构建好的CodeGraph序列化如使用pickle或存储到图数据库并缓存。为每个文件版本或提交哈希存储对应的图快照。混合策略与降级方案CodeGraph不是万能的。对于某些极其复杂或高度依赖具体实现的逻辑问题LLM可能仍然需要查看部分原始代码。设计混合策略系统优先使用CodeGraph摘要。如果LLM返回的答案置信度低可通过提示工程让LLM输出置信度或用户明确要求“显示具体代码”则系统可以按需附上原始代码片段。提供降级路径始终保留一个“回退”模式当图分析服务不可用时能降级到传统的基于全文检索或简单AST分析的方法。安全与边界输入验证确保解析的代码来源可信防止通过恶意构造的代码进行路径遍历或注入攻击。资源隔离解析第三方或用户上传的代码应在沙箱环境中进行限制其内存、CPU和网络访问。敏感信息过滤在生成摘要或发送到LLM前对代码进行扫描过滤掉硬编码的密码、API密钥、内部IP等敏感信息。评估与监控定义评估指标衡量优化效果不能只看Token数。需要监控平均每次问答的Token消耗输入输出。问答准确率/用户满意度通过反馈或人工评估。系统响应延迟图查询LLM调用的总时间。A/B测试可以对比“纯CodeGraph摘要”和“CodeGraph摘要部分源码”两种策略在不同类型问题上的效果持续优化策略选择算法。扩展性与多语言支持抽象解析接口将CodeGraphBuilder设计为支持多语言后端的抽象类。为每种语言实现特定的解析器使用tree-sitter对应语言库。统一图模型定义一套通用的、语言无关的图节点和边类型如Function,Class,Calls,Inherits不同语言的解析器都将代码映射到这个统一模型上。这样上层的分析和查询逻辑就可以与语言解耦。通过将CodeGraph分析与LLM智能结合我们能够在代码理解、智能问答、代码审查、架构分析等场景中实现精度与效率的平衡。Token消耗的优化不是目的而是实现更强大、更实时、更经济的AI编程工具的手段。希望本文提供的思路和代码示例能帮助你启动自己的项目并在此基础上探索出更优的解决方案。下一步你可以尝试集成更强大的图查询语言如Cypher、引入向量数据库进行语义检索或者探索如何用小型、专用的模型来替代部分摘要生成工作从而构建一个完全自主、高效、低成本的代码智能分析系统。