{
  "slug": "graphify-claude-code-memory",
  "url": "https://kelewrites.com/posts/graphify-claude-code-memory/",
  "title": "给 Claude Code 一张代码地图：Graphify 如何用知识图谱省下一半 token",
  "subtitle": "用 tree-sitter 确定性建图、不靠向量嵌入，把代码库变成 AI 能直接查的持久记忆",
  "summary": "Claude Code 的最大痛点是没有记忆——每次提问都靠全局搜索盲找、烧掉大量 token。Graphify 用 tree-sitter 把代码库确定性地建成一张知识图谱，给 AI 一份可查询的地图；实测同一个问题省下约六成 token，回答还更准。",
  "date": "2026-06-04",
  "updated": "",
  "tags": [],
  "series": "",
  "source": {
    "title": "Chase AI：这个开源项目刚解决了 Claude Code 的最大痛点",
    "url": "https://www.youtube.com/watch?v=ChskqGovoHg",
    "date": "2026-06-04"
  },
  "ai": {
    "summary": "Claude Code 的最大痛点是没有记忆——每次提问都靠全局搜索盲找、烧掉大量 token。Graphify 用 tree-sitter 把代码库确定性地建成一张知识图谱，给 AI 一份可查询的地图；实测同一个问题省下约六成 token，回答还更准。",
    "takeaways": [
      "Claude Code 的最大痛点是没有记忆——每次提问都靠全局搜索盲找、烧掉大量 token。Graphify 用 tree-sitter 把代码库确定性地建成一张知识图谱，给 AI 一份可查询的地图；实测同一个问题省下约六成 token，回答还更准。",
      "开场：聪明的 AI，却总在原地\"重新认路\"",
      "一、痛点：Claude Code 不是不聪明，而是手里没有地图",
      "二、原理：把\"让 AI 猜\"换成\"让程序读\""
    ],
    "audience": [
      "想快速吸收高密度长文的中文读者"
    ],
    "quote": "一句话总结：Claude Code 的最大痛点是没有记忆——每次提问都靠全局搜索盲找、烧掉大量 token；Graphify 用 tree-sitter 把代码库确定性地建成一张知识图谱，给 AI 一份可查询的地图，实测同一个问题省下约六成 token，回答还更准。",
    "questions": [
      "这篇文章的核心结论是什么？",
      "开场：聪明的 AI，却总在原地\"重新认路\"到底讲了什么？",
      "痛点：Claude Code 不是不聪明，而是手里没有地图是什么意思？",
      "原理：把\"让 AI 猜\"换成\"让程序读\"到底讲了什么？"
    ],
    "citation": {
      "title": "给 Claude Code 一张代码地图：Graphify 如何用知识图谱省下一半 token",
      "conclusion": "Claude Code 的最大痛点是没有记忆——每次提问都靠全局搜索盲找、烧掉大量 token。Graphify 用 tree-sitter 把代码库确定性地建成一张知识图谱，给 AI 一份可查询的地图；实测同一个问题省下约六成 token，回答还更准。",
      "points": [
        "开场：聪明的 AI，却总在原地\"重新认路\"",
        "一、痛点：Claude Code 不是不聪明，而是手里没有地图",
        "二、原理：把\"让 AI 猜\"换成\"让程序读\""
      ],
      "quote": "一句话总结：Claude Code 的最大痛点是没有记忆——每次提问都靠全局搜索盲找、烧掉大量 token；Graphify 用 tree-sitter 把代码库确定性地建成一张知识图谱，给 AI 一份可查询的地图，实测同一个问题省下约六成 token，回答还更准。",
      "url": "https://kelewrites.com/posts/graphify-claude-code-memory/",
      "attribution": "kele · Article Share"
    }
  },
  "headings": [
    {
      "depth": 2,
      "text": "开场：聪明的 AI，却总在原地\"重新认路\""
    },
    {
      "depth": 2,
      "text": "金字塔总览"
    },
    {
      "depth": 2,
      "text": "一、痛点：Claude Code 不是不聪明，而是手里没有地图"
    },
    {
      "depth": 2,
      "text": "二、原理：把\"让 AI 猜\"换成\"让程序读\""
    },
    {
      "depth": 2,
      "text": "三、价值：一次建图、反复查询的\"持久记忆\""
    },
    {
      "depth": 2,
      "text": "一页速览（三段一表）"
    },
    {
      "depth": 2,
      "text": "一句话收束"
    }
  ],
  "text": "> **一句话总结**：Claude Code 的最大痛点是没有记忆——每次提问都靠全局搜索盲找、烧掉大量 token；Graphify 用 tree-sitter 把代码库确定性地建成一张知识图谱，给 AI 一份可查询的地图，实测同一个问题省下约六成 token，回答还更准。\n\n---\n\n## 开场：聪明的 AI，却总在原地\"重新认路\"\n\n你大概率有过这种体验：让 Claude Code 回答一个稍微涉及全局的问题——\"这个设计请求是怎么从前端一路流到后端智能体再返回的\"——它会当场启动一两个探索智能体，把整个仓库翻一遍，几分钟、十几万 token 之后，才给出一个其实并不复杂的答案。\n\n问题不在它不够聪明，而在它**没有记忆**。每一次提问，它都像第一次进这个项目，对着满屏文件用 Ctrl+F 盲找。仓库越大，这种\"重新认路\"的代价越高——token 烧得多、回答还容易抓不准关联。\n\n那有没有办法，让 AI 不必每次都重新摸索，而是手里先拿着一张画好的路线图？答案是一个几个月前刚发布、已经攒了近 7 万 star 的开源项目：**Graphify**。它把整个代码库一次性建成一张知识图谱，从此 AI 顺着确定的架构关联直接查答案。\n\n那么 Graphify 到底解决了什么、怎么做到的？答案一句话：**它把\"每次现场搜索\"换成了\"一次建图、反复低成本查询\"的持久记忆**。下面分三层展开。\n\n## 金字塔总览\n\n---\n\n## 一、痛点：Claude Code 不是不聪明，而是手里没有地图\n\n传统 AI 编程助手回答全局问题只有一招：全局搜索。它在文件里一层层翻找、靠探索智能体扫描整个代码库，本质上就是\"拿着 Ctrl+F 瞎找\"。而知识图谱给它的，是一张清晰的路线图——A 怎么连到 B、B 怎么连到 C，以及这些关联意味着什么，一目了然。地图能做到的事，全局搜索做不到。\n\n差距有多大，作者拿一个相对庞大的开源仓库 open-design 做了实测：问同一个问题——\"设计请求如何从 Web 应用流向编码智能体再返回\"——开两个标签页对比。\n**不用 Graphify**：Claude Code 启动了两个探索智能体扫全库，光这一步就烧掉约 15 万 token，主对话再叠加约 5 万，合计**约 20 万 token**。\n**用 Graphify**：直接查已经建好的图谱，**约 8 万 token** 就给出了答案。\n\n两边最终答案准确度其实一样，但后者只花了前者四成左右的开销。更关键的是：不用图谱的那一次，扫描成本是\"现用现烧\"，下次换个问题还得再付一遍；而图谱一旦建好，后续查询就不必重复为\"读一遍代码库\"买单。\n\n> **金句**：全局搜索是拿着 Ctrl+F 瞎找，知识图谱是手里攥着一张路线图——同一个答案，一个烧 20 万 token，一个只要 8 万。\n\n## 二、原理：把\"让 AI 猜\"换成\"让程序读\"\n\nGraphify 怎么把一堆代码变成这张图？它走的是一条**三阶段管线**，最巧妙的地方在于：真正花钱的 LLM，被放到了最后、用得最省。\n**第一阶段——解析代码结构（免费、本地、不用大模型）**。用 tree-sitter 直接解析源码，提取类、函数、调用图和注释。这一步完全是**确定性**的：不是让 AI 猜\"这段代码可能和那段有关\"，而是照着代码本来写出来的架构，明确指出哪两处真实相连。你在图里看到的大部分骨架，都来自这一步，一分钱 API 费用都不花。\n**第二阶段——转录音视频**。如果仓库里夹带了音频、视频，用 faster-whisper 自动转成文字，一并并入图谱。\n**第三阶段——语义分析文档（这才轮到 LLM）**。对 PDF、文档、图片、论文这类非代码文件，大模型才真正介入，去理解它们到底在讲什么，并把它们安放到整张图谱的合适位置。这一阶段类似 RAG，但**不需要做真正的向量嵌入**。\n\n跑完之后，Graphify 把这一切汇成图：每个**节点**是一个实体，节点之间的连线是**边**（代表关联），性质相近的节点再聚成**社区**。在 open-design 的演示里，它分析了 203 个文件，生成 1907 个节点、3447 条边、109 个社区，输出 token 略低于 12 万。\n\n这也正是它和 GraphRAG、LightRAG、微软 GraphRAG 这些图 RAG 系统的根本分野——**它根本不用向量嵌入**。代码库的结构是确定的、写死在那里的，何必再丢给概率模型去近似？能用解析器读出来的，就不该让 AI 猜。\n\n> **金句**：能用 tree-sitter 确定性读出来的关联，就不该丢给向量嵌入去猜——Graphify 把昂贵的 LLM 留到最后一步，前面全靠免费的解析。\n\n## 三、价值：一次建图、反复查询的\"持久记忆\"\n\n建图本身那张炫酷的可视化并不是重点——真正的价值，是 AI 从此有了一份**持久且可低成本复用**的记忆。\n**建一次，反复查**。图谱建好后，后续每次提问都不再重复扫描整个仓库，token 成本直接降到查询级别。这就是\"记忆\"二字的含义。\n**代码改了，图谱跟着增量更新**。运行一次 git hook 安装，之后每次提交都会自动重建——而且只针对 AST、只看实际改了什么，**确定性完成、零 API 费用**。即便两个开发者在同一仓库并行开发，它也能应对，最终给团队留下一张持续生长的活地图。\n**上手只要一条命令**。把 GitHub 链接丢给 Claude Code 说\"帮我装一下\"即可；装好会附带一个技能包，自动判断你这句话该调用哪个命令（建图、查询还是解释），不用你死记。它甚至能一键把内容导出成 Obsidian 库。\n\n至于\"省 70 倍 token\"的说法——作者自己也觉得偏夸张，实测约省六成更接近真实；项目给出的基准也是代码审查约 6.8 倍、大型仓库日常编码最高约 49 倍的区间。Graphify 的定位，大致落在 Obsidian 本地笔记和一套完整 RAG 系统**之间**：你既不必只困在 Markdown 里，也不必大费周章搭一整套向量检索架构。\n\n> **金句**：它不是又一个 RAG，而是 Obsidian 与完整 RAG 之间那块空白里的轻量折中——给 AI 一份建一次就能反复查的代码记忆。\n\n---\n\n## 一页速览（三段一表）\n\n| 章节 | 关键观点 | 一句话核心 |\n\n| 一、痛点 | Claude Code 没有记忆，靠全局搜索盲找，一个问题实测烧约 20 万 token | 缺的不是智商，是地图 |\n| 二、原理 | 三阶段管线：tree-sitter 确定性解析代码 → 转录音视频 → LLM 只负责文档语义，不用向量嵌入 | 能读出来的，别让 AI 猜 |\n| 三、价值 | 建一次图反复查，git 提交后增量重建、零 API 费用、支持团队协作 | 持久记忆，约省六成 token |\n\n---\n\n## 一句话收束\n\n> **给 AI 一张地图，比让它每次重新认路便宜得多**——Graphify 的意义，不在那张好看的图谱，而在它把\"现场搜索\"换成了\"一次建图、反复低成本查询\"的持久记忆。"
}