AI 编程最烧钱的地方,可能不是写代码,而是“找代码”

阅读全文预计耗时 9 分钟。

几秒钟速读版

这篇讲什么

这次看的项目是：

https://github.com/colbymchenry/codegraph。

它不是新的 IDE，也不是新的大模型。

它做的是一件更底层的事：先把你的代码库预先索引成一张本地知识图谱，再通过 MCP 工具交给 Claude Code、Cursor、Codex、Hermes Agent 这类 AI coding agent 使用。

换句话说，它想解决的是 AI 编程里一个很贵、很常见、但经常被忽略的问题：

AI 在真正改代码前，先花大量 token 和工具调用到处找代码。

为什么要看

现在很多人聊 AI 编程，只盯模型会不会写、会不会修 bug。

但你真把 Agent 放进一个中大型仓库，它第一步往往不是写代码，而是搜索、grep、读文件、找调用链、找入口、找影响范围。

这一步很耗钱，也很耗时间。

CodeGraph 的思路是：别让 Agent 每次都像第一次进公司。

先给它一张代码地图。

你能记住什么

CodeGraph 是一个本地优先的代码知识图谱工具，核心是 tree-sitter + SQLite + MCP。
它支持 Claude Code、Cursor、Codex CLI、opencode、Hermes Agent、Gemini CLI、Antigravity IDE、Kiro。
README 给出的最新基准测试里，7 个真实开源仓库平均降低 25% 成本、57% token、23% 时间、62% 工具调用。
它不是自动修 bug 的神器，而是让 Agent 少做重复探索。
它 100% 本地运行，不需要 API key，不把代码发到外部服务。
真正适合它的场景，是中大型代码库、架构理解、调用链追踪、影响范围分析和多 Agent 协作。

适合谁

适合已经在认真用 AI coding agent 的开发者。

尤其是这几类人：

仓库文件很多。

Agent 经常先 grep 一圈再干活。

你问的是架构、调用链、影响范围，而不是单文件小改动。

你同时用 Claude Code、Cursor、Codex、Hermes 这类工具，希望它们共享一层本地代码理解能力。

不适合谁

如果你只在一个几十个文件的小项目里让 AI 改两行代码，CodeGraph 不一定是刚需。

小仓库里，模型自己搜一搜也够快。

CodeGraph 的价值，主要在“仓库变大、关系变复杂、Agent 探索成本开始失控”以后出现。

完整正文版

我先说结论：AI 编程接下来最值得关注的，不只是哪个模型更会写代码。

还有一个更现实的问题：

模型写代码前，到底花了多少钱在“找代码”。

很多人没意识到这一点。

你让 Claude Code、Cursor、Codex 进一个陌生仓库，它不是一上来就改。

它会先搜。

搜文件名。

搜函数名。

读 README。

grep 入口。

看调用方。

找测试。

再开几个探索流程，把相关文件读一遍。

这一步在人类看来很正常。一个新同事接手项目，也得先摸一遍目录。

但对 AI Agent 来说，这些动作每一步都要消耗 token、工具调用和等待时间。

更麻烦的是，它下一次进来，可能又要重新摸一遍。

CodeGraph 这个项目，切的就是这里。

它不是让 AI 更聪明。

它是先把代码库变成 AI 更容易读的样子。

CodeGraph 到底是什么

CodeGraph 的定位很清楚：给 AI coding agents 用的预索引代码知识图谱。

仓库介绍里写的是：Pre-indexed code knowledge graph for Claude Code, Codex, Gemini, Cursor, OpenCode, AntiGravity, Kiro, and Hermes Agent。

翻成人话：

它会提前扫描你的项目，把代码里的符号、函数、类、方法、导入、调用关系、继承关系、路由关系等信息抽出来，存成本地数据库。

然后 Claude Code、Cursor、Codex CLI、Hermes Agent 这类工具，可以通过 MCP 调它。

这和普通 grep 最大的区别是：

grep 只知道“哪一行出现了这个词”。

CodeGraph 试图知道“这个函数是谁、被谁调用、会影响谁、从哪个入口走到这里”。

这就是代码地图和全文搜索的差别。

全文搜索像在公司群里搜关键词。

代码知识图谱更像你手里有组织架构图、业务流程图和座位表。

你不是只知道某个人名字出现在哪里。

你还知道他在哪个部门、汇报给谁、跟谁协作、改他会牵动哪些人。

这对 AI Agent 很重要。

因为 Agent 最怕的不是不会写某个函数，而是不知道该改哪个函数。

它为什么会火

CodeGraph 容易传播，不是因为它概念新奇。

而是它戳中了 AI 编程的一个真实浪费。

现在的 AI coding agent 很像一个很聪明但没有公司记忆的新员工。

你每次把它放进仓库，它都要问：

入口在哪？

这个函数谁调用？

路由怎么进 controller？

改这个 service 会不会影响测试？

这个接口到底有几个实现？

如果仓库小，这些问题不贵。

如果是 VS Code、Django、Tokio 这种规模，探索成本就开始明显了。

README 里的 benchmark 直接把这个成本摆出来。

项目在 7 个真实开源代码库上做了对比：VS Code、Excalidraw、Django、Tokio、OkHttp、Gin、Alamofire。

测试方式是让 Claude Code headless 回答同一个架构问题。

一组开 CodeGraph MCP。

一组不开。

每组跑 4 次，取中位数。

结果是：平均 25% 更便宜、57% 更少 token、23% 更快、62% 更少工具调用。

这里我更看重的不是 25% 这个数字。

数字会随着模型、问题、仓库、版本波动。

我更看重的是方向：

当代码库足够大，AI 的“找路成本”已经高到值得单独做一层基础设施。

这就是 CodeGraph 的价值。

它不是在写代码环节省钱。

它是在写代码之前，先减少乱找。

它怎么工作

CodeGraph 的技术路线不玄。

第一步，用 tree-sitter 解析代码。

它会从代码里抽取函数、类、方法、调用、导入、继承、实现等结构信息。

第二步，把这些信息存到本地 SQLite 数据库。

默认位置是项目下的 .codegraph/codegraph.db。

里面有 symbols、edges、files，还有 FTS5 全文搜索。

第三步，通过 MCP server 暴露给 Agent。

README 里列出的 MCP 工具有这些：

codegraph_search codegraph_context codegraph_trace codegraph_callers codegraph_callees codegraph_impact codegraph_node codegraph_explore codegraph_files codegraph_status

这几个工具对应的，其实就是 Agent 最常见的代码理解问题。

我要找某个符号，用 search。

我要理解某个任务相关的代码上下文，用 context。

我要看 A 怎么走到 B，用 trace。

我要知道谁调用它，用 callers。

我要知道它调用谁，用 callees。

我要改它之前看影响范围，用 impact。

以前 Agent 可能要通过多轮 grep、find、Read 拼出答案。

现在它可以直接问代码图。

这就像以前你让新人自己翻公司文档，现在你给他一个内部地图系统。

不是不让他读源码。

而是先告诉他应该读哪里。

它对大仓库更有意义

CodeGraph 的收益不是平均撒在所有项目上。

README 里的数据很明显。

在 VS Code 这种约 1 万文件的 TypeScript 仓库里，工具调用减少 80%，token 减少 70%。

在 Tokio 这种 Rust 项目里，工具调用减少 79%，token 也减少 70%。

但在 Gin、Alamofire 这类更小的仓库里，收益就窄一些。

Gin 的时间只快了 9%。

Alamofire 的工具调用只少了 13%。

这说明 CodeGraph 不是魔法。

它更像一条分界线：

仓库越大，调用关系越复杂，入口越分散，AI 自己摸索的成本越高，CodeGraph 越有用。

小项目里，模型直接读文件也不慢。

大项目里，Agent 如果每次都从零开始搜索，就像让一个外包每次上班都重新问公司大门在哪。

这件事本身就不合理。

所以 CodeGraph 的传播点不应该写成“让 AI 编程便宜 25%”。

更准确的说法是：

它把 AI 编程里最浪费的一段流程，单独拎出来做成了基础设施。

这个点，对真正用 Agent 干活的人很有吸引力。

它支持的不只是 Claude Code

CodeGraph 另一个重要点，是它没有绑死一个 Agent。

README 写的支持对象包括：

Claude Code。

Cursor。

Codex CLI。

opencode。

Hermes Agent。

Gemini CLI。

Antigravity IDE。

Kiro。

这说明它更像一层横向基础设施，而不是某个 IDE 的插件。

如果未来开发者只用一个 AI 工具，这层价值一般。

但现实趋势不是这样。

很多人已经在混用：

Cursor 写前端。

Claude Code 做重构。

Codex CLI 跑命令行任务。

Hermes Agent 做自动化和调度。

不同 Agent 都要理解同一个仓库。

如果每个 Agent 都自己重新 grep 一遍，成本会重复浪费。

CodeGraph 想做的是共享地图。

一次索引，多处使用。

这个方向很值得看。

因为 AI 编程工具越多，围绕它们的“公共基础设施”就越重要。

前一波大家做的是 Agent。

下一波会有人专门做 Agent 的记忆、权限、任务调度、上下文压缩、代码索引、运行监控。

CodeGraph 属于代码索引这一层。

它不抢 Agent 的活。

它给 Agent 铺路。

本地优先，是它的关键卖点

CodeGraph 还有一个点很讨开发者喜欢：100% local。

代码不出本机。

不需要 API key。

不依赖外部服务。

索引落在项目里的 SQLite 数据库。

这对代码工具很重要。

因为很多公司的代码不能随便发出去。

即使你允许模型读代码，也不代表你愿意再把索引、符号关系、调用链交给另一个云服务。

CodeGraph 走本地路线，降低了使用门槛。

安装上，它也在尽量减少麻烦。

README 里写得很直接：No Node.js required。

macOS / Linux 可以这样装：

curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh

Windows PowerShell：

irm https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.ps1 | iex

如果你已经有 Node，也可以：

npx @colbymchenry/codegraph npm i -g @colbymchenry/codegraph

项目初始化：

cd your-project codegraph init -i

当前 README 里说，codegraph init 会创建本地 .codegraph/ 索引目录，-i 会顺手构建初始图。

CHANGELOG 里也提到，后续 codegraph init 会默认构建初始索引，-i 继续兼容。

所以你可以把它理解成两步：

先装 CodeGraph。

再给项目建一张本地代码地图。

它的边界也要讲清楚

CodeGraph 不是“装了以后 AI 自动变大神”。

它解决的是代码探索成本，不是模型推理能力。

如果 Agent 不直接调用 CodeGraph，还是习惯开子代理、grep、Read 文件，那 CodeGraph 可能反而变成额外开销。

README 里也说得很明白：CodeGraph only helps when queried directly。

这句话很关键。

它真正要求的是工作流变化：

Agent 要先问 CodeGraph。

CodeGraph 给出上下文、调用链、影响范围。

Agent 再去读少量关键源码。

这套流程跑顺了，才会省。

还有，CodeGraph 默认会排除依赖、构建产物、缓存目录、大于 1MB 的文件，也会遵守 .gitignore。

这通常是好事。

但如果你确实想索引某些 vendored 代码，就要显式处理。

再比如索引不是永远实时无延迟。

它有文件 watcher，有默认 2 秒 debounce，也有 staleness banner 提醒 Agent 哪些文件还没同步。

这套设计已经很工程化，但你不能把它理解成“任何时候都绝对实时”。

它更像一个可靠的本地地图系统。

地图会自动更新。

但刚修路的那几秒，系统会提示你：这段路可能还没同步，必要时直接看现场。

我怎么看

CodeGraph 这个项目，值得写的地方不是“又一个 MCP 工具”。

MCP 工具现在太多了。

真正值得写的是它背后的趋势：AI coding agent 开始需要专门的代码理解基础设施。

过去，AI 写代码像一个聊天框能力。

你问，它答。

现在，AI 写代码越来越像一个工程系统。

它要进仓库。

要找入口。

要理解调用链。

要判断影响范围。

要跑测试。

要跨多个工具协作。

一旦进入这个阶段，“上下文怎么来”就会变得非常重要。

以前上下文靠人复制粘贴。

后来靠 Agent 自己搜索文件。

再往后，就会出现专门的上下文基础设施。

CodeGraph 就属于这一类。

它不是最性感的那层。

但它很实用。

因为真正长期使用 AI 编程的人，迟早会发现：

让模型写代码只是第一步。

让模型每次都准确找到该看的代码，才是更贵、更容易被低估的一步。

收藏版清单

如果你想判断 CodeGraph 值不值得试，看这几条：

你的项目是不是已经大到“找代码”本身很费时间？
你的 Agent 是不是经常先 grep/read 一堆文件再进入正题？
你是不是经常问调用链、影响范围、架构流向这类问题？
你是不是同时用 Claude Code、Cursor、Codex、Hermes 等多个 AI 编程工具？
你的代码是否适合本地索引，而不是每次全靠模型临时搜索？
你能不能接受每个项目维护一个 .codegraph/ 本地索引？

前四条如果命中两条以上，可以试。

如果只是小项目单文件改动，先不用急。

下一步建议

想试的话，不要一上来就接最复杂的生产仓库。

我建议这样来：

第一步，找一个中等规模、你熟悉的项目。

第二步，安装 CodeGraph。

第三步，跑 codegraph init -i 建索引。

第四步，把它接到你常用的 Agent，比如 Claude Code、Cursor、Codex CLI 或 Hermes Agent。

第五步，别先让它修 bug，先问结构问题。

比如：

这个请求从路由到数据库怎么走？

这个函数被哪些地方调用？

改这个 service 会影响哪些测试？

这个接口有哪些实现？

如果这些问题明显少读文件、少绕路，再把它放进真实开发流程。

不要反过来。

别一上来就用它替你大改生产代码。

先验证它的地图准不准，再让 Agent 开车。