代码库压缩省token实测：CodeGraph、AOCI与Understand Anything对比

1. 三个工具到底在解决什么问题先把话说在前头CodeGraph、AOCI、Understand Anything 这三个名字放在一起本质上都在干同一件事——把代码库压缩成结构化的上下文再喂给大模型从而把 token 用量打下来。区别只在于压缩的粒度、自动化的程度以及你愿意为它付出多少配置成本。我自己维护着一个中等规模的代码仓库前后端加起来大概 12 万行日常用 AI 辅助做代码审查、写单测、排查线上问题。最开始我是直接把整个文件甚至整个目录丢进对话窗口结果就是两三次交互之后上下文就爆了要么被截断要么账单肉眼可见地往上走。后来我开始系统性地试各种省 token方案这三个工具是我实际跑过至少两周以上的不是看两眼文档就下结论。先说清楚它们各自是什么定位避免你选错方向CodeGraph走的是代码图谱路线。它会把仓库解析成符号级别的图结构——函数、类、变量、调用关系、引用关系然后你提问的时候只把相关的子图捞出来塞进上下文。它的核心卖点是精准检索不是无脑压缩。AOCI更偏向上下文编排。它不太关心代码本身的语义结构而是关注这次任务需要哪些文件、哪些片段通过一套规则和索引机制把上下文拼装出来。你可以理解成它是给 AI 做备菜的。Understand Anything名字起得最直白它的思路是先让模型理解整个项目再基于理解结果做问答。它通常会先跑一遍全量分析生成一份项目级的摘要和索引后续提问都基于这份索引而不是每次重新读代码。这三个东西的差异决定了它们适合的场景完全不同。下面我逐个拆。1.1 为什么 token 会成为瓶颈很多人对 token 的消耗没有直观概念。我拿自己的仓库举个例子一个 300 行的 TypeScript 文件大概对应 3500 到 4500 个 token取决于注释密度和命名长度。如果你一次丢 20 个文件进去那就是 8 万 token 起步。现在主流模型的上下文窗口虽然标称 128K 甚至 200K但实际使用中上下文越长模型对中间部分的注意力越弱这就是所谓的lost in the middle现象。更现实的问题是成本。按输入 token 计费的话一次 8 万 token 的请求如果你一天跑 50 次一个月下来就是一笔不小的开销。而且很多时候你丢进去的 20 个文件里真正相关的可能只有 3 个。所以省 token 的本质不是抠门而是在保证回答质量的前提下减少无效上下文。这三个工具都是在做这件事只是路径不同。1.2 三者的核心差异一句话总结维度CodeGraphAOCIUnderstand Anything核心机制符号级代码图谱检索上下文规则编排全量预分析索引首次配置成本中高中低增量更新支持依赖规则需重新分析适合仓库规模中大型任意中小型省 token 幅度高60%-85%中40%-60%中高50%-70%学习曲线陡平缓平缓这张表是我实测下来的主观感受具体数字后面会展开说。2. CodeGraph图谱检索的威力与代价CodeGraph 是我用得最久的一个也是三个里面对代码理解这件事做得最深的。它的工作流程大致是先对仓库做一次全量解析建立符号索引和调用图然后在你提问时通过语义匹配找到相关符号再沿着调用图扩展一到两跳最后把这一小簇代码拼成上下文。2.1 它是怎么把 token 降下来的关键在于它不读文件它读符号。传统做法是这个问题可能和 user 模块有关把 user 目录下的文件都读进来CodeGraph 的做法是这个问题涉及validateToken这个函数它调用了decodeJWT和checkExpiry把这三个函数的定义和直接引用它们的代码捞出来。我实测过一个场景排查一个登录态失效的问题。传统方式我把 auth 目录下 8 个文件全丢进去大概 3.2 万 token。用 CodeGraph 之后它只捞出了 4 个函数和 2 个类型定义加起来 4200 token 左右。省了将近 87%而且因为上下文更聚焦模型的回答反而更准没有在无关代码上瞎猜。这个降幅不是每次都这么夸张。简单问题可能只省 40%复杂问题因为要扩展更多跳可能只省 50%。但整体下来60% 到 85% 是一个合理的预期区间。2.2 配置过程与踩坑记录CodeGraph 的配置是三个里最麻烦的。你需要安装它的 CLI 工具和对应的语言解析器TypeScript、Python、Go 等各装各的在项目根目录初始化配置文件指定要索引的目录和要排除的目录跑一次全量索引生成图谱数据配置你的 AI 客户端让它通过 CodeGraph 的接口来获取上下文第三步是最容易出问题的。我第一次跑索引的时候把node_modules和dist也扫进去了结果索引跑了 40 分钟还没结束内存直接飙到 8G。后来在配置里加了排除规则才正常。注意索引目录的排除规则一定要写全尤其是构建产物、依赖目录、测试快照这类东西。我见过有人把.next缓存目录也扫进去索引文件直接涨到 2G。还有一个坑是增量更新。CodeGraph 支持增量索引但它的增量是基于文件修改时间的。如果你用 git 切换分支文件时间戳会变它可能会触发大量重索引。我的做法是在切换分支后手动跑一次全量索引虽然慢一点但比它自己判断要可靠。2.3 什么时候该用它CodeGraph 最适合的场景是仓库规模大、代码结构清晰、你需要频繁做跨文件的代码理解。比如你要搞清楚一个请求从入口到数据库经过了哪些层或者要评估改一个函数会影响哪些调用方这种关系型的问题CodeGraph 的优势非常明显。反过来说如果你的仓库很小比如就几千行或者你的问题大多是这个文件里这段逻辑是干嘛的这种局部问题那 CodeGraph 的配置成本就不划算了直接用文件读取反而更快。3. AOCI把上下文编排做成流水线AOCI 的思路和 CodeGraph 完全不同。它不建图谱它建的是规则。你告诉它当我说到 API 相关的问题时把src/api目录下的文件、types/api.ts类型定义、以及docs/api.md文档一起带上它就按这个规则去拼上下文。3.1 规则驱动的上下文组装AOCI 的核心概念叫上下文包context bundle。你可以定义多个包每个包对应一类任务。比如api-bundleAPI 相关文件 类型定义 接口文档db-bundle数据模型 迁移脚本 查询封装ui-bundle组件 样式 状态管理提问的时候你指定用哪个包或者让它根据关键词自动匹配。这样每次带进去的上下文都是预先筛选过的不会把整个仓库都塞进去。我实测下来AOCI 的省 token 幅度在40% 到 60%之间。它不如 CodeGraph 精准因为规则是粗粒度的一个包里的文件可能只有一半是真正相关的。但它的好处是可控——你完全知道每次会带进去什么不会出现图谱检索漏了关键文件的情况。3.2 规则怎么写才不浪费 token写 AOCI 规则最大的误区是包越大越保险。我一开始就是这么想的把整个src目录都塞进一个包结果每次请求还是 5 万 token 起步等于没省。后来我调整了策略按任务类型拆细而不是按目录拆。比如同样是 API 相关我拆成了三个包api-read只包含查询接口的定义和实现api-write只包含写操作相关的api-auth只包含鉴权中间件和权限校验这样每次提问时根据具体是读还是写还是权限问题选对应的包上下文能再降一半。提示AOCI 的规则文件建议纳入版本管理团队里谁改了规则都能看到。我见过因为规则文件没同步两个人用同一套工具但上下文完全不一样排查问题排查了半天。3.3 它的局限在哪AOCI 最大的问题是它不理解代码。它只是按你写的规则搬文件。如果规则写得不合理或者代码结构和规则假设的不一致它就会带错上下文。比如你把某个工具函数从utils移到了helpers但规则里还写着utils那这个函数就永远不会被带进去。所以 AOCI 适合的是代码结构稳定、团队有明确约定的项目。如果你的项目还在快速迭代、目录结构三天两头变维护规则的成本会很高。4. Understand Anything先理解再回答Understand Anything 的定位最傻瓜化。它的流程是先对整个项目跑一次分析生成一份结构化的项目摘要包括模块划分、核心流程、关键数据结构然后你所有的提问都基于这份摘要来回答。4.1 预分析阶段做了什么它的预分析会做几件事扫描所有源文件提取顶层结构模块、类、函数签名识别入口文件和核心流程生成一份人类可读的项目概览文档建立文件到摘要的映射索引这份摘要通常只有几千 token但覆盖了项目的骨架。后续提问时它先在这份摘要里定位相关部分再决定要不要去读具体文件。我实测的省 token 幅度在50% 到 70%。它的优势是首次配置几乎为零——装好之后指一下项目目录等它分析完就能用。对于不想折腾配置的人来说这是最友好的。4.2 分析质量决定一切但 Understand Anything 的效果高度依赖预分析的质量。如果项目结构混乱、命名不规范它生成的摘要就会很泛后续定位就不准。我拿两个项目对比过一个是结构清晰的 NestJS 项目分析出来的摘要非常准确后续问答基本不用再读原文件另一个是历史遗留的 Express 项目路由和业务逻辑混在一起分析出来的摘要基本是这个文件做了一些事情这种废话后续还是得靠读原文件。注意Understand Anything 的分析结果建议人工过一遍。它有时候会把测试文件当成核心逻辑或者漏掉一些动态加载的模块。花十分钟检查一下摘要能省后面很多麻烦。4.3 增量更新的痛点它最大的短板是增量更新。代码改了之后你需要重新跑分析才能让摘要保持准确。对于小项目这没什么跑一次几分钟。但对于大项目全量分析可能要十几分钟甚至更久频繁改代码的话就很烦。我的做法是按需重跑日常小改动不重跑等积累到一定量或者要做重要分析时再跑一次全量。这样平衡了准确性和时间成本。5. 实测对比同一批任务下的表现光说机制不够我拿三个真实任务跑了一遍记录 token 消耗和回答质量。5.1 任务设置三个任务分别是任务 A定位一个 bug——用户修改密码后旧 token 仍然有效任务 B为一个工具函数写单元测试任务 C评估把某个同步操作改成异步的影响范围每个任务分别用三个工具跑记录输入 token 数和回答是否直接可用。5.2 数据对比任务工具输入 token回答质量备注A裸读文件28400一般有猜测成分漏了中间件里的校验逻辑ACodeGraph3900准确直接定位沿调用图找到了中间件AAOCI11200较准规则包里包含了中间件AUnderstand Anything6800较准摘要里提到了鉴权流程B裸读文件15600可用带了无关的相邻文件BCodeGraph5200可用只带了函数定义和类型BAOCI7400可用规则包匹配到了测试目录BUnderstand Anything4900可用摘要定位到了函数C裸读文件42000差上下文被截断文件太多超出窗口CCodeGraph8100好列出了调用链图谱扩展了两跳CAOCI18600一般规则包太大带了无关文件CUnderstand Anything12400较好摘要覆盖了主要调用方从数据看CodeGraph 在复杂任务上的优势最明显任务 C 里它比裸读省了 80% 以上而且回答质量最好。AOCI 表现中规中矩规则写得好就省得多写得粗就省得少。Understand Anything 在简单任务上表现不错复杂任务上因为摘要粒度不够细略逊于 CodeGraph。5.3 回答质量的细节差异token 省了不代表回答就好。我特别关注了几个细节任务 A 里裸读文件的方式虽然带了 8 个文件但模型还是漏了中间件里的 token 校验逻辑因为它被淹没在大量无关代码里了。CodeGraph 因为精准定位到了调用链直接指出了问题所在。这说明上下文的质量比数量重要得多。任务 C 里AOCI 因为规则包定义得太宽带了一堆无关的 service 文件模型虽然没被截断但在回答里花了不少篇幅讨论那些无关文件实际有用的分析反而少了。6. 选型建议与组合用法说了这么多到底怎么选我的建议是不要只选一个而是根据场景组合使用。6.1 按场景选日常小改动、单文件问题直接用编辑器自带的 AI 补全或者裸读文件就够了上工具反而慢。跨文件排查、影响面评估CodeGraph 是首选它的图谱检索在这个场景下无可替代。团队协作、需要统一上下文规范AOCI 更合适规则文件可以共享大家用同一套上下文。快速上手、不想折腾Understand Anything 最省心装完就能用。大型仓库、长期维护CodeGraph AOCI 组合CodeGraph 负责精准检索AOCI 负责兜底和补充。6.2 我的实际组合我现在的主力配置是CodeGraph 做主力检索 Understand Anything 做项目概览。具体流程是新接触一个模块时先看 Understand Anything 生成的摘要快速建立整体认知具体排查问题时用 CodeGraph 精准捞取相关符号如果 CodeGraph 漏了什么偶尔会发生再用 AOCI 的规则包补一下这套组合下来我的平均 token 消耗比最开始裸读文件降了75% 左右而且回答质量明显提升。6.3 一个容易被忽略的点不管你用哪个工具代码本身的可读性直接影响省 token 的效果。命名清晰、职责单一、注释到位的代码任何工具都能更好地理解和压缩。反过来一个 2000 行的巨型文件里面全是data1、temp、handleThing这种命名再好的工具也救不了。所以省 token 这件事工具只是一半另一半是你自己的代码质量。我花在重构上的时间最后都从 token 账单和排查效率上赚回来了。7. 常见问题与排查技巧最后整理几个我实际遇到过的坑都是文档里不会写的。7.1 索引/分析跑不动怎么办最常见的原因是扫描范围太大。检查你的排除规则把node_modules、dist、build、.git、测试快照、日志目录全部排除。如果还是慢试试分模块索引先索引核心模块跑通了再扩展。7.2 检索结果不准怎么办CodeGraph 检索不准通常是符号命名太泛导致的。比如你有五个叫handle的函数它很难判断你要哪个。解决办法是在提问时带上更多限定词比如用户模块里的 handle 函数。Understand Anything 摘要不准通常是项目结构问题。可以考虑手动维护一份项目结构说明让它参考。7.3 token 没降反升是什么情况如果你发现用了工具之后 token 反而更多了大概率是工具把索引本身也塞进上下文了。检查一下配置确保它只传检索结果不传索引元数据。我遇到过 AOCI 把规则文件内容也带进去的情况白白多了几千 token。7.4 团队协作时的注意事项如果团队多人使用规则文件和索引配置一定要纳入版本管理。否则每个人本地配置不一样讨论问题时上下文都对不齐沟通成本反而更高。我们团队的做法是把配置文件放在仓库根目录新人入职第一件事就是拉下来跑一遍初始化。这三个工具没有绝对的优劣关键是匹配你的仓库规模、团队习惯和任务类型。我踩过的坑基本都写在这了剩下的就靠你自己上手试了。