这个工具让 AI 代码助手不再＂失忆＂,我实测了 go-tiny-claw 项目

故事是这样的。

最近我在维护一个叫 go-tiny-claw 的项目，Go 语言写的，一个轻量级的 AI Agent 引擎。代码量不算大，但模块挺多，调用关系也复杂。

每次我想搞清楚"这个函数在哪里被调用"或者"改这个模块会影响哪些部分"的时候，就得开个 AI 助手问。结果呢，它每次都是从零开始，完全不记得我们之前聊过什么。

我就想，这 AI 助手怎么跟金鱼似的，转头就忘？

我跟几个做开发的朋友聊过，发现大家都有类似的困扰。

代码库一大，AI 助手就懵了。它不知道整个项目的架构是什么样的，不知道函数之间的调用关系，更不知道你上次让它分析过什么。每次对话都像第一次见面，得重新解释一遍项目背景。

更麻烦的是，你想让它帮你理清调用链，它就得反复 grep、read 文件，Token 消耗蹭蹭往上涨，效率低得让人着急。

我就一直在想，有没有什么工具能让 AI 助手真正"记住"你的代码库？

前几天刷 GitHub 的时候，看到一个叫 codebase-memory-mcp 的项目。其实吧，它就是给 AI 代码助手装了一个"记忆中枢"。

怎么理解呢？

传统的方式，AI 助手看代码就像瞎子摸象，每次只能看到一小块。而 codebase-memory-mcp 会先把整个代码库构建成一个知识图谱，把函数、方法、结构体、调用关系这些都理清楚，存成一个结构化的数据库。

这样一来，AI 助手就不是从零开始了，而是直接查询这个图谱，一下子就能看到整个项目的全貌。

我寻思了一下，这玩意儿挺有意思的，就决定拿来试试。

我本来以为这种工具配置起来会很麻烦，结果发现特别简单。

codebase-memory-mcp 是一个单一的二进制文件，下载下来就能用，不用装什么运行时库，也不用配 Docker。对于我这种懒人来说，简直是福音。

安装完之后，我把它配置到了 WorkBuddy 的 MCP 服务器里，重启一下就行。

整个过程不到五分钟。

安装完之后，我还发现它有个 UI 界面，可以可视化整个知识图谱。

启动命令很简单：

然后打开浏览器访问 http://localhost:9749，就能看到一个 3D 的知识图谱。

特别是它的 graph 标签页，可以直接查看项目的知识图谱。比如访问 http://localhost:9749/?tab=graph&project=E-go-tiny-claw，就能看到 go-tiny-claw 项目的完整图谱：

go-tiny-claw 项目的知识图谱可视化

对于我这种视觉型的人来说，这比看命令行输出舒服多了。特别是想快速了解项目整体结构的时候，一眼就能看明白。

光看静态图不过瘾，我直接上手操作了一遍，顺手录了个动图。

操作实录：拖拽旋转、滚轮缩放、点击节点

按住拖拽，整个图谱跟着转。滚轮一推，瞬间拉近。点击节点，右边直接弹出详情。整个过程行云流水，完全不像在分析代码，倒像在玩一个星空探索游戏。

我截了几个关键瞬间。

刚加载完的样子，852 个节点全部铺开，密密麻麻但井然有序。

初始状态：852 个节点全部铺开

按住左键一拖，图谱立刻跟着旋转，想从哪个角度看就从哪个角度看。

拖拽旋转：换一个角度看图谱

滚轮往前一推，直接放大，context、engine这些核心模块看得清清楚楚。

滚轮放大：拉近看核心模块

再拉远一点，模块之间的调用连线一目了然，哪些是热点区域一眼就认出来了。

拉远视角：调用连线一目了然

整个工具的工作流程大概是这样的：

codebase-memory-mcp 工作流程：安装 → 索引 → 构建知识图谱 → AI 查询 → 多场景应用

配置好之后，我迫不及待地拿 go-tiny-claw 项目试了试。

第一步是索引项目。我进入项目目录，运行索引命令：

索引完成之后，它告诉我，这个项目有 852 个节点，4113 条关系边。

我当时的反应是，这么多？？

然后我用 get_architecture 工具看了一下项目的架构概览。结果出来的时候，我愣住了。

它把整个项目的结构都理清楚了：293 个函数，166 个方法，102 个结构体，还有两个入口点，两个 HTTP 路由。

最关键的是，它还识别出了热点函数。排在第一的是 Error 函数，被调用了 42 次。我一看，确实是这样，这个函数在整个项目里被频繁使用。

这种感觉太爽了，就好像一下子从盲人摸象变成了上帝视角。

以前我想找某个函数在哪里，得用 grep 搜好几次，还得一个个文件去看。

现在呢，我直接用 search_code 工具，输入关键词就行。

比如我想找所有跟 "loop" 相关的代码，运行一下：

几秒钟就出来了，5 个相关位置，每个都标清了文件路径和行号。

我点进去一看，果然都是跟循环相关的代码，一个是飞书审批的清理循环，一个是限流器的补充循环。

这效率，简直了。

更让我惊喜的是调用链追踪功能。

我想知道 Run 函数到底是怎么工作的，它调用了哪些其他函数。以前这种分析，要么手动一个个追，要么用专门的分析工具，费时费力。

现在呢，我运行一下 trace_path 命令：

它直接把调用链给我理出来了。Run 函数被调用了 24 次，它自己调用了 22 个其他函数，包括工具执行、上下文管理、会话处理等等。

而且它还给出了复杂度分析：圈复杂度 23，认知复杂度 54。这说明 Run 函数确实是一个关键但复杂的函数，需要重点关注。

这种深度分析，以前我得花好几个小时才能搞清楚，现在几秒钟就搞定了。

还有一个功能我也挺喜欢的，就是死代码检测。

codebase-memory-mcp 会分析每个函数的调用关系，找出那些没有被调用的函数。这些函数要么是遗留代码，要么是还没用到的功能。

我用 get_architecture 工具看了一下边界分析，发现 engine 模块到 tools 模块有 44 次调用，是最活跃的边界。这意味着这两个模块之间的耦合度比较高，重构的时候需要特别小心。

这种分析对于技术债务清理特别有用，能帮你快速定位哪些代码可以安全删除。

用了几天之后，我觉得 codebase-memory-mcp 确实解决了一个真实的问题。

以前 AI 助手看代码，就像一个新来的实习生，每次都要重新熟悉项目。而现在，它更像是一个已经在项目里待了很久的老同事，对整个代码库了如指掌。

这种转变，不只是效率的提升，更是思维方式的转变。

你不再需要反复解释项目背景，AI 助手已经"记住"了。你不再需要多次 grep 来理清关系，图谱里都写得清清楚楚。你不再需要担心 Token 消耗，一次查询就能获取完整信息。

更重要的是，它让 AI 代码助手真正成为了一个可以长期协作的伙伴，而不是一个每次都要重新认识的陌生人。

我有时候觉得，AI 代码助手的发展方向，就是从"无状态"到"有记忆"。

codebase-memory-mcp 只是这个方向上的一个尝试，但它让我看到了可能性。

想象一下，如果每个 AI 助手都能真正"记住"你的代码库，那开发体验会是什么样的？

你打开 IDE，AI 助手已经熟悉了整个项目，知道每个模块的功能，知道函数之间的调用关系，甚至知道上次重构遗留下来的技术债务。

你提出一个问题，它不是从零开始搜索，而是直接从知识图谱里获取答案。

这种感觉，想想就让人兴奋。

如果你也在维护复杂的代码库，如果你也受够了 AI 助手的"失忆"问题，不妨试试 codebase-memory-mcp。

安装简单，效果明显，而且完全本地化，不用担心代码安全问题。

你可以先拿个小项目试试，感受一下这种"有记忆"的 AI 助手是什么体验。

对了，你平时用什么工具来理解代码库？有没有遇到过类似的"AI 失忆"问题？欢迎在评论区聊聊，说不定能碰撞出新的思路。