事情要从几天前说起：
和一个开发朋友日常进行闲聊，他提了一嘴他公司最近在优化的一个项目：
整一套面向青少年的心理辅助 Agent 助手，用来做情绪疏导和危机干预。
「现在卡在知识库搭建这块，」他说，「你懂吧，我们打算搞个知识图谱，给AI来进行诊断」
我灌了口可乐，随口说了句：「这年头你们还搞 RAG 啊？会不会有点落伍了？」
沉默，是今晚的康桥。。。。。。
「……不是知识图谱跟 RAG 有毛线关系啊？？」
「不是你说的吗？你们这个项目不就是要给 AI 外挂一个知识库？」
「大哥，不要看到外接知识库就说是RAG啊，知识图谱，懂吗？？」
此处再省略5分钟科普。。。。
哈，讲完后发现我拉了坨大的，这俩完全是两个东西！
然后回去他建议我找了个开源SKILL，自己动手给我现在的项目搭了一套知识图谱。
说实话，真的感谢他给我科普了这一趟，在完整了解这俩概念，并且搭建完一次知识图谱后，我的编程习惯都感觉被重塑了（什么恶堕？）这个本地图谱的好用程度有点超乎我的预期了。
于是在今天，我决定把我这段经历写成文章，重点把这三件事说清楚：RAG 和知识图谱到底是什么、Graph RAG 又是什么、以及我自己实操下来，被本地知识图谱五个被彻底改变的编程习惯。
先搞清楚：RAG、知识图谱到底有什么区别
介于我已经在上文丢过脸了，所以先花一点篇幅把概念厘清。如果您是本来就懂行的大佬，可以直接跳到第四节看实操。这部分主要面向和我之前一样没有厘清概念的朋友：
1.RAG 到底是什么
RAG全称是“检索增强生成”，其核心思想是把大模型自身参数里的“记忆”和外部检索到的“非参数记忆”结合起来，用检索结果辅助生成答案。比如说，你去问AI问题：
北京烤鸭属于什么菜系？
正常情况下，这个问题本身会作为上下文被塞给大模型，大模型根据自身训练参数里的记忆给出回答。
但是问题很明显，这大模型训练的时候没有学习相关信息，或者相关信息不是最新的，最正确的（例如被最新的“北京鸭腿事件”给盖过去了。只是举例嗷，没有阴阳阿姨的意思），大模型回答的质量可能会令人不满意。
而使用了RAG以后，通过拼接外部的额外记忆或知识：
- 1.
北京烤鸭是北京的著名美食 - 2.
北京烤鸭属于京菜 - 3.
北京烤鸭的主要食材是鸭肉
把这部分知识拼成一个完整的输入prompt：
{北京烤鸭是北京的著名美食。北京烤鸭属于京菜。北京烤鸭的主要食材是鸭肉。} + {北京烤鸭属于什么菜系？}
由于上下文给大模型提供了更多的上下文，大模型相当于翻书翻到了正确资料，现在的回答变得更加靠谱，精准的找到了“京菜”这一关键信息，于是回答道：
北京烤鸭属于京菜，主要食材是鸭肉
当然，这只是一个简单的示例。下面讲一下完整的RAG流程。
由于搭建RAG通常伴随着搭建向量数据库，导致很多人误解：向量数据库==RAG。我之前刚开始起步的时候也犯过这个错误，但是实际上RAG 是一种系统流程，向量数据库只是 RAG 里常用的一个组件。
一个典型 RAG 系统通常包括：
- 1. 原始资料
- 2. 切分成 chunk
- 3. 转成 embedding 向量
- 4. 存进向量数据库
- 5. 用户提问
- 6. 检索相关 chunk
- 7. 把 chunk 作为上下文交给大模型
- 8. 大模型生成答案
所以 RAG 是一条链路：
在实际运行过程中，chunk 是重要的单元，一般称之为“分块”，比如一篇 10 页 PDF，会被切成很多 chunk：
chunk 1：第1页第1段 chunk 2：第1页第2段 chunk 3：第2页第1段 ...
每个 chunk 会被转成向量。
用户问题也会被转成向量。
然后系统会问：哪些 chunk 和这个问题在语义上最接近？
这就是向量检索。检索完以后，就回到我们最初的步骤，把检索到的内容拼接回问题：也就是问北京烤鸭到底是什么菜系。然后让大模型回答就完事了。
2. 知识图谱：完整的推理链路约束
知识图谱的思维模型完全不同。它不是把文档切成碎片去检索，而是把知识拆成**「实体 + 关系」**的三元组。
还是北京烤鸭的例子，用知识图谱表示：
(北京烤鸭, 属于菜品类型, 北京菜) (北京菜, 属于, 中国菜) (北京烤鸭, 主要食材, 鸭肉) (北京烤鸭, 烹饪方式, 烤制) (鸭肉, 来源于, 鸭子) (鸭子, 属于, 禽类) (禽类, 属于, 动物)
这张图不仅能回答「北京烤鸭属于什么菜」，还能回答 RAG 很难直接回答的推理型问题：
「北京烤鸭的主要食材来自哪类动物？」
推理路径是：
北京烤鸭 → 鸭肉 → 鸭子 → 禽类 → 动物
这就是知识图谱的核心优势：它能沿着关系链路做多跳推理，而不是只在语义相似的文本块里打转。
3.为什么它们经常被混淆
- • 因为它们都被叫作“知识库”
- • 因为它们都能让大模型回答更准
就是这么简单的一个坑。。。
因为他俩对于AI来说，通常都会被视作外部知识库，目的也都是提升模型回答的质量，所以我搞混了，以为他俩说的是一个东西，闹了笑话。
加上网络上很多教程会说：
用 RAG 搭建企业知识库 用知识图谱搭建企业知识库
但实际上：RAG 靠外部文本证据增强回答。则是知识图谱靠结构化关系约束推理。
目标相似，路径不同。
这个时候就有反应快的观众要问了：主播主播，有没有什么方式，我既能利用外部证据，还能把本地的关系化结构用来增强推理啊？
有的兄弟，有的，Graph RAG来了。
扩展内容：Graph RAG，让AI变成可靠智囊
听名字就知道，这玩意是把RAG 和知识图谱做成一个东西了。
可以这样理解：Graph RAG就是用图结构增强 RAG 的检索和推理。
当然，这样做也会带来额外的开销，其本质上是让大模型在回答前先理解实体之间的关系，再结合文本证据生成更准确、更可解释的答案。
你不仅需要维护你的知识图谱，保证关系的一致性与正确性，还得花时间搭RAG，最后还得把接口弄上，挺麻烦的。一般都是企业级的工程才这么搞，个人搭本地知识库我并不是很推荐，真的太麻烦了。
本人实操：如何把项目变成知识图谱
我个人尝试下来，最舒服的方式是在本地把大型代码项目转化为知识图谱。
通过把你的整个代码库提前索引成本地知识图谱提前建图，后续查询直接走图谱，不再每次都全量扫文件，工具调用数量暴降 94%，速度起飞、Token 狂省、我自己已经爱上这个范式了。
实操起来也是格外的简单。最近有个很火的开源项目CodeGraph，因为它是走完全本地的，满足我的安全和隐私需求，所以我直接安装了。
安装与接入
其实以下三步都是AI完成的，我实际上就说了一句话：
帮我安装：https://github.com/colbymchenry/codegraph
第一步：安装
npm i -g @colbymchenry/codegraph
验证一下：
codegraph version# 输出：1.0.1
第二步：接入 AI 助手
CodeGraph 支持 Claude Code、Cursor、Codex CLI、Hermes Agent 等 8 种主流 AI 编程助手。我用的是 Hermes Agent，一条命令自动接入：
codegraph install --target hermes --location global --yes
它会自动在 ~/.hermes/config.yaml 里写入 MCP Server 配置：
mcp_servers: codegraph:command: codegraphargs:- serve- --mcptimeout: 120connect_timeout: 60enabled: true
重启 Hermes，搞定。
第三步：初始化项目
进入你的项目目录：
cd your-project codegraph init
我这个项目是一个做了很久的检测系统，92 文件，Python + Vue + YAML 混合，用它来跑了一遍：
◆Indexed 92 files ●1,166 nodes, 2,141 edges in 1.3s └Done
1.3 秒。92 个文件，1166 个节点，2141 条边。而且初始化之后 CodeGraph 会自动启动文件监听，后续你或 AI 改的任何代码都会自动增量同步到图谱里，不需要手动重建索引。
懒人福音啊有木有！
编程习惯的改变：五个实实在在的 before & after
我知道有人看到这，发现我没回收标题，想骂我标题党了。
但是这篇文章说了，不是简单的科普，我会如实分享这段时间我的心路历程和工作流程变化。
不再让 AI 盲目 grep
以前让 AI 理解一个功能流程，要来回 8-12 次 tool call——grep 这个、read 那个、再 grep、再 read——Token 烧了一堆，说的就是你 Claude ，每次花我一大笔真金白银。
现在一次 codegraph_explore("how does video extraction work")，直接返回相关符号、调用链、源码，AI 从「瞎子摸象」变成了「拿着地图走路」。
别的不说，剩Token是真的省，token 费用少35%！
接新项目不再恐惧
会想起来以前接新项目，前两天全花在理解代码结构上，AI 来帮忙的话，一次就给你花一堆 Token ——没办法项目真的很大啊。
现在我用 codegraph init 一秒建图，Hermes总结好之后，直接告诉我入口在哪、数据怎么流转、哪些模块是核心。
从两天才能上手，变成几分钟就能写代码。效率提升114514%。
测试精准跑
之前中转站加入aff的时候，那次测试的就不够完整，中间有些步骤会导致BUG，直接黑屏，在本地测试的时候完全没发现，最后修了半天，累的崩溃。
现在有了 graph 以后， codegraph affected 只跑真正受影响的测试，配合 git diff --name-only HEAD | codegraph affected --stdin 一条命令搞定。覆盖率问题无需担心。
反馈循环从分钟级缩到秒级，而更短的反馈循环 = 更高的开发效率。
后记：
回顾一下整个过程：
- 1. 我最初搞混了 RAG 和知识图谱，拉了个大的。
- 2. 花时间搞清楚了它们分别是「翻书」和「画地图」两种完全不同的模式
- 3. 了解了 Graph RAG，但发现对个人开发者太重
- 4. 最后找到了 CodeGraph——一个轻量的、本地的、开箱即用的代码知识图谱方案
- 5. 接入之后，我的编程习惯发生了五个实实在在的改变
这篇文章的标题我没有用「CodeGraph 使用教程」，因为工具本身不重要，网上开源的很多，重要的是它改变了你什么。
如果你也经常遇到 AI 助手在你的项目里「迷路」——反复 grep、重复 read、理解偏差、遗漏关键依赖——不妨试试给它的脑子装一张地图。
