企业官网建设流程全解析

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 三者的核心差异一句话总结

这张表是我实测下来的主观感受，具体数字后面会展开说。

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 的配置是三个里最麻烦的。你需要：

1. 安装它的 CLI 工具和对应的语言解析器（TypeScript、Python、Go 等各装各的）
2. 在项目根目录初始化配置文件，指定要索引的目录和要排除的目录
3. 跑一次全量索引，生成图谱数据
4. 配置你的 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-bundle：API 相关文件 + 类型定义 + 接口文档
• 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 预分析阶段做了什么

它的预分析会做几件事：

1. 扫描所有源文件，提取顶层结构（模块、类、函数签名）
2. 识别入口文件和核心流程
3. 生成一份人类可读的项目概览文档
4. 建立文件到摘要的映射索引

这份摘要通常只有几千 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 数据对比

从数据看，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 做项目概览。具体流程是：

1. 新接触一个模块时，先看 Understand Anything 生成的摘要，快速建立整体认知
2. 具体排查问题时，用 CodeGraph 精准捞取相关符号
3. 如果 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 团队协作时的注意事项

如果团队多人使用，规则文件和索引配置一定要纳入版本管理。否则每个人本地配置不一样，讨论问题时上下文都对不齐，沟通成本反而更高。我们团队的做法是把配置文件放在仓库根目录，新人入职第一件事就是拉下来跑一遍初始化。

这三个工具没有绝对的优劣，关键是匹配你的仓库规模、团队习惯和任务类型。我踩过的坑基本都写在这了，剩下的就靠你自己上手试了。