一行命令把杂乱文件变成知识图谱——我的知识库搭建流程

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

我的电脑上一直有个坏习惯：到处存文件。论文存一个文件夹，代码存一个仓库，截图随手放桌面，笔记写在 Notion，书签收藏在浏览器。几千个文件，从来没真正串起来看过。

我知道这个毛病。你保存某个东西是因为它感觉重要。你告诉自己以后会回来看。你从来没看过。

我试过的知识管理方案不下十种。Notion 数据库、Obsidian 双向链接、文件夹分类、标签系统。它们的共同问题只有一个：你得提前知道信息应该放在哪里。

最近我换了个思路。不再手动分类了。我把所有文件丢进一个文件夹，让一个开源工具自动帮我建了一张知识图谱。

Boy was I wrong——我以为手动分类是唯一的路。跑完之后我才发现自己攒的资料里藏着多少以前没注意到的联系。

它是什么

graphify 是一个面向 AI 编码助手的开源工具。它在 Claude Code、Codex 等平台上以 /graphify 命令的形式工作，但你也可以手动使用。

它做的事情说起来很简单：扫描一个文件夹里的所有文件，提取概念和关系，合并成一张知识图谱。代码走 AST 解析（纯本地，不消耗 token），文档和图片走语义提取（调用你平台的模型）。

代码、Markdown、PDF、截图、白板照片，什么格式都行。

项目地址：https://github.com/safishamsi/graphify

核心思路：两轮提取

这是 graphify 跟其他工具最大的区别。它分两轮执行：

第一轮是确定性的 AST 提取。对代码文件做结构分析——类、函数、导入、调用图、docstring、注释里的设计动机（# NOTE:、# WHY: 这种）。这一轮完全不需要 LLM，纯本地解析，速度很快。

第二轮是语义提取。对文档、论文和图片，它并行启动多个 Claude 子代理，从中提取概念、关系和设计意图。最后把两边结果合并到一个图里，用 Leiden 社区发现算法做聚类。

每条关系都会被标记为三种类型之一：EXTRACTED（原文直接找到的）、INFERRED（合理推断，附带置信度分数）、AMBIGUOUS（有歧义，需要复核）。所以你始终知道哪些是实际发现的，哪些是模型猜出来的。

这种设计的好处是：代码分析不消耗 token，只在你需要文档理解时才调用 LLM。而且结果里明确区分了事实和推断，这在其他工具里几乎见不到。

安装：两条命令

pip install graphifyy

注意 PyPI 包名是 graphifyy（两个 y），但命令行命令仍然是 graphify。

然后注册到你的 AI 编码助手：

graphify install

这一步会在项目里写入 skill 定义，让 Claude Code 识别 /graphify 命令。如果你用 Codex 或 OpenCode，加个平台参数就行：

graphify install –platform codex graphify install –platform opencode

跑起来

打开你的 AI 编码助手，输入：

/graphify .

它会自动扫描目录，分类统计文件，然后开始提取。跑完之后输出三个文件：

graphify-out/graph.html — 交互式图谱，浏览器双击就能打开，节点可拖拽，社区按颜色分组
graphify-out/GRAPH_REPORT.md — 文字报告，包含核心节点（God Nodes）、意外连接、建议提问
graphify-out/graph.json — 持久化图谱数据，数周后仍可查询，无需重新读取原始文件

让助手自动优先读图谱

图谱建好之后，跑一次：

graphify claude install

这会在项目的 .claude/settings.json 里注册一个 PreToolUse hook，并在 CLAUDE.md 里写一条规则。效果是：每次 Claude 执行 Glob 或 Grep 搜索之前，它会先看到提示——”知识图谱已存在，请先读图谱报告再搜索文件。”

以后再问项目相关的问题，Claude 会先看图谱导航，而不是直接 grep 一堆文件乱搜。

可以这样理解：常驻 hook 是先给助手一张地图，/graphify query、/graphify path 这几个命令则是让它沿着地图精确导航。

日常使用场景

增量更新——加了新文件之后：

/graphify . –update

只重新提取变更过的文件，已有结果走 SHA256 缓存，不重复消耗 token。

后台监听——开发过程中自动同步：

/graphify . –watch

在后台终端跑着就行。代码文件变化立刻重建（只走 AST），文档或图片变更会提醒你跑 –update。

查询图谱——问两个概念的关系：

/graphify query "GameEngine 和音频系统有什么关系？"

它在图上做 BFS 遍历，返回所有连接的节点和边的类型。

最短路径——两个概念之间怎么连通的：

/graphify path "GameEngine" "Database"

解释节点——某个概念的所有连接信息：

/graphify explain "SwinTransformer"

添加外部资料——论文、推文一键入库：

/graphify add https://arxiv.org/abs/1706.03762 /graphify add https://x.com/someone/status/123 –author "张三"

自动下载、保存、更新图谱。

Git 提交后自动重建：

graphify hook install

每次 git commit 后自动更新图谱，不需要额外开后台进程。

实际跑出来的结果

我拿 Beacon Ash 游戏项目跑了第一次。471 个文件混在一起——180 个代码文件、153 个文档、138 张截图，约 116 万字。

跑完得到 1394 个节点、1930 条边、193 个社区。

最有价值的发现不是某个具体文件，而是社区之间的关系。GameEngine 连接了音频、渲染、世界地图、存档系统——这是游戏的核心骨架，符合预期。但 DOCXSchemaValidator 有 60 条边，连接数比游戏引擎还多——原因是它被 docx 和 pptx 两个完全不同的 skill 共享，底层 OOXML 验证框架是复用的。这个我之前完全没意识到。

还有一堆”意外连接”：设计文档里提到的某个决策，和代码里的一段注释形成了语义相似边。代码和文档说的是同一件事，但结构上没有任何关联。这种连接只有图谱能帮你发现。

打开 graph.html，节点可以拖拽，社区按颜色分组。一眼就能看到整个项目的骨架——哪些模块是核心，哪些是边缘，哪些连接是我从没注意到的。

它不是银弹

它不会替你思考，不会替你写总结。它只是把一堆散乱的文件变成一张可浏览的地图。至于怎么走那条路，还是你自己的事。

但它解决了一个我以前一直没解决的问题：不用提前设计分类体系，信息自己找位置。你只需要往 /raw 文件夹里丢东西，剩下的交给它。

安装两条命令，一条跑图谱。就这么简单。

本文由mdnice多平台发布