Graphify：无需向量库，把任意代码库变成可查询的知识图谱

代码库在变大，笔记、论文和截图也在不断堆积，而编程智能体每次开启新会话，几乎都要从零开始重读这些原始文件。这既烧掉大量 token，也让知识无法跨会话沉淀。Graphify 正是针对这一痛点出现的开源项目。它是一个 Claude Code 技能：在 Claude Code 里输入 /graphify，它会读取目录下的文件，构建一张知识图谱，再把你原本不知道存在的结构交还给你。项目自述称，与直接阅读原始文件相比，每次查询所用的 token 少 71.5 倍，图谱可以跨会话持久保存，并且会诚实地区分哪些内容是“找到的”，哪些只是“猜测的”。项目 README 还借用了 Andrej Karpathy 的做法作类比：Karpathy 习惯保留一个 /raw 文件夹，随手丢进论文、推文、截图和笔记，而 Graphify 想解决的正是这种“资料越堆越多、却无法被有效调用”的问题。需要说明的是，71.5 倍这个数字来自项目自身的说明，我们没有独立复现，读者应把它当作量级参考，而不是保证。

Graphify 的第一个特点是完全多模态。它的输入不限于源代码：PDF、Markdown 文档、屏幕截图、架构图、白板照片，甚至其他语言书写的图片，都可以直接丢进去。项目使用 Claude 的视觉能力，从这些异构材料中抽取概念与关系，再把它们连接进同一张图。这意味着一张手绘的系统草图、一份设计评审的 PDF 和一段核心模块的源码，可以在图谱里成为相互关联的节点，而不是散落在三个互不相通的目录里。对于经常需要在“文档说的”和“代码做的”之间来回核对的团队来说，这种统一表示本身就有价值。同时，它采用的是结构化图而不是向量检索，因此标题里强调“无需向量库”：查询依赖节点与边的显式关系，而不是嵌入空间里的相似度。

第二个特点在于产出物的设计。运行 /graphify . 之后，会生成一个 graphify-out 目录，里面分工明确。graph.html 是可交互的图谱，可以点击节点、搜索，并按社区过滤。obsidian 目录可以直接作为 Obsidian 知识库打开。启用 --wiki 参数时，会生成类似维基百科风格的条目，专门供智能体导航使用。GRAPH_REPORT.md 是一份报告，列出“上帝节点”（连接最密集的核心概念）、出人意料的跨领域连接，以及建议你继续追问的问题。graph.json 是持久化的图谱本体，数周之后无需重读原文件即可查询。最后，cache 目录保存 SHA256 缓存，使得重新运行时只处理发生变化的文件。这套设计把“给人看”和“给智能体用”两条路径同时照顾到了，而增量缓存让它在日常迭代的仓库里不至于每次都重新付费。

安装方式也很轻量。它要求已安装 Claude Code 与 Python 3.10 以上，执行 pip install graphifyy 再运行 graphify install 即可。这里有一个容易踩坑的细节：PyPI 上的包名暂时叫 graphifyy，因为 graphify 这个名字仍在回收中，但命令行工具和技能命令依然叫 graphify。Windows 用户若安装后找不到命令，需要把 Python 的 Scripts 目录加入 PATH，或者改用 pipx；macOS 上遇到“外部管理环境”报错时，同样建议使用 pipx。也可以手动安装：用 curl 下载技能文件 SKILL.md 放到 ~/.claude/skills/graphify 目录，再在 ~/.claude/CLAUDE.md 中登记。之后在任意目录打开 Claude Code，输入 /graphify . 即可开始。

把它放进具体场景，价值会更清楚。设想一位新加入团队的工程师，面对一个陌生的大仓库，手边还有几份设计文档和一张白板照片。过去的做法是让智能体逐个文件打开，边读边总结，下一次会话又得重来。有了图谱之后，智能体可以先看 GRAPH_REPORT.md，了解哪些是核心节点、哪些模块之间存在意料之外的耦合，再沿着图中的边去追问具体问题，只在需要时回到原文件核对细节。这种“先看地图，再进现场”的工作方式，与传统的检索增强生成并不冲突，而是换了一个切入点：它先把关系理清，再谈召回。当然，它是否优于纯向量检索，取决于任务类型。对于强调结构、依赖与概念关联的问题，图通常更直观；对于需要在大量相似段落中模糊匹配措辞的问题，向量检索仍有其位置。两者并用，也许才是更稳妥的选择，团队可以先小范围试用，再逐步扩大。

从行业视角看，Graphify 代表了一条值得关注的路线：不把长期记忆完全交给向量库，而是让大模型一次性把材料“编译”成显式的图结构，之后的查询只读图。这样做的好处是结果可审计、可增量更新、跨会话稳定；代价是图的质量取决于模型抽取的准确度，错误的边会被固化下来。项目强调要区分“找到的”和“猜测的”，正是对这一风险的回应，但具体做到什么程度，仍需要读者在自己的语料上抽样检验。另外，首次构建大型目录时需要调用模型，尤其是视觉抽取，成本不可忽略，增量缓存只能缓解后续运行的开销。我们的建议是：先在一个中等规模的仓库上试跑，对照 GRAPH_REPORT.md 里的核心节点，检查它是否真的符合你对系统的理解，再决定是否把它纳入日常的智能体工作流。如果结果可信，它有望成为连接代码、文档与视觉资料的一层通用上下文基础设施。