CodeGraph 代码地图
这两天我一直在想一件事：AI 编程助手写代码越来越顺，但它理解项目的方式，很多时候还是有点笨。
你让它改一个陌生项目，它先搜文件，再读文件，再顺着函数名继续找。项目小还好，项目一大，时间和 token 都花在“找路”上。CodeGraph 吸引我的地方就在这里：它不是再做一个聊天窗口，而是先给 AI 助手画一张代码地图。
为什么我会点开它
今天 GitHub Trending 里，colbymchenry/codegraph 的 stars today 排在第一。我抓到的数据是 3,688 stars today，仓库总 star 约 16,093，主要语言是 TypeScript。
不过我不太想把重点放在“它涨了多少 star”上。热度只能说明大家今天注意到了它，不代表它一定好用。
我真正感兴趣的是它背后的需求：AI 工具要接手更复杂的任务，就不能每次都从零开始翻项目。
它想解决什么
按 README 的描述，CodeGraph 会在本地解析代码，把函数、类、调用关系、导入关系、继承关系、路由关系整理成知识图谱，再通过 MCP server 提供给 Claude Code、Cursor、Codex CLI 这类工具查询。
换句话说，它做的是“提前读项目”。
以前模型要理解一个功能，可能会先 grep 一个关键词，再打开几个文件，再继续顺着调用链看下去。CodeGraph 想把这部分变成结构化查询：这个函数被谁调用，某个文件影响哪里，某条路由最后落到哪个处理函数。
这件事听起来不花哨，但很实用。尤其是老项目、大项目、目录结构复杂的项目，真正浪费时间的往往不是写代码，而是先搞明白代码在哪里。
我最在意的点
我比较在意三件事。
第一，它强调本地运行。README 里提到索引结果放在本地 SQLite，使用 FTS5 做全文搜索，也强调不需要 API key，不把代码发到外部服务。对私有项目来说，这一点很重要。
第二，它不是单纯做文本搜索。README 提到它使用 tree-sitter 解析源码，抽取符号、调用和导入关系。也就是说，它关心的是代码之间的关系，而不只是某个词出现在哪里。
第三，它接 MCP。这个方向比较自然。现在很多 AI 编程工具都在接 MCP，CodeGraph 如果能稳定提供“项目结构上下文”，就可能成为 AI 写代码前的第一步。
当然，这些只是基于 README 和公开信息的判断。我还没有在本地完整跑通它，所以不会把 README 里的 benchmark 当成自己的测试结论。
如果我要试用
README 给的入口很简单：
1 | |
已经安装后，可以在项目里初始化：
1 | |
我会先拿一个中等规模的项目试，不会一上来就放到很大的生产仓库里。原因也简单：这种工具最怕“看起来很聪明，但索引慢、同步慢、结果不稳”。
如果它只是多一个配置步骤，却没有明显减少模型读文件的次数，那意义就不大。
我会怎么判断它有没有用
我会看几个很具体的点。
- 初始化索引要多久。
- 改完文件后，索引能不能及时更新。
- AI 助手会不会真的优先查 CodeGraph，而不是继续到处读文件。
- 查询结果能不能帮我更快定位调用链。
- 小项目里会不会反而增加负担。
这里我更关心“省不省事”，而不是 benchmark 数字漂不漂亮。
因为日常写代码不是跑论文实验。工具要真有用，应该能让我少问几轮、少翻几次文件、少等几次无效搜索。
适合什么人
如果你只是偶尔让 AI 改一个小脚本，CodeGraph 可能没必要。
但如果你经常让 AI 助手读项目、改业务逻辑、追调用链，或者项目本身比较大，那它就值得试一下。它解决的不是“生成代码”，而是“让模型更快进入项目状态”。
我觉得这个方向会越来越重要。AI 编程工具往后拼的不只是模型会不会写代码，还包括它拿上下文的方式够不够聪明。
CodeGraph 这类工具的价值，就在于把“翻文件找路”这件事提前做好。模型少走一点弯路，人也少等一点。