先问一个问题：你让 AI 帮你改代码的时候，最烦什么？
对我来说，最烦的是它每次都像第一次见这个项目一样，需要重新理解代码结构。
我来描述一下这个场景：
我："把这个 Service 里查询用户的方法改一下，用 LambdaQueryWrapper 替换原来的写法。"
然后它开始读文件。先读 Service 接口，再读 ServiceImpl 实现，再读 Entity，再读 Mapper……一通操作下来，几千 Token 已经没了。好不容易读完了，它说"好的我理解了"，然后改完交差。
下一轮对话，我又让它改另一个方法。好嘛，它又把刚才读过的文件重新读一遍。
一次两次还行，一天几十次交互，光翻文件就翻掉大几万 Token。每个月 Token 账单里至少有一半是花在"AI 反复读已经读过的代码"上。
这就好比你每天去一家餐厅吃饭，每次都要跟厨师介绍一遍"我喜欢吃辣的、不要香菜、米饭少一点"。第一天厨师记住了，但第二天你又得重新说一遍。搁谁谁受得了？
根本原因在于：Hermes 的会话记忆是面向自然语言对话的，不是面向代码的。
它记得住你上一句说了什么，但记不住"这个 Controller 的路径是什么"、"这个 Service 依赖了哪些类"、"这个接口有多少个实现"。每次都要重新去文件系统里查，每次都要重新 parse，每次都要重新理解。
那有没有办法让 AI 一次性把代码结构记下来，以后直接查呢？
有的，这就是 codebase-memory-mcp 干的事。
codebase-memory-mcp（全称很绕口，后面简称 CBM）是一个基于 MCP 协议的代码知识图谱服务器。GitHub 地址：https://github.com/DeusData/codebase-memory-mcp
它的工作流程是这样的：
之后 AI 想问任何关于代码的问题，直接查知识图谱就行，不用再碰文件系统。
来看看数据：
| 指标 | 数据 |
|---|---|
| 解析语言数 | 158种 |
| 索引速度 | Linux 内核（2800万行）3分钟 |
| 查询速度 | 亚毫秒级（<1ms） |
| Token节省 | 官方说 99%，实测 90%+ |
| 存储格式 | LZ4 压缩 SQLite |
| 依赖 | 零，单文件二进制 |
我自己的 nsw-project 项目有 6 个后端服务 + 2 个前端，总共 31 万多个代码节点、213 万条调用关系，索引起来也就几秒的事。
对比一下以前的方式：
传统方式（查文件）：
AI 要理解 getStatsCards 这个方法干了啥 → 找到文件 → 打开 → 读 100 行 → 分析 → 得出结论。消耗 Token：3000+，时间：3-5 秒。
CBM 方式（查图）： AI 查知识图谱 → 直接拿到方法的定义、调用者、被调用者、行号范围 → 需要详细代码再读具体行。消耗 Token：300以下，时间：<1 秒。
差距接近 10 倍。
装好之后，AI 手上多了 14 个工具，覆盖了代码查询的方方面面：
| 工具 | 功能 |
|---|---|
| search_graph | 搜索代码图谱（函数名、类名、关键词） |
| get_code_snippet | 获取某个函数或类的源代码 |
| get_architecture | 获取项目架构总览（模块、依赖、路由） |
| trace_path | 追踪调用链（谁调了我、我调了谁） |
| search_code | 结合正则搜索和知识图谱的增强搜索 |
| query_graph | 用 Cypher 语法查询图谱 |
| index_repository | 索引一个项目 |
| index_status | 查看索引状态 |
| list_projects | 列出所有已索引的项目 |
| delete_project | 删除索引 |
| detect_changes | 检测代码变更和影响范围 |
| manage_adr | 管理架构决策记录 |
| ingest_traces | 导入运行时追踪数据 |
| get_graph_schema | 获取图谱的结构 |
其中最常用的是 search_graph、trace_path 和 get_code_snippet，这三个基本覆盖了日常开发 90% 的代码查询需求。
CBM 的安装不算复杂，但比 RTK 多几个步骤。
shcurl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash
如果网络状况不好，这个方案可能会超时。我推荐方案二。
先去 GitHub Releases 看看最新版本：https://github.com/DeusData/codebase-memory-mcp/releases
找到 codebase-memory-mcp-darwin-arm64.tar.gz（Mac ARM 芯片）或对应的平台版本下载。
sh# 解压
tar xzf codebase-memory-mcp-darwin-arm64.tar.gz
# 复制到 PATH 里
cp codebase-memory-mcp ~/.local/bin/
# 加执行权限
chmod +x ~/.local/bin/codebase-memory-mcp
shhermes mcp add codebase-memory --command ~/.local/bin/codebase-memory-mcp
会检测到 14 个工具，选 Y 全部启用。
执行 /reset
跟 AI 说："帮我索引一下这个项目"，它就会自动扫描当前目录的代码。
也可以手动指定项目路径，在 MCP 工具里调用 index_repository。
CBM 还有一个带 UI 的版本，可以在浏览器里看 3D 知识图谱。如果标准版用着觉得不够直观，可以装 UI 版：
sh# 下载 UI 版
curl -fSL -o /tmp/cbm-ui.tar.gz \
"https://github.com/DeusData/codebase-memory-mcp/releases/download/v0.9.0/codebase-memory-mcp-ui-darwin-arm64.tar.gz"
# 解压安装
cd /tmp && tar xzf cbm-ui.tar.gz
cp codebase-memory-mcp ~/.local/bin/codebase-memory-mcp-ui
chmod +x ~/.local/bin/codebase-memory-mcp-ui
# 启动 UI 服务
~/.local/bin/codebase-memory-mcp-ui --ui=true --port=9749
浏览器打开 http://localhost:9749，就能看到项目的 3D 知识图谱了。函数调用关系、模块依赖、热点代码一目了然，比自己翻代码直观多了。
说几个让我觉得"这玩意儿真值"的场景。
场景一：改代码前先看影响范围
我之前改了一个工具类的公共方法，改完之后总觉得心里没底，怕影响别的模块。以前的做法是全局搜索这个方法名，然后一个个打开调用的地方看。
有了 CBM 之后，我直接让 AI 查调用链，不到一秒就返回了所有调用者的列表和文件位置。确认没有影响之后才放心改了。
场景二：找 API 路由
新同事想看看项目里有哪些 API 接口，以前我得让他去翻 Controller 代码。现在直接问 CBM，它返回了 998 条路由的完整列表，GET/POST/PUT/DELETE 一目了然。
场景三：理解老代码
项目里有些老代码是几年前的人写的，逻辑比较绕。以前要读半天才能搞清楚它在干嘛。
现在直接查知识图谱，函数的调用关系、数据流向、依赖的服务，一张图就看明白了。大大降低了理解老代码的心智负担。
CBM 的底层用的是 tree-sitter 来做代码解析。tree-sitter 是一个增量解析库，跟传统编译器的区别是：它不会把代码编译成抽象语法树然后扔掉，而是维护一个可以增量更新的语法树。
这样 CBM 就能做到：
图谱存储在 LZ4 压缩的 SQLite 数据库里，索引完成后内存会自动释放，不占运行时资源。
CBM 是我最近装的最值得的 MCP 工具。它解决了一个很本质的问题：AI 不应该反复做已经做过的工作。
代码结构这种东西，索引一次就够了。以后每次查询都从图谱里拿结果，又快又省 Token。
对于项目规模比较大的兄弟（尤其是微服务架构、多模块项目），这个工具的性价比极高。装一次，每次对话都在省 Token。
本文作者:JACK WEI
本文链接:
版权声明:本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！