21.9k 星的本地代码图谱
colbymchenry/codegraph 这两周 GitHub 星标爬到了 21.9k，热度仍在上涨。它解决的问题在 Cursor、Claude Code 用户里很普遍——AI 工具在面对中大型代码库的时候，全文 grep 加读几个文件的方式效率低、覆盖率差，经常给出的修改建议是基于片段的猜测。CodeGraph 把代码库的结构关系做成本地图谱，让 AI 工具可以拿着这张图谱去做更精准的检索和推理。
tree-sitter 加 SQLite 的实现路线
具体怎么实现的？CodeGraph 在仓库根目录跑一遍之后，会用 tree-sitter 解析所有源文件，提取函数、类、变量、import 关系，存到本地的一份 SQLite 文件里。这份文件就是项目的代码图谱——一张以符号为节点、以调用关系/继承关系/引用关系为边的有向图。Cursor、Claude Code、Aider 这些工具可以通过 CodeGraph 提供的 CLI 或 MCP 接口查询这张图：比如”这个函数被哪些地方调用”、”这个类有哪些子类”、”修改这个 API 会影响哪些文件”。
作者 Colby McHenry 是 Stripe 前工程师，他在仓库 README 第一行就写明立场：”我不希望我自己十年的 side project 全部喂给云端 AI 公司，所以做了这个工具。” 这句话本身就解释了项目为什么会爆——它说出了很多企业开发者不便明说的顾虑。
三个差异化点
它和已有方案的区别在三个点。第一，本地化。所有解析和图谱构建都在你的机器上完成，不上传任何代码到云端。这对企业用户和处理私有代码的开发者来说是必须的——很多公司用 Cursor 的时候不得不把整个仓库的索引交给 OpenAI/Anthropic，CodeGraph 截断了这条链路。第二，多语言。tree-sitter 已经覆盖了 100 多种语言，CodeGraph 的初版重点支持 Python、TypeScript、Rust、Go、Java，下一步会加 C++ 和 Elixir。第三，速度。一个 50 万行的中等规模仓库，全量解析时间在 5 到 15 分钟，增量更新时间在秒级。
仓库 README 里给的几个使用场景挺实在。比如”我要把一个公共 API 改名，告诉我所有需要改的地方”——传统 LSP 也能做，但 LSP 在跨语言（Python 和 TypeScript 都用同一套接口）的场景下经常失败，CodeGraph 因为是基于 tree-sitter 的统一解析器，跨语言关系也能识别。再比如”我要重构这个目录，AI 帮我看哪些函数耦合最深”——CodeGraph 输出图的入度/出度统计，AI 拿这个数据再去推荐重构顺序。
Cursor 用户给出的反馈
Cursor 用户已经把 CodeGraph 配成 MCP 服务用了一段时间，反馈集中在两点：一是它让 Claude/GPT 在处理大仓库时的幻觉式修改显著减少——不会再出现”AI 改了一个函数但没意识到三处调用方需要同步改”的情况；二是它对 AI agent 的多步任务很友好，agent 能用图谱来规划修改路径，而不是每一步都重新读代码。Aider 作者 Paul Gauthier 在 X 上转发时写：”这是我等了一年的工具，我们 aider 内置的 repo-map 终于可以下岗了。”
反云端潮流的产品形态会越来越多
21.9k 星这个数据放到 GitHub 工具类项目里属于第一梯队。和它定位接近的项目有 sourcegraph 的 cody（闭源方向）、aider 自带的 repo-map、还有一些早期的 ts-morph 包装器。CodeGraph 的差异化是轻量、本地、零数据外发。一行 npm install 就能用，不依赖任何云端服务或注册账号。这种产品形态在 AI 工具普遍走云端订阅路线的当下相当反潮流，但它精确击中了一类用户：写企业代码、写有合规要求代码、或者单纯不想把自己几年的 side project 喂给云端 AI 公司的开发者。AI 工具的下一波分化大概率沿着云端便利与本地隐私这条线展开，CodeGraph 是后者的早期信号。
参考：GitHub 仓库
