code-review-graph Python调用解析深潜Jedi增强如何让调用边更准确【免费下载链接】code-review-graphLocal-first code intelligence graph for MCP and CLI. Builds a persistent map of your codebase so AI coding tools read only what matters, with benchmarked context reductions on reviews and large-repo workflows.项目地址: https://gitcode.com/GitHub_Trending/co/code-review-graphcode-review-graph 是一个本地优先的代码智能图谱工具支持 MCP 与 CLI它为代码库构建持久化的调用关系地图让 AI 编程工具只读取真正相关的内容。其中Python 调用解析的准确性直接决定了改动影响范围blast radius分析的可信度。本文将深潜其源码解析 Jedi 静态分析增强是如何把 tree-sitter 解析阶段丢掉的调用边找回来、并保证新边不出错、不越界的。为什么纯 AST 解析会丢边code-review-graph 的底座是 tree-sitter 语法解析见 parser.py。对 Python 方法调用解析器采用了一套保守策略只保留高置信度的调用self.xxx()/cls.xxx()/super.xxx()—— 接收者是明确的实例SomeClass.xxx()—— 大写开头的接收器通常指向类名。而svc.authenticate()这类小写变量接收者的调用会被直接丢弃。原因是svc可能来自svc factory()静态 AST 无法推断factory的返回类型解析器宁可丢边也不造边。问题在于这类工厂模式 依赖注入的写法在 Python 项目里极其常见。丢掉的每一条调用边都意味着图谱中一段看不见的依赖链。Jedi 增强构建后补齐丢失的调用边解决方案在 jedi_resolver.py 中。Jedi 是 Python 生态成熟的静态分析库项目依赖声明为jedi0.19.2见 pyproject.toml它擅长跨文件追踪类型。code-review-graph 把它设计为构建后post-build增强步骤核心函数是enrich_jedi_calls()。第一步精准找出被丢弃的调用增强步骤不是盲目地问 Jedi 解析所有调用而是先重走一遍 tree-sitter 语法树_find_untracked_method_calls()按与主解析器完全一致的标准筛选接收者是小写标识符非self/cls/super的receiver.method()调用测试文件跳过——测试文件在主解析阶段已全量跟踪调用。同时还有一个性能闸门只有当方法名在项目已索引的函数节点中真实存在时才值得请求 Jedi 解析。logger.get_logger()这种项目内根本没有的定义会被直接略过。第二步Jedi 跨文件追踪返回类型对筛选出的待解析调用每个文件只创建一个jedi.Script实例然后对每个候选调用执行script.goto(line, col)。Jedi 会沿赋值链如svc factory()→factory返回AuthService跨文件追踪定位到方法真正的定义位置。解析成功后目标会规范化为限定名格式文件路径::ClassName.method或文件路径::func并以CALLS边写入图谱数据库。第三步三重保险保证新边不越界Jedi 增强在敢加边之前做了三层防护这也是它和粗暴补边方案的关键区别项目内限定Jedi 解析出的定义若不在仓库根目录内relative_to(repo_root)校验失败直接丢弃——第三方库调用不进图谱去重已存在的CALLS边按来源函数 行号匹配不会被重复插入项目范围收敛Jedi 项目被限定到所有 Python 文件的公共父目录多语言 monorepo 中的node_modules、TS 源码不会被拖进初始化扫描。最终返回的统计只有三个字段resolved补回多少条边、files多少文件被增强、errors加载失败数。与 Python 导入解析的分工Jedi 增强解决的是CALLS 边谁调用了谁而 python_resolver.py 中的resolve_python_imports()解决的是IMPORTS_FROM 边谁依赖了谁它按仓库内唯一路径后缀匹配模块导入无法唯一确定时会把候选文件列表写进边属性import_candidates状态标记为ambiguous而非硬猜。两条解析线都在构建流水线末尾执行——全量构建incremental.py和增量更新都会触发 Python 导入解析Jedi 调用增强则作为独立的 post-build 步骤运行。相关行为由 test_python_reachability.py 等测试守护。补回的调用边如何变成实际收益图谱中每一条准确的CALLS边都会向下游能力传导影响范围分析改一个函数前图谱能列出完整的调用方链条而不是只有文本搜索能看到的调用增量更新依赖文件发现find_dependents基于导入/调用边丢边会导致该重新解析的文件被漏掉流程见 incremental.py上下文增强AI 工具读取文件时自动附带的 Called by / Calls 上下文直接来自这些边。快速上手开启 Jedi 增强Jedi 是可选依赖通过enrichment附加包安装说明见 docs/TROUBLESHOOTING.mdpip install code-review-graph[enrichment]安装后构建 Python 项目时增强步骤自动生效未安装时模块会优雅跳过日志提示 Jedi not installed, skipping Python enrichment不影响基础图谱。总结code-review-graph 的 Python 调用解析是一个典型的保守解析 语义增强架构tree-sitter 打底快速、多语言、高置信度宁可丢边不造边Jedi 补边用跨文件类型追踪找回工厂模式等场景的调用边多重防护项目内限定、方法名预过滤、行级去重确保补回的每一条边都可靠。这套设计让代码图谱在构建速度与调用边准确性之间取得了平衡——对依赖调用方是谁做影响分析、代码审查的 AI 工作流来说这正是最核心的质量保障。【免费下载链接】code-review-graphLocal-first code intelligence graph for MCP and CLI. Builds a persistent map of your codebase so AI coding tools read only what matters, with benchmarked context reductions on reviews and large-repo workflows.项目地址: https://gitcode.com/GitHub_Trending/co/code-review-graph创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 code-review-graph Python调用解析深潜：Jedi增强如何让调用边更准确
code-review-graph Python调用解析深潜Jedi增强如何让调用边更准确【免费下载链接】code-review-graphLocal-first code intelligence graph for MCP and CLI. Builds a persistent map of your codebase so AI coding tools read only what matters, with benchmarked context reductions on reviews and large-repo workflows.项目地址: https://gitcode.com/GitHub_Trending/co/code-review-graphcode-review-graph 是一个本地优先的代码智能图谱工具支持 MCP 与 CLI它为代码库构建持久化的调用关系地图让 AI 编程工具只读取真正相关的内容。其中Python 调用解析的准确性直接决定了改动影响范围blast radius分析的可信度。本文将深潜其源码解析 Jedi 静态分析增强是如何把 tree-sitter 解析阶段丢掉的调用边找回来、并保证新边不出错、不越界的。为什么纯 AST 解析会丢边code-review-graph 的底座是 tree-sitter 语法解析见 parser.py。对 Python 方法调用解析器采用了一套保守策略只保留高置信度的调用self.xxx()/cls.xxx()/super.xxx()—— 接收者是明确的实例SomeClass.xxx()—— 大写开头的接收器通常指向类名。而svc.authenticate()这类小写变量接收者的调用会被直接丢弃。原因是svc可能来自svc factory()静态 AST 无法推断factory的返回类型解析器宁可丢边也不造边。问题在于这类工厂模式 依赖注入的写法在 Python 项目里极其常见。丢掉的每一条调用边都意味着图谱中一段看不见的依赖链。Jedi 增强构建后补齐丢失的调用边解决方案在 jedi_resolver.py 中。Jedi 是 Python 生态成熟的静态分析库项目依赖声明为jedi0.19.2见 pyproject.toml它擅长跨文件追踪类型。code-review-graph 把它设计为构建后post-build增强步骤核心函数是enrich_jedi_calls()。第一步精准找出被丢弃的调用增强步骤不是盲目地问 Jedi 解析所有调用而是先重走一遍 tree-sitter 语法树_find_untracked_method_calls()按与主解析器完全一致的标准筛选接收者是小写标识符非self/cls/super的receiver.method()调用测试文件跳过——测试文件在主解析阶段已全量跟踪调用。同时还有一个性能闸门只有当方法名在项目已索引的函数节点中真实存在时才值得请求 Jedi 解析。logger.get_logger()这种项目内根本没有的定义会被直接略过。第二步Jedi 跨文件追踪返回类型对筛选出的待解析调用每个文件只创建一个jedi.Script实例然后对每个候选调用执行script.goto(line, col)。Jedi 会沿赋值链如svc factory()→factory返回AuthService跨文件追踪定位到方法真正的定义位置。解析成功后目标会规范化为限定名格式文件路径::ClassName.method或文件路径::func并以CALLS边写入图谱数据库。第三步三重保险保证新边不越界Jedi 增强在敢加边之前做了三层防护这也是它和粗暴补边方案的关键区别项目内限定Jedi 解析出的定义若不在仓库根目录内relative_to(repo_root)校验失败直接丢弃——第三方库调用不进图谱去重已存在的CALLS边按来源函数 行号匹配不会被重复插入项目范围收敛Jedi 项目被限定到所有 Python 文件的公共父目录多语言 monorepo 中的node_modules、TS 源码不会被拖进初始化扫描。最终返回的统计只有三个字段resolved补回多少条边、files多少文件被增强、errors加载失败数。与 Python 导入解析的分工Jedi 增强解决的是CALLS 边谁调用了谁而 python_resolver.py 中的resolve_python_imports()解决的是IMPORTS_FROM 边谁依赖了谁它按仓库内唯一路径后缀匹配模块导入无法唯一确定时会把候选文件列表写进边属性import_candidates状态标记为ambiguous而非硬猜。两条解析线都在构建流水线末尾执行——全量构建incremental.py和增量更新都会触发 Python 导入解析Jedi 调用增强则作为独立的 post-build 步骤运行。相关行为由 test_python_reachability.py 等测试守护。补回的调用边如何变成实际收益图谱中每一条准确的CALLS边都会向下游能力传导影响范围分析改一个函数前图谱能列出完整的调用方链条而不是只有文本搜索能看到的调用增量更新依赖文件发现find_dependents基于导入/调用边丢边会导致该重新解析的文件被漏掉流程见 incremental.py上下文增强AI 工具读取文件时自动附带的 Called by / Calls 上下文直接来自这些边。快速上手开启 Jedi 增强Jedi 是可选依赖通过enrichment附加包安装说明见 docs/TROUBLESHOOTING.mdpip install code-review-graph[enrichment]安装后构建 Python 项目时增强步骤自动生效未安装时模块会优雅跳过日志提示 Jedi not installed, skipping Python enrichment不影响基础图谱。总结code-review-graph 的 Python 调用解析是一个典型的保守解析 语义增强架构tree-sitter 打底快速、多语言、高置信度宁可丢边不造边Jedi 补边用跨文件类型追踪找回工厂模式等场景的调用边多重防护项目内限定、方法名预过滤、行级去重确保补回的每一条边都可靠。这套设计让代码图谱在构建速度与调用边准确性之间取得了平衡——对依赖调用方是谁做影响分析、代码审查的 AI 工作流来说这正是最核心的质量保障。【免费下载链接】code-review-graphLocal-first code intelligence graph for MCP and CLI. Builds a persistent map of your codebase so AI coding tools read only what matters, with benchmarked context reductions on reviews and large-repo workflows.项目地址: https://gitcode.com/GitHub_Trending/co/code-review-graph创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考