阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/graphify-knowledge-graph/ 「芋道源码」欢迎转载，保留摘要，谢谢！

• 它的答案，是先把项目翻译成一张能查的图
• 钱主要花在代码以外的地方
• 图和 grep 最大的不同，每条关系都能交代出处
• 官方把跑分放出来了，数字比宣传语实在
• 两条命令上手，但先说三个容易踩的坑
• 什么时候值得装，什么时候别折腾

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

先说一个 AI 编程助手都躲不过的时刻。让它改老项目里的一个功能，它读了七八个文件，token 花掉一大截，最后改出来的代码调了一个早就没人用的函数。

它不是不聪明，只是不知道这个项目里谁调用谁、谁依赖谁。

它手里只有 grep 和关键词匹配，匹配到的是「这个名字出现在哪一行」，回答不了「这两个东西之间是什么关系」。仓库越大，这个差别越致命。

今年 4 月开源的一个项目想换个思路，到现在 GitHub 上攒了十二万上下的 Star。

它的答案，是先把项目翻译成一张能查的图

Graphify 不是独立软件，它是装进 AI 编程助手里的一个技能。装好以后在助手里敲一句 /graphify，它就从头到尾扫一遍当前项目，扫完给你一张知识图谱。

这张图是实实在在的文件。跑完项目里会多出一个 graphify-out 目录，里面只有三个东西。graph.html 点开就能看、能筛选能搜索，GRAPH_REPORT.md 是重点摘要，graph.json 是完整数据，之后随时能查。

有一个容易混的地方，它跟向量检索不是一回事。向量检索返回「长得像」的内容，回答不了关系。它的做法更笨也更硬，先把节点和边建出来，图结构自己就是相似信号，不需要再养一个向量库。

建图时它还会顺手做两件事。一件是找出 god nodes，也就是连接数最多的那批概念，整个项目干什么基本绕不开它们。另一件是拿 Leiden 算法按连接密度把图切成一个个子系统，每个子系统自动起名，在页面里可以一块一块地看。

钱主要花在代码以外的地方

省钱这件事值得单独说。代码文件全部走 tree-sitter 语法树解析，整个过程不碰大模型，代码也不出本机。只建代码这部分的图，一分钱 API 费用都不用花。

真正需要模型参与的，是文档、PDF 和图片。官方把这个过程拆成三趟，代码结构一趟全部在本地跑完，音视频用 faster-whisper 在本机转写成文字，转写出来的文字才和文档一起交给模型做语义抽取。

但这里有个官方材料自己没对齐的地方。README 的文件表列了 37 个 tree-sitter 语法，能力表写「约 40 种语言」，另一篇 how-it-works 文档写 25 种。三个数不影响结论，但值得心里有数。

图和 grep 最大的不同，每条关系都能交代出处

图里的每一条边都挂着标签。EXTRACTED 说的是这个关系在源码里直接写着，INFERRED 说的是工具自己推出来的，报告里还有一类 AMBIGUOUS，是工具自己也拿不准的边。真去查问题的时候，哪些是实打实的、哪些还得再看一眼，扫一遍标签就分得清。

查东西主要靠三个命令。query 接大白话的问题，返回一块相关的子图。path 用来看两个东西中间是怎么连起来的。explain 解释一个概念和它周围一圈的关系。

官方举的例子是拿 FastAPI 的图问 APIRouter，结果里能看到它出自 routing.py 第 2210 行，连着 47 个节点，每条边都带来源标签。一份能追问出处的项目关系说明书，才是它真正交到 AI 手里的东西。

官方把跑分放出来了，数字比宣传语实在

大多数项目只说一句「效果不错」，这个项目把跑分表放进了仓库。LOCOMO 数据集三百条样本上，它的 recall@10 是 0.497，mem0 只有 0.048，supermemory 是 0.149，传统 BM25 是 0.362。

QA 准确率它拿到 45.3%，比 mem0 的 27.3% 高出一大截，比 supermemory 的 49.7% 低 4.4 个点。看着是输了，可官方把账单一起放了出来，supermemory 那次 ingest 花了 15.67 美元，graphify 是 1.40 美元。

而且 supermemory 的召回率官方自己标了「被嵌入模型混淆」，它锁死了 768 维英文嵌入模型，QA 那一栏才是干净比较。LongMemEval-S 这项它是 76%，和 dense RAG 并列第一。

这些数字值不值得信，还取决于怎么评分。官方用的是同一套 harness、同一个模型、同样的预算，评委还做了盲验，和第二位独立评委一致率 90.6%，Cohen’s kappa 0.81。

两条命令上手，但先说三个容易踩的坑

环境里有个 Python 3.10 以上就行，核心就两条命令。

uv tool install graphifyy
graphify install

第一条把命令行工具装上，第二条把它注册给你的 AI 助手。装完在助手里敲 /graphify . 就开始建图。成功信号很好认，项目根目录下出现 graphify-out，里面躺着那三个文件。

第一个坑在包名。PyPI 上的包叫 graphifyy，两个 y，其他叫 graphify 什么什么的都跟官方没关系，装完以后命令仍然叫 graphify。想用 uvx 临时跑一次得写成 uvx --from graphifyy graphify install，直接敲 uvx graphify 会报错。

平台差异是第二个。Windows 的 PowerShell 里要写 graphify .，不能带那个斜杠，它会被当成路径分隔符。

第三个最常见，装完提示 command not found，多半是工具目录没进 PATH，跑一句 uv tool update-shell 再开个新终端就好。平时用中文提问多的，建议顺手装上 graphifyy[chinese]，它带 jieba 分词。

建完想改行为不用重来，只看代码用 --code-only，重新聚类用 --cluster-only，不生成页面用 --no-viz，都可以用大白话跟助手说。

什么时候值得装，什么时候别折腾

官方在代码智能上也留了实测。测试仓库是 ERPNext，一个大约一百万行的生产项目。只给助手 grep 和读文件，关键事实覆盖率是 70.8%，给它一个 graphify 工具，覆盖率升到 82.0%。

这个数字比任何形容词都有用。反过来把整个仓库塞进上下文那种做法，token 大约是它的二十倍，覆盖率反而更低。

图也不是建一次就扔那。改过的文件可以增量更新，装一个 git hook 之后，每次 commit、切分支它都自己重建。有一件事容易漏掉，graphify-out 默认在 gitignore 里，想让团队共用得手动把 graph.json 和 GRAPH_REPORT.md 拎出来提交，不然同事 clone 下来是没有图的。

接别的工具也简单，图能起成 MCP 服务或者 HTTP 服务，整个团队共用一个地址。它另外还有个 PR 看板，能看出哪些 PR 撞在同一个子系统上，合并顺序要小心。

我的判断是这样。项目上到几千个文件、新人接手要摸清架构、或者团队想把结构摊开共享，它很值；几十个文件的小项目就别折腾了，直接让 AI 读文件更快。还有一条边界要提前想好，代码以外的东西要花额度，PDF 和文档堆得多的仓库，建图那一步会有账单。