📌 项目地址：safishamsi/graphify | ⭐ 55,907 颗星 | 🔧 Python | 📜 MIT
它不是数据分析工具，是Claude Code的专属技能
很多GitHub项目试图做“通用知识管理”，但graphify的定位很窄——它是Claude Code的一个斜杠命令。安装后，你在Claude Code里输入/graphify .，它就会读取当前文件夹的所有文件，生成一个知识图谱。
我从一个实际场景说起。Andrej Karpathy在X上提过他习惯在项目里建一个/raw文件夹，丢进去论文、推文截图、笔记，但这些东西最终很难再利用。graphify的README直接引用了这个场景，说它是这个问题的答案。
71.5倍token节省是怎么算的
README里写了一个数字：每次查询的token消耗减少71.5倍。意思是，与其每次让Claude重新读取一堆原始文件（论文PDF、截图、代码），不如先建好图，之后所有查询都在这张图上进行。
我用一篇文章解释这个逻辑。假设你有一个文件夹，里面有10篇论文、20张架构图截图、5个代码目录。如果每次提问都让AI扫一遍，每个文件的上下文都要重复加载。而graphify把文件解析成节点和关系后，查询只需要加载图谱数据（结构化、可索引），体积自然小得多。
还有更关键的——这个图谱是持久化的。graph.json保存了所有结构数据，你过两周再问同一个文件夹的问题，不需要重新分析文件，直接加载这个json文件就行。cache/目录里存了SHA256哈希，只有修改过的文件才会被重新处理。
输入可以是任何东西：代码、PDF、白板照片、外语截图
graphify能处理的文件类型很广：
- 代码文件（自动提取函数、类、模块之间的关系）
- PDF、Markdown
- 截图、图表、白板照片
- 其他语言图像（利用Claude的视觉识别能力）
它不局限于文本。你把一张手绘的架构图照片丢进去，它会识别里面的框和箭头，提取出“服务A → 服务B”这样的关系。
输出物有6个，每个有明确用途
运行/graphify .后，生成一个graphify-out目录，里面6样东西：
graph.html：交互式图谱网页。可以点击节点、搜索、按社区筛选关系。适合直接打开看。obsidian/：直接作为Obsidian仓库打开。如果你用Obsidian做笔记，这相当于把你的代码/文档/笔记自动导入了你的笔记系统。wiki/（加--wiki参数生成）：维基百科风格的文章。每篇讲一个主题，节点之间互相链接。README说这是给“agent navigation”用的，我理解是让AI代理能“翻阅”这些文章来回答问题，比直接读图谱json更友好。GRAPH_REPORT.md：报告文件，列出枢纽节点（god nodes）、意外连接、建议查询问题。graph.json：图谱的原始数据结构，用于持久化和程序化查询。cache/：SHA256缓存。只有文件修改了才重新处理，没变动的直接用缓存。
安装过程有两个坑
第一个坑：PyPI上包名不叫graphify，叫graphifyy。因为graphify这个名字正在交涉。但安装后，命令行和技能命令仍然是graphify。
pip install graphifyy && graphify install第二个坑：Windows下如果graphify命令不识别，需要把Python Scripts目录加到PATH（比如%APPDATA%PythonPython3xxScripts）。macOS如果报“externally-managed-environment”，用pipx install graphifyy。README推荐直接用pipx，它会自动处理PATH问题。
还有一种手动安装方法：从GitHub下载skill.md文件放到~/.claude/skills/graphify/，然后在~/.claude/CLAUDE.md里添加配置。具体命令README里都有，这里不重复。
用法：全部是Claude Code内的斜杠命令
安装好之后，所有操作都在Claude Code里输入：
# 对当前目录
/graphify .
# 指定文件夹
/graphify ./raw
# 深度模式：更激进地推断隐含关系
/graphify ./raw --mode deep
# 增量更新：只处理变化的文件，合并到现有图谱
/graphify ./raw --update
# 添加网络资源：论文、推文
/graphify add https://arxiv.org/abs/1706.03762
/graphify add https://x.com/karpathy/status/...
# 查询图谱：用自然语言问
/graphify query "what is the relationship between module A and module B?"注意/graphify query后面跟的是双引号里的一段话。README里有一个完整的查询命令示例，但文稿中截断了——原文是/graphify query "wh...，推测完整格式是/graphify query "what is..."。
我觉得它适合什么情况
不适合分析单个文件。适合处理满是零散材料的文件夹。我举几个实际会碰到的场景：
- 接手一个老项目。代码、文档、数据库schema图、第三方API的截图混在一个目录里。跑一遍graphify，得到模块之间的依赖、文档中提到的业务逻辑和代码中的实现函数之间的关联。
- 研究一个开源项目。你把论文、代码库、笔记、架构截图丢进一个文件夹。graphify输出一个可交互图谱，比读上万行代码更快看到结构。
- 长期积累的研究笔记。几个月下来存了几百篇论文截图和笔记。跑一次图，以后所有查询基于图谱，不需要每次重新翻原文。
graphify的工作流是：先分析，存图，之后只查图，不查文件。这一点和“每次都重新扫描”的方案有本质区别。持久化图谱加上增量更新，意味着它适合持续使用的场景，而不是一次性分析工具。
我的评价
一件事说清楚：graphify不是通用工具，它依赖Claude Code。你如果不用Claude Code，它对你没意义。
它的设计里有三个亮点值得单独说：
- 多模态输入不是噱头。手绘图、截图、外语标识图都能解析，这来自Claude的视觉能力，不是graphify自己做的，但它把这种能力直接整合进了文件读取流程。
- token节省71.5倍是具体的数值主张。我建议你在自己的项目上测试一下这个比例是否成立，但理论上堆叠多个文件时，结构化图谱的查询开销确实远小于重复加载原文。
- 增量更新是很多人忽略的设计决策。
cache/目录的存在意味着这个工具设计用于长期维护的图谱，而不是跑完就丢。对于持续增长的研究笔记或项目文档，这比每次全量重建实用。
唯一让我觉得遗憾的：graphify的输出格式里，wiki模式文档是为“agent navigation”设计的，但这部分说明不够具体。我理解这句话的意思是“让AI能翻阅这些文章来回答问题”，但README没展开讲这个Agent到底怎么用。
另外，这个项目目前的功能集中在文件读取和知识提取，没有直接输出给其他系统使用的API接口。如果能把graph.json直接导入到Neo4j、ArangoDB这类图数据库，或者输出为知识图谱标准格式（RDF、KGML），它的可扩展性会强很多。但这也可能是项目早期，团队优先做了Claude Code内的闭环体验。
对于有大量零散文件需要整理成知识库的人，这个工具是值得试的。安装成本不高，运行一次就知道效果。