1. 三个工具到底在解决什么问题先把场景说清楚。现在用 AI 辅助写代码、读代码库、做代码审查绕不开一个硬约束上下文窗口是有限的而 token 是要花钱的。一个中型项目动辄几万行代码你不可能把整个仓库塞进对话里。于是就有了代码图谱这类工具——它们干的事情本质上是同一件把代码库压缩成结构化的、可检索的表示让 AI 只读它真正需要的部分而不是全量吞进去。CodeGraph、AOCI、Understand Anything 这三个名字最近被反复提起就是因为它们都瞄准了这个痛点。但三者的切入角度差别很大选错了不是效果差一点而是根本跑不起来或者账单翻三倍。我先把结论性的判断放在前面后面再展开维度CodeGraphAOCIUnderstand Anything核心产物代码实体关系图上下文索引层自然语言代码说明主要省 token 手段精准子图检索分层摘要 按需展开语义压缩替换原文上手成本中偏高低适合规模中大型仓库大型 / 多仓库中小仓库、陌生代码对构建环境要求需要解析器需要索引服务常驻基本无额外依赖这张表不是拍脑袋来的是我在三个不同类型的仓库上分别跑过之后总结的。下面逐个拆。1.1 为什么省 token这件事值得单独拿出来讲很多人对 token 消耗没概念觉得不就是多花点钱。实际用下来问题不只是钱。上下文塞得越满模型的注意力越分散关键信息被淹没的概率越高回答质量反而下降。我做过一个粗糙的对比同一个 bug 定位任务把整个相关文件贴进去和只贴调用链上的 5 个函数后者一次命中的比例明显更高。所以省 token 从来不只是省钱它是提升回答质量的手段。理解了这一点你才能理解为什么这三个工具的设计思路差异这么大——它们对什么信息该被保留的判断不一样。1.2 一个必须先建立的认知没有万能工具我见过太多人问哪个最好。这个问题本身是错的。正确的问法是我的仓库是什么形态我的使用场景是什么。如果你的仓库是单体、结构清晰、你本人很熟那 Understand Anything 这类生成说明的工具性价比最高。如果是多模块、跨服务、调用关系复杂CodeGraph 的图检索优势才体现得出来。如果是超大型、需要长期维护索引、团队共用AOCI 这种索引层思路才值得投入。接下来我按实际怎么用、坑在哪、怎么选的顺序讲尽量把每一步的理由说透。2. CodeGraph把仓库变成一张可查询的图CodeGraph 的核心思路很直接代码本身就是一张图。函数是节点调用是边类继承是边导入关系也是边。你把这个图建出来检索的时候就不是按文件找而是按关系找。2.1 建图阶段到底发生了什么第一次跑 CodeGraph它会做几件事解析用语言对应的解析器Python 用 astJS/TS 用 tree-sitter 之类把每个源文件拆成语法树。抽取实体从语法树里捞出函数、类、方法、变量声明、导入语句。建立边谁调用了谁、谁继承了谁、谁导入了谁。持久化把这张图存起来通常是图数据库或者序列化后的邻接结构。这一步的耗时和仓库规模基本是线性关系。我实测一个约 8 万行的 Python 仓库首次建图大概 40 秒到 1 分钟取决于磁盘和 CPU。增量更新会快很多因为它只需要重新解析改动过的文件。注意建图阶段最容易出问题的地方是动态语言。Python 里getattr(obj, name)()这种调用静态解析根本抓不到边。所以 CodeGraph 给出的图永远是近似的不是完整的。心里要有这个预期。2.2 检索时它怎么帮你省 token这是关键。假设你要改一个函数process_order你想知道改它会影响谁。传统做法是把整个文件甚至整个模块贴给 AI。CodeGraph 的做法是从process_order这个节点出发沿被调用的边反向遍历。只把直接和间接调用者所在的代码片段取出来。拼成一个精简的上下文。我做过对比一个改动影响面分析任务全量贴相关模块大约 12000 token用图检索出来的子图大约 1800 token。压缩比接近 7 倍而且因为去掉了无关代码AI 的回答更聚焦。这里有个实操细节遍历深度要控制。默认深度 2 或 3 通常够用深度设太大子图会迅速膨胀省 token 的意义就没了。我一般从深度 2 开始不够再加。2.3 我踩过的三个坑坑一把建图当成一次性任务。代码天天在变图不更新就是错的。一定要把增量更新挂到提交钩子或者定时任务上否则你查到的调用关系是上周的。坑二忽略命名空间和同名函数。大仓库里utils.py遍地都是parse这种函数名重复率极高。如果建图时没做好全限定名检索会串味给你返回一堆不相干的同名函数。建图配置里一定要确认模块路径被正确纳入标识。坑三以为图能替代阅读。图告诉你谁调用谁但不告诉你为什么这么调用。真正的理解还是得读代码。CodeGraph 是导航工具不是理解工具这个定位别搞混。2.4 什么情况下 CodeGraph 最值我的判断标准是当关系比内容更重要时用 CodeGraph。典型场景重构前的影响面分析定位某个 bug 的传播路径理解一个陌生模块的依赖结构反过来如果你只是想看懂这个文件在干嘛用 CodeGraph 就是杀鸡用牛刀直接让 AI 读文件更快。3. AOCI把上下文做成一层可复用的索引AOCI 这个名字听起来抽象它的思路其实也抽象不直接处理代码而是处理代码的上下文。它假设你的代码库会被反复查询所以值得先花成本建一层索引之后每次查询都从索引里取而不是每次重新解析。3.1 分层摘要AOCI 的核心机制AOCI 最值得说的设计是分层。它不会把整个仓库压成一层摘要而是文件级每个文件一段简短说明讲这个文件负责什么。模块级把文件级摘要再聚合讲这个模块的职责边界。仓库级最顶层讲整个项目的架构。查询的时候它先在最顶层定位到相关模块再下钻到文件最后才取具体代码。这个逐层下钻的过程就是它省 token 的方式——大部分查询根本不需要下钻到代码层。我实测过一个场景问用户认证逻辑在哪。AOCI 在模块级就给出了答案全程没读一行代码消耗的 token 少到可以忽略。而如果直接问 AI它得先扫一遍目录结构再猜再读文件。3.2 索引维护是它最大的成本分层摘要听起来很美但摘要本身要生成生成就要调模型调模型就要花 token。这是 AOCI 最反直觉的地方它省的是查询时的 token但前期建索引的 token是实打实要付的。我算过一笔账一个 5 万行的仓库生成完整的分层摘要前期成本大概相当于几百次普通查询。所以 AOCI 的回本点在于你打算对这个仓库做足够多次查询。如果只是临时看两眼AOCI 完全不划算。提示AOCI 的索引一定要做增量更新。代码改了但摘要没更新它给你的就是过时信息比没有还危险。我一般把索引更新和 CI 绑在一起合并到主分支就触发。3.3 多仓库场景下它才真正发光单仓库用 AOCI说实话有点重。但如果是多仓库、跨服务的场景AOCI 的价值就出来了。因为它可以在仓库级之上再加一层组织级索引让你能跨仓库查询。比如你问订单服务调用库存服务的哪个接口单仓库工具只能看到一个仓库AOCI 能跨过去。这种场景下它省的不只是 token还有你来回切换仓库的时间。3.4 什么时候别碰 AOCI仓库很小几千行以内建索引的成本永远收不回来。代码变动极频繁索引刚建好就过时了。你只是偶尔查一次直接读代码更快。AOCI 是长期投资型工具不是即用即走型工具。这个定位一定要清楚。4. Understand Anything用自然语言替换代码前两个工具都在结构化上做文章Understand Anything 走的是另一条路把代码翻译成自然语言。它的产物不是图也不是索引而是一段段这个函数在干嘛的说明。4.1 它的省 token 逻辑最直接逻辑简单粗暴代码原文 token 多自然语言说明 token 少。一个 200 行的函数原文可能 3000 token一段准确的说明可能只要 150 token。压缩比可以到 20 倍以上。代价是信息损失。自然语言说明会丢掉实现细节——边界条件、异常处理、具体的算法选择。所以 Understand Anything 适合了解大意不适合精确修改。我一般这么用先用它快速摸清一个陌生模块的整体逻辑定位到具体要改的函数后再回去读原文。它是侦察兵不是施工队。4.2 生成质量高度依赖模型这一点必须强调。Understand Anything 的产出质量几乎完全取决于你用什么模型来生成说明。用弱模型生成的说明经常是这个函数处理数据这种废话毫无信息量。我的经验是生成说明这一步值得用你能拿到的最好的模型。因为说明会被反复复用一次生成好后面省的是无数次查询。反过来如果为了省钱用弱模型生成得到的是一堆垃圾说明还不如没有。4.3 安装和上手确实最省心从热词里能看到不少人在搜understand anything 安装说明它的上手门槛是三个里最低的。基本流程就是指向仓库目录跑一遍等它生成说明。不需要配图数据库不需要起索引服务。但上手简单不等于用得好简单。我见过有人跑完一遍就以为完事了结果代码一改说明全过时。说明的更新机制才是真正要花心思的地方。4.4 它最适合的两类人刚接手陌生代码库的人快速建立整体认知比一行行读快得多。做代码审查的人先看说明判断改动意图再决定要不要细读。如果你已经很熟自己的代码Understand Anything 对你的边际价值很低——你脑子里的说明比它生成的还准。5. 三者横向对比一张表说清怎么选前面分开讲了这里做个集中对比。我把实际使用中最影响决策的几个维度列出来。对比项CodeGraphAOCIUnderstand Anything首次投入建图分钟级建索引小时级 token 成本生成说明分钟到小时级增量维护简单挂钩子即可复杂需 CI 配合中等需检测改动查询省 token高子图检索极高多数查询不下钻极高语义压缩信息保真度高保留原文中高分层低有损压缩跨仓库支持弱强弱适合仓库规模中大型大型 / 多仓库中小型学习曲线中陡平缓5.1 按场景给具体建议场景一你刚加入一个项目想快速上手。选 Understand Anything。先跑一遍生成说明花半天时间把整体逻辑过一遍。这一步的投入产出比最高。场景二你要做一个影响面很大的重构。选 CodeGraph。先把图建起来用子图检索确认所有受影响的调用点。这一步能帮你避免改了一个地方崩了三个服务。场景三你们团队有十几个仓库需要长期维护。选 AOCI。前期投入大但一旦索引建好团队所有人的查询都受益。这是团队级的基础设施。场景四预算紧张只想省点 token。Understand Anything 起步因为它前期成本最低。等用出感觉了再考虑上 CodeGraph。5.2 一个反直觉的结论三个工具不是互斥的。我现在的实际配置是Understand Anything 做第一层快速认知CodeGraph 做精确的关系查询AOCI 暂时没上因为我的仓库还没大到那个程度。它们解决的是不同粒度的问题。Understand Anything 回答这是什么CodeGraph 回答它连着谁AOCI 回答它在整个系统里的位置。硬要三选一反而限制了自己。6. 实操中的 token 账怎么算既然主题是省 token那就得会算账。不然你根本不知道自己省了没有。6.1 一个可复用的估算方法粗略估算1 行代码大约对应 10 到 15 个 token取决于语言和缩进。一个 500 行的文件大约 5000 到 7500 token。有了这个基数你就能估算全量贴文件直接按行数算。CodeGraph 子图按检索出的函数行数算通常是被影响函数的 1 到 2 倍。Understand Anything 说明按说明字数算通常是原文的 5% 到 10%。AOCI多数查询在模块级解决token 消耗可以忽略。6.2 别忽略隐性 token很多人只算贴进去的代码忽略了来回对话的 token。你贴了一大段代码AI 没答到点上你再追问再贴这个来回的成本往往比第一次贴的还高。所以真正的省 token 逻辑是一次给对比给得多更重要。这也是为什么结构化检索CodeGraph和语义压缩Understand Anything有效——它们提高的是一次命中率。6.3 我自己的配置习惯单文件任务直接读不上工具。跨文件任务先 Understand Anything 摸清结构再 CodeGraph 定位关系。长期项目把索引和图的更新挂到提交钩子上保证数据新鲜。这套组合下来我估算 token 消耗比无脑全量贴降低了大概 60% 到 70%而且回答质量更稳定。7. 几个高频问题的直接回答热词里有一堆关于 token 的搜索我挑几个和这三个工具相关的直接答。codegraph 怎么用核心就三步——建图、检索、更新。建图一次检索日常用更新挂钩子。别把它当成需要天天操作的东西。understand anything 安装它的安装确实是三个里最简单的基本是指向目录就能跑。但装完只是开始说明的更新策略才是要花心思的地方。token 用量这三个工具省的都是查询时的 token。但 AOCI 和 Understand Anything 有生成时的 token 成本这部分要提前算进去别只看查询省了多少。免费 token这个和工具选型关系不大但提醒一句——省 token 的工具本身就是在帮你把免费额度用得更久。同样的额度用结构化检索能撑的查询次数明显更多。7.1 关于 token 失效类报错的说明热词里大量出现各种 token 相关的报错比如刷新失败、交换失败、权限被拒之类。这些绝大多数和本文讨论的代码上下文 token不是一回事——那些是身份认证层面的 token属于账号和网络配置问题。我这里只提醒一点别把两类 token 搞混。本文讲的 token 是模型上下文长度单位认证 token 是身份凭证。搜索资料的时候注意区分否则会看到一堆不相干的内容。7.2 选型时最容易被忽略的一点大家都在比谁省得多但真正该比的是**谁省得对**。省 token 的终极目的是让 AI 答得准。一个工具如果省了 90% 的 token但把关键信息也省掉了那它就是在帮倒忙。我的判断标准始终是在保证回答质量的前提下谁的 token 消耗低谁就赢。脱离质量谈省 token没有意义。8. 我最后想说的几句实在话这三个工具我都实际跑过也都在真实项目里用过一段时间。最大的体会是工具本身不复杂复杂的是什么时候用哪个的判断。而这个判断没有任何一篇文章能替你做只能靠你在自己的仓库上试。我的建议是先拿一个你熟悉的中等仓库三个工具都跑一遍对比一下它们给你的结果和你脑子里的认知差多少。差得越少说明这个工具越适合你的代码风格。这个过程花不了多少时间但能帮你建立最直接的判断依据。另外别指望一次选型就一劳永逸。仓库在长大你的需求也在变。今天适合 Understand Anything 的仓库明年可能就得上 AOCI 了。保持开放定期重新评估比死守一个工具强。至于 token 账单它只是一个信号。账单涨了说明你的上下文管理出了问题该回头看看是不是又在无脑全量贴了。工具是帮你养成好习惯的不是替你偷懒的。