Graphify：把代码库变成一张知识图谱，不依赖向量库

Graphify 是一个把代码库整理成可查询知识图谱的工具，代码、文档、SQL Schema、配置和 PDF 都能进。

做法

代码部分用 Tree-sitter AST 在本地解析，不依赖向量库。每条关系还会标明是直接从源码提取的，还是后续推断出来的。

为什么这个区分重要

编码智能体在大型项目里最费时间的动作是反复搜文件、找定义、追调用关系。向量检索解决的是文本相似，但代码的语义主要在结构里——谁调了谁、哪个类型从哪来、这个配置项被谁读。这些关系用图表达比用向量表达精确得多。

而标注关系来源这件事更关键：直接从 AST 提取的是硬事实，推断出来的是猜测。混在一起看，智能体会把猜测当事实用，最后给出看起来合理但完全错的结论。

能做什么

生成后可以查节点、追踪路径，能直接接入 Claude Code、Cursor、Codex 这类工具。典型用法是问它某个函数的影响面：改这里会波及哪些调用链、哪些测试覆盖了它。

适用边界

大仓库收益明显，小项目反而是负担——建图的成本比直接读文件高。另外它不解决动态分发、反射、依赖注入这些静态分析看不见的路径，遇到这类代码要接受图是不完整的。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

标出关系来源这件事最关键，语法树提取的是硬事实，推断出来的是猜测，混在一起看智能体会把猜测当事实用。它解决不了动态分发和反射，遇到这类代码要接受图是不完整的，别当真理用。

区分源码提取和推断出来的关系，这个设计很关键。图谱最怕推断边被当成事实，查调用链越查越远，最后指向一堆不存在的依赖。Tree-sitter 本地解析不依赖向量库也合理，代码语义本来就在结构里。想问增量更新怎么做，改一个文件要不要全量重解析。

不依赖向量库这个选择是对的。代码检索里最贵的不是找相似文本，是追调用链和类型来源，这部分用图确实比 embedding 精确。我更关心增量更新：代码库天天在变，AST 全量重解析的成本和图局部更新策略，这个决定了它能不能接进 CI。