给 Claude Code 一张代码地图：Graphify 如何用知识图谱省下一半 token

一句话总结：Claude Code 的最大痛点是没有记忆——每次提问都靠全局搜索盲找、烧掉大量 token；Graphify 用 tree-sitter 把代码库确定性地建成一张知识图谱，给 AI 一份可查询的地图，实测同一个问题省下约六成 token，回答还更准。

开场：聪明的 AI，却总在原地”重新认路”

你大概率有过这种体验：让 Claude Code 回答一个稍微涉及全局的问题——“这个设计请求是怎么从前端一路流到后端智能体再返回的”——它会当场启动一两个探索智能体，把整个仓库翻一遍，几分钟、十几万 token 之后，才给出一个其实并不复杂的答案。

问题不在它不够聪明，而在它没有记忆。每一次提问，它都像第一次进这个项目，对着满屏文件用 Ctrl+F 盲找。仓库越大，这种”重新认路”的代价越高——token 烧得多、回答还容易抓不准关联。

那有没有办法，让 AI 不必每次都重新摸索，而是手里先拿着一张画好的路线图？答案是一个几个月前刚发布、已经攒了近 7 万 star 的开源项目：Graphify。它把整个代码库一次性建成一张知识图谱，从此 AI 顺着确定的架构关联直接查答案。

那么 Graphify 到底解决了什么、怎么做到的？答案一句话：它把”每次现场搜索”换成了”一次建图、反复低成本查询”的持久记忆。下面分三层展开。

金字塔总览

mindmap
  root((Graphify：给 AI 的代码地图))
    痛点
      AI 没有记忆
      全局搜索像 Ctrl+F
      一个问题烧约 20 万 token
    建图原理
      三阶段管线
      tree-sitter 确定性解析
      不用向量嵌入
      产出节点 边 社区
    持久记忆
      建一次反复查
      git 提交后增量重建
      零 API 费用 也支持团队协作

一、痛点：Claude Code 不是不聪明，而是手里没有地图

传统 AI 编程助手回答全局问题只有一招：全局搜索。它在文件里一层层翻找、靠探索智能体扫描整个代码库，本质上就是”拿着 Ctrl+F 瞎找”。而知识图谱给它的，是一张清晰的路线图——A 怎么连到 B、B 怎么连到 C，以及这些关联意味着什么，一目了然。地图能做到的事，全局搜索做不到。

差距有多大，作者拿一个相对庞大的开源仓库 open-design 做了实测：问同一个问题——“设计请求如何从 Web 应用流向编码智能体再返回”——开两个标签页对比。

• 不用 Graphify：Claude Code 启动了两个探索智能体扫全库，光这一步就烧掉约 15 万 token，主对话再叠加约 5 万，合计约 20 万 token。
• 用 Graphify：直接查已经建好的图谱，约 8 万 token 就给出了答案。

两边最终答案准确度其实一样，但后者只花了前者四成左右的开销。更关键的是：不用图谱的那一次，扫描成本是”现用现烧”，下次换个问题还得再付一遍；而图谱一旦建好，后续查询就不必重复为”读一遍代码库”买单。

金句：全局搜索是拿着 Ctrl+F 瞎找，知识图谱是手里攥着一张路线图——同一个答案，一个烧 20 万 token，一个只要 8 万。

二、原理：把”让 AI 猜”换成”让程序读”

Graphify 怎么把一堆代码变成这张图？它走的是一条三阶段管线，最巧妙的地方在于：真正花钱的 LLM，被放到了最后、用得最省。

1. 第一阶段——解析代码结构（免费、本地、不用大模型）。用 tree-sitter 直接解析源码，提取类、函数、调用图和注释。这一步完全是确定性的：不是让 AI 猜”这段代码可能和那段有关”，而是照着代码本来写出来的架构，明确指出哪两处真实相连。你在图里看到的大部分骨架，都来自这一步，一分钱 API 费用都不花。
2. 第二阶段——转录音视频。如果仓库里夹带了音频、视频，用 faster-whisper 自动转成文字，一并并入图谱。
3. 第三阶段——语义分析文档（这才轮到 LLM）。对 PDF、文档、图片、论文这类非代码文件，大模型才真正介入，去理解它们到底在讲什么，并把它们安放到整张图谱的合适位置。这一阶段类似 RAG，但不需要做真正的向量嵌入。

跑完之后，Graphify 把这一切汇成图：每个节点是一个实体，节点之间的连线是边（代表关联），性质相近的节点再聚成社区。在 open-design 的演示里，它分析了 203 个文件，生成 1907 个节点、3447 条边、109 个社区，输出 token 略低于 12 万。

这也正是它和 GraphRAG、LightRAG、微软 GraphRAG 这些图 RAG 系统的根本分野——它根本不用向量嵌入。代码库的结构是确定的、写死在那里的，何必再丢给概率模型去近似？能用解析器读出来的，就不该让 AI 猜。

金句：能用 tree-sitter 确定性读出来的关联，就不该丢给向量嵌入去猜——Graphify 把昂贵的 LLM 留到最后一步，前面全靠免费的解析。

三、价值：一次建图、反复查询的”持久记忆”

建图本身那张炫酷的可视化并不是重点——真正的价值，是 AI 从此有了一份持久且可低成本复用的记忆。

• 建一次，反复查。图谱建好后，后续每次提问都不再重复扫描整个仓库，token 成本直接降到查询级别。这就是”记忆”二字的含义。
• 代码改了，图谱跟着增量更新。运行一次 git hook 安装，之后每次提交都会自动重建——而且只针对 AST、只看实际改了什么，确定性完成、零 API 费用。即便两个开发者在同一仓库并行开发，它也能应对，最终给团队留下一张持续生长的活地图。
• 上手只要一条命令。把 GitHub 链接丢给 Claude Code 说”帮我装一下”即可；装好会附带一个技能包，自动判断你这句话该调用哪个命令（建图、查询还是解释），不用你死记。它甚至能一键把内容导出成 Obsidian 库。

至于”省 70 倍 token”的说法——作者自己也觉得偏夸张，实测约省六成更接近真实；项目给出的基准也是代码审查约 6.8 倍、大型仓库日常编码最高约 49 倍的区间。Graphify 的定位，大致落在 Obsidian 本地笔记和一套完整 RAG 系统之间：你既不必只困在 Markdown 里，也不必大费周章搭一整套向量检索架构。

金句：它不是又一个 RAG，而是 Obsidian 与完整 RAG 之间那块空白里的轻量折中——给 AI 一份建一次就能反复查的代码记忆。

一页速览（三段一表）

一句话收束

给 AI 一张地图，比让它每次重新认路便宜得多——Graphify 的意义，不在那张好看的图谱，而在它把”现场搜索”换成了”一次建图、反复低成本查询”的持久记忆。