Graphify 把文件夹变成知识图谱，但 71.5x 需要前提

Graphify 本周涨了大约 7,300 颗 star，一下挤进 GitHub 周榜前列，总数突破 137,000。它的卖点只有一句话：把编码 agent 指向一个文件夹，敲下 /graphify .，就能拿回这个文件夹里所有内容的知识图谱。

真正有意思的不是图谱本身，而是挂在它旁边的那个数字：相比直接读原始文件，每次查询的 token 消耗少了 71.5x。如果这个结论能够普遍成立，它就不是一个顺手的小工具，而是改变了 agent 需要承载多少上下文这件事。

它从哪来

作者 safishamsi 把这个项目描述成对 Andrej Karpathy 某个习惯的回应：Karpathy 有一个 /raw 文件夹，论文、推文、截图、笔记全往里丢，然后再也找不到东西。这个问题很多人都能共情，而且这个起源故事比大多数都诚实，因为它描述的是一个失败模式，而不是一个市场。

它宣称的目标比"搜索你的文档"要窄：产出某种能跨会话存活的持久物，并且明确区分哪些是推断出来的、哪些是抽取出来的。图里每条边都打了标签：EXTRACTED、INFERRED 或 AMBIGUOUS。这是一个不常见的设计选择，在我看来，也是整件事里最有价值的部分。

它到底做什么

安装是两条命令。是的，PyPI 包名暂时是错的：

pip install graphifyy && graphify install

那个双写的 Y 是命名纠纷，不是拼写错误。CLI 和 skill 命令至今都还是 graphify。在 Windows 上，如果安装完命令无法识别，要么把 Python 的 Scripts 目录加进 PATH，要么改用 pipx install graphifyy，直接绕开这个问题。

然后在 Claude Code 里，任意目录下：

/graphify .
/graphify ./raw --mode deep
/graphify query "what connects attention to the optimizer?"
/graphify path "DigestAuth" "Response"
/graphify explain "SwinTransformer"

输出落在 graphify-out/。里面有一个可以点着看的交互式 graph.html，一个能作为 vault 打开的 obsidian/ 目录，一个持久化的 graph.json（几周后再查询，也不用重读任何文件），一个以 SHA256 为键的 cache/（重跑时只处理改动过的文件），还有一份 GRAPH_REPORT.md，列出它所谓的 god nodes —— 度数最高的概念 —— 以及按综合评分排序的"意外连接"，其中代码到论文的边比代码到代码的边权重更高。

多模态那部分是实打实的，不是营销话术。代码文件走 tree-sitter 做 AST 解析，再加一遍调用图分析。Markdown、PDF 和图片走 Claude：从散文里抽概念和关系，从论文里挖引用，用视觉能力处理截图、示意图、白板照片和其他语言的图片。

还有些导出格式，对不想困在这个工具里的人很重要：--svg、给 Gephi 或 yEd 用的 --graphml，以及 --neo4j —— 它生成一个 cypher.txt，而不是要求你跑一个数据库。技术栈是 NetworkX、经 graspologic 做 Leiden 聚类、tree-sitter 和 vis.js。没有服务端。除了 Claude 调用之外，什么都不离开本机。

拆解那个 71.5x

基准语料是 52 个文件：Karpathy 的仓库、五篇论文、四张图。结果是相比直接读原始文件，每次查询的 token 少 71.5x。

仓库对这套东西如何随规模变化异常诚实，这种诚实罕见得值得引述其要点：token 的节省随语料规模增长；而在只有六个文件时，图谱的价值在于结构清晰，而不是压缩，因为六个文件本来也塞得进上下文窗口。他们自己拿 graphify 源码加 Transformer 论文做的样例是 5.4x。在六个合成的库文件上，大约是 1x。

这个形状是对的。如果你的语料本来就在一个上下文窗口之内，你省下的不是 token，你买的是一张地图。如果是五十个混杂类型的文件，节省是真实且巨大的 —— 因为替代方案不是把文件读一遍，而是在多个轮次里反复读，每次 agent 都丢了位置。

这个对比在一个方向上略微抬高了 graphify，在另一个方向上又低估了它。读原始文件是最差情况的基线；一个调优过的检索索引在对比中会显得比原始文件好看。但检索索引返回的是段落，而 graphify 返回的是关系 ——"注意力机制和优化器之间靠什么连起来"的答案不是一段话，而是一条路径。这是两种不同的查询，而向量库只能服务其中一种。

"不用向量库"是一个真正的架构立场

大多数检索系统把文本切块、做 embedding、然后做最近邻搜索。Graphify 把这些全跳过了：代码用本地确定性的 AST 解析，散文和图片用 LLM 抽取，然后建图。没有 embedding 步骤，也没有相似度搜索。

换来的东西是可解释性。问它两样东西为什么相连，你拿到的是那些边，每条边都标着是源自原文抽取，还是模型推断。向量索引给不了这个。它只能告诉你余弦距离很小。

代价是覆盖率。图只知道抽取器找到的东西。如果抽取那一遍漏掉了一个关系，任何查询都不会把它翻出来，也没有模糊兜底。AMBIGUOUS 标签是对此的诚实承认，而 --mode deep 这个参数之所以存在，是因为默认那一遍对推断边很保守。

它在哪里站得住

按我对这类工具的经验，两个工作流。

第一个是上手一个陌生的代码库。不是"函数 X 在哪" —— 这种 grep 就够了 —— 而是"这里承重的概念是什么，其中哪些碰到了计费代码"。这是个图问题，而 god nodes 报告给出的答案，你两分钟就能读完。

第二个是多 agent 的场景。几个 agent 并行写代码时，各自对仓库的模型几分钟内就会过期。每提交一次就重建的图（graphify hook install 会装一个 post-commit hook），或者在文件保存时重建（--watch），能让每个 agent 拿到同一张当前地图，而不是五份互相分歧的猜测。

明显的限制：这东西首先是作为 Claude Code 的 skill 建起来的。手动安装路径会把一个 SKILL.md 丢进 ~/.claude/skills/graphify/，并在 CLAUDE.md 里加一行。有一个 MCP server 模式（--mcp）供其他客户端使用，但使用体验明显是为一个生态优化的；而且对 Claude 的依赖意味着在大型语料上，抽取那一遍是要花真金白银的。

诚实的结论

Graphify 不是搜索引擎，也不该按搜索引擎去评价。它是一个关于某个文件夹里有什么的、持久且可检查的模型，并且带有一个不寻常的属性：它会告诉你哪些部分是它猜的。对一个 137,000 star、已经热了一周的项目来说，有意思的问题不是这张图够不够惊艳，而是"给推断打标签"这个习惯，能不能在只想要答案的用户手里活下来。

我猜大多数人会只用 query，无视边的标签，永远不看 graph.json。能坚持用下去的人，是那些需要地图、而不是需要标准答案的人。