详情

首页手游攻略 01|AI 改个代码读了 40 万 token?我把 codebase-memory-mcp 接上后只剩 3 千

01|AI 改个代码读了 40 万 token?我把 codebase-memory-mcp 接上后只剩 3 千

佚名 2026-07-07 09:11:52


一、起因:AI 改一个函数,先把我项目读了个底朝天

最近用 AI 改代码,我越来越受不了一件事。

我让 Cursor 帮我改一个稍微核心点的函数,比如"把这个 createOrder 的参数加一个字段,顺便看看哪些地方调了它"。

它的做法是什么?

先 grep 一遍 createOrder然后挨个打开命中的文件一个文件读完不够,再去读它 import 的文件来回十几次工具调用几万 token 烧掉了,最后还跟我说"可能还有遗漏,建议你手动确认一下"

我盯着 token 用量那一刻是真的肉疼。它不是在思考,它是在用蛮力翻书。

直到我看到 DeusData/codebase-memory-mcp 这个项目,它论文里那句话直接戳到我:

40 万 token vs 3 千 token。这不是优化,这是换了个物种。


二、它是什么:把代码库变成一张"可查询的知识图谱"

一句话定位:

拆开几个关键词:

MCP 服务器:它走 Model Context Protocol,能直接挂到 Claude Code、Cursor、VS Code 这些支持 MCP 的客户端上。知识图谱:它不是把代码切成文本块,而是抽出"函数、类、调用关系、继承关系、HTTP 路由"这些代码事实,建成一张图。持久化:索引一次存进本地 SQLite,之后查询是亚毫秒级,不用每次重算。C 单文件二进制:一个静态二进制,无依赖,下载就能跑,macOS / Linux / Windows 都行。

它支持 158 种语言的语法解析,其中 9 个主流语言族还有更深的语义类型推断。


三、它跟我之前理解的"代码搜索"完全不是一回事

我一开始以为这就是个"更快的 grep"或者"又一个 RAG 代码检索"。看完发现完全不在一个层面。

三者的本质区别:

维度

grep

RAG

codebase-memory-mcp

数据形态

文本

embedding 向量

代码事实图谱

抽象层

字符匹配

文本相似

结构 / 语义关系

适合

找 TODO 注释

模糊语义搜索

调用链、影响分析、重构

token

极低

最关键的区别:grep 和 RAG 都还在"文本窗口里挑东西",而这个项目做的是"把代码变成可以问关系的图"。

你能问它"改这个函数会影响哪些文件"、"这个接口被谁调用"、"哪些代码是死代码"——这些问题 grep 根本答不了,RAG 也只能给你一堆模糊片段。


四、接进来:我整理的最小上手路径

这一节我按"如果我重新接一次"的思路梳理。命令和配置都是真实可用的,我只是按它现在的形态整理一遍。

第一步:拿到二进制

它是单一静态二进制,也发了 npm 包。核心就是把可执行文件放好,没有一堆依赖要装。

第二步:配置到 Cursor / Claude Code

它作为 MCP 服务器,通过 stdio JSON-RPC 跟客户端通信。配置思路跟接任何 MCP server 一样,在客户端的 MCP 配置里加一条,指向这个二进制即可(具体 JSON 看项目 README,不同客户端字段略有差异)。

它官方说兼容 11 款 agent,包括 Claude Code、Codex、Gemini CLI、Cursor 等。

第三步:第一次索引

接好之后,最妙的体验是——你在 Claude Code 里直接说一句:

它就触发索引了。

一个 1,200 个 Python 文件、8,500 个函数、420 个类、15 条 HTTP 路由的项目,索引大约 14 秒。

夸张点的:Linux 内核(2800 万行、7.5 万文件),官方说 3 分钟完成索引(这个数字是项目自报,未经第三方独立复现,我标注一下)。

第四步:之后就直接问

索引完,AI 查代码不再 grep 了,而是通过 MCP 工具直接查图谱。延迟亚毫秒级,token 几百起步。


五、第一次用我最直观的三个感受

我把它套进自己的使用习惯里推演了一遍,最戳我的是这几点:

1. token 真的降下来了

以前一个"影响分析"类问题,AI 得读十几个文件,几万 token。现在一条结构化查询,几百 token 拿到结果。一个月下来 API 账单的差别是肉眼可见的。

2. AI 不再"我觉得可能还有遗漏"

grep 的本质是不完整的。AI 自己也知道,所以经常补一句"建议你再手动确认"。

知识图谱不一样——调用关系是从 AST 抽出来的,它能说全"谁调用了这个函数",而不是"我搜到的这几个"。这个确定性对重构特别重要。

3. 索引一次,反复查

RAG 每次要重算、grep 每次要重扫。它索引一次存盘,后面查询都是在本地 SQLite 上跑,还有后台线程做增量重索引。改了代码不用全量重来。


六、先把丑话说前面:它不是万能的

我也得泼盆冷水,免得你抱着不切实际的期待去用。

找 TODO 注释这种纯文本活,grep 更快。它的强项是结构,不是文本匹配。小项目(< 1 万行)没必要。grep 就够了,上知识图谱是杀鸡用牛刀。9 种 Hybrid LSP 语言之外(比如 Haskell、Elixir),只有语法解析没有深度语义,效果打折。高度动态生成 / 混淆压缩过的代码,AST 抽不出来,它也没辙。

技术选型最忌"看到好东西就想全场用"。它解决的是大中型代码库里的结构性问题,对上这个场景才香。


七、总结:它瞄准的是 AI 编程里一个真问题

写到这我对它的第一印象已经很清楚了。

现在的 AI 编程助手有个被严重低估的瓶颈:它们理解代码库的方式太原始了。要么 grep,要么 RAG,本质都是"在文本里捞"。代码明明是有结构的——函数会调用函数,类会继承类,服务会调用服务——这些结构信息白白浪费了。

codebase-memory-mcp 做的事就是把这层结构捡回来,建成图,让 AI 用"查关系"代替"翻文件"。

它不是又一个炫技玩具。它瞄准的是一个每个重度 AI 编程用户都在默默忍受的痛——token 烧得冤,答案还不全。

下一篇我会把它的内部拆开:tree-sitter 怎么解析 158 种语言、Hybrid LSP 怎么补语义、知识图谱长什么样、它暴露的 14 个 MCP 工具分别能干啥。


相关资讯
点击查看更多
游戏推荐
推荐专题
热门阅读
推荐下载