Graphify 将代码库转化为知识图谱，助你快速理清项目结构与核心逻辑。
核心内容：
1. Graphify工具与Claude的集成使用方法
2. 使用Go语言sync.map包进行效果验证
3. Graphify构建知识图谱的过程与输出结果

Graphify 是一个开源的知识图谱构建工具，将知识库转换为知识图谱，来帮助AI 更好地理解项目结构。我会想，这个东西的作用究竟有多大？至少它并没有在我的工作域流行起来。

按照仓库 README 我们先安装 graphify，建议我们先安装 uv 工具，它是下一代 Python 工具链，旨在替代传统的 pip。uv 是使用 rust 开发的，是用新的语言实现了一遍旧的功能吗？

uv tool install graphifyy

这里安装的是 graphifyy，最后是双y，主要是 graphify 单词已经被占用了。如果名称被抢占的话，开源项目有一套常见的命名策略，这可能也算是其中的一种。

现在我们将 graphify 注册到 claude 中，在 claude 通过技能来使用它。这里可以有两种安装选项，一个是用户维度的，另一个是项目维度的。安装后的效果如图（在控制台我习惯展示3个窗口，安装位于最右边）

graphify installgraphify install --project

在 claude 命令行输入 /graphify 就可以正常触发，它既可以借助大模型来构建关系图，也可以直接基于语法树来构建。当务之急是找一个代码库来验证一下效果。当然 graphify 在自我介绍中这么说：

Turn any folder of code, SQL schemas, R scripts, shell scripts, docs, papers, images, or videos into a queryable knowledge graph.

人家的定位可不仅仅是代码，只用来解决代码就太局限了。现在用代码来验证下效果当然可以。找一个 Go 语言的开源库算是比较靠谱的，阅读到这里的读者大多都和编程有点关系。

将 Go 的源码下载到本地，我们将分析目标局限在一个具体的包上。选择一个比较常用的 sync.map 的代码包分析，让大模型帮我们解释下，sync map 是如何来解决读写冲突问题的

git clone [email protected]:golang/go.git

对于这类底层工具包，目录下的每个文件都代表了一种独立功能，文件和文件之间的关系非常简单，所以，我们通过 graphify 是想更加聚焦单个文件内部，我们要对这个目录构建知识图谱，但我们只想分析其中的 map.go 文件

在目录下启动 claude，然后在命令行触发 graphify，系统开始执行，模型在不断地推理、执行、反思、再执行、经过了多次的问题修复，最终输出了：Graph: 658 nodes, 1369 edges, 38 communities 的效果图

No existing graph found. I will build the knowledge graph from the current directory

图谱底层生成采用的是社区检测算法，很明显，sync.map 的社区比较独立，和它相关的节点就是几个对应的函数，这个包确实不太适合来做分析。这个图中其实还有一个关键信息：置信度。

图的每条边上都有一个自信度的标记，Graphify 在提取实体和关系时使用三种置信度标记，分别是EXTRACTED (高置信度)、INFERRED (中等置信度) 、AMBIGUOUS (低置信度) ，这样的等级划分其实是可以参考的。

运行之后当前目录下生成了 graphify-out 文件夹，这几个文件。你可以打开 graph.html 查看可视化图谱（如上图），或根据 GRAPH_REPORT.md 中的建议问题探索代码库结构。

使用基础的 query 命令查询 map，对比命令行直接执行和在大模型中执行的效果。根据左侧命令的输出，程序使用广度优先搜索 (Breadth-First Search) 进行遍历。右侧是大模型的结果，直接输出了大模型处理后的结果。

然后我对比一个贴近工作语义的问题，直接在大模型中输入：sync.map是如何解决并发读写问题的 vs /graphify sync.map 是如何解决并发读写问题的。后者的数据结果主要基于 /graphify 召回的节点进行分析。

我们发现，graphify 在这个场景解决的是召回率的问题，结合生成的图谱，可以快速召回相关的数据。相比于 RAG 在构建知识库是文本固定切块，块与块之间保留一部分内部重合的模式，graphify 数据的召回内容相关性更好。

登录查看剩余 70% 内容