Graphify 深度评测:12.5 万 Star 的代码知识图谱,官方 71.5 倍省 token 我复算只有 38.3 倍,6957 条测试我跑两遍

Graphify 深度评测:12.5 万 Star 的代码知识图谱,官方 71.5 倍省 token 我复算只有 38.3 倍,6957 条测试我跑两遍

你能省多少 token,不是看你把文件读了多少遍,而是看你拿什么当「一共要读多少」的分母。

这句话是我评测 Graphify 的全部理由。它 12.5 万 Star,一度在主页上写着能把一个项目的 token 消耗压掉 71.5 倍;我在隔离沙箱里把它装在真仓库上跑,发现这个「压掉多少」的分母,是拿代码里的节点个数乘以 50 估出来的。

它到底是什么

一句话:把一整个代码库(外加文档、PDF、图片)读成一张知识图谱——也就是一张「谁调用谁、谁属于谁、谁解释了谁」的关系网,之后你问问题,它沿着这张网走,不再把源文件整个塞给模型。

它的做法叫 tree-sitter 解析,说人话就是:不靠大模型去猜代码写了什么,而是像编译器那样把源码拆成结构。所以代码部分完全在本地跑,一个 token 都不花,出门都不用联网。这是我实测过最扎实的部分,后面会讲。

它还留了一手很有意思的设计:每条关系都标着来源——EXTRACTED 表示「源码里明写着」,INFERRED 表示「是它自己推出来的」。你一眼能分清哪些是读到的事实、哪些是它的猜测。敢把这两类分开标的项目不多。

它自己宣传的卖点,最抓眼球的是这一条:

它主页上怎么写 我这次要做的事
查询一次的开销,比直接读原始文件省 71.5 倍 用它自带的算分命令,在同一份图上重算一遍

我先把 71.5 倍这句,从文档里追到代码里

先说我怎么找到这个数字的出处——它不在任何一句宣传语里,而在仓库里一个叫「跑过的例子」(worked)的目录。

那个目录里 commit 了一份完整的推算记录:语料是三个 Karpathy 的仓库加五篇论文加四张图,一共 52 个文件、92,616 个词,折算成约 123,488 个 token;查询一次的平均开销记的是 1,726 个 token。两者一除,71.5。

我照着它自己的算分代码,在这份仓库里自带的图上重算:

我怎么算 结果
语料规模(它自己记的数字) 92,616 词 → 123,488 token
它记录的平均查询开销 ~1,726 token → 71.5 倍
我用它的代码重算的平均开销 ~3,225 token → 38.3 倍

差在哪儿?我又做了一步它文档里没写的检查:把它那五道示例问题,逐条喂给这张图。

五道题里有四道,一个节点都没匹配上。

它现在的算分命令只统计「有命中的题目」,取这些题的平均值当分母。命中的题目越少、命中范围越小,平均值越低,「省了多少倍」这个数字就越大。所以 71.5 不是造出来的,但它是一个挑题目挑出来的最好看的口径——用同一张图、同一份代码重跑,它的读数是 38.3。

更值得看的是:这个数它是怎么在文档里消失的

我把英文版文档和 31 个语言的翻译版逐个拉下来比对。

英文版的这一整段,已经被删干净了。我搜「71.5」,英文主页里 0 次命中;搜「token reduction」「fewer tokens」,也是 0 次。新英文文档里只留下另一组数字:LOCOMO 记忆基准的 recall@10 是 0.497、QA 准确率 45.3%、LongMemEval-S 76%、ERPNext 跨工具覆盖率 82.0%——这些是拿公开学术数据集测的,而且写明了「裁判用第二个独立裁判盲验过,一致率 90.6%」。这一套口径比 71.5 严得多。

但 31 个翻译版里,28 个还在写 71.5 倍,包括中文版:首页引语里写着「相比直接读取原始文件,每次查询的 token 消耗可降低 71.5 倍」,正文里还有一整段在讲它。

我不打算把它写成「明知故犯」,因为证据不支持这个说法——英文版主动撤下这个数字,是清理动作做在了英文上、没做全。但结果是:一个只看中文版文档的读者,读到的数字和被撤下的那个是同一个。顺手核了一句:它的 Python 包说明页(PyPI)里,71.5 出现 0 次——包页面是干净的。

那个「省了多少倍」,分母是估出来的

这是我自己最在意的一处,因为它不需要任何前提就能复现。

它自带一条算分命令,命令行跑一下就会打印「省了 X 倍」。它要算「原始语料一共多少 token」,靠读一个记录语料规模的文件。文件不在,它就用「图里的节点数 × 50 个词」顶上。

我在两个真仓库上各跑了两遍——一遍按它默认的走,一遍把真实语料规模填进去:

我在哪测 真实语料 它默认报的 换成真实语料后
httpx(Python 部分 5.0 万词) 50,422 词 报 9.5 倍 5.4 倍
fastapi(Python 部分 28.1 万词) 281,060 词 报 8.5 倍 1.8 倍

它默认报的那两个数,分母分别是 89,000 词和 1,339,100 词——都是「节点数 × 50」估出来的,跟真实语料差着一倍到四倍。

而更要紧的是:它自己的官方用法,本来就永远走这条兜底路径。它的安装脚本把语料记录写在输出目录里面,而算分命令只在仓库根目录找同名文件。两个路径对不上——也就是说,谁按它官方文档装、按官方流程跑,看到的那个「省了多少倍」都是估算分母算出来的。

也有真东西:这一套离线跑得又快又稳

公平地说,把代码读成关系网这件事,它做得比我预期好,而且好得能自己站住。

全程断网(沙箱直接切断网络)跑下来:

我跑的 结果
httpx 60 个文件建图 17 秒 → 1,780 个节点、3,804 条关系
fastapi 1,177 个文件建图 74 秒 → 9,268 个节点、20,139 条关系
同一个仓库再跑一次 9 秒(72 个文件全部命中缓存)
生成的关系网报告里,排前面的「核心抽象」 Response、Request、BaseClient、Client——确实是这个库的主干

断网、无密钥、纯本地,几十秒出一张能查的图。这个能力本身是成立的。

它自己的报告里还有一处我特别想指出来:仓库里 commit 的另一份自评(对一个真实项目跑的)自己承认了一类系统性偏差——测试代码里的工厂函数会挤满「核心节点」榜单,因为每个测试都要构造这些对象,它们的关系数自然最高。它还给了规避办法(用忽略清单把测试目录排掉)。一个项目肯把自己输出的这个毛病写进仓库,我认为是加分的。

它的测试规模很大,我跑了两遍

它的测试量是真的舍得投:6,957 个用例,测试代码 11.8 万行,比它 8 万行的源码还多——源码 94 个文件,测试 361 个文件。

我在同一个沙箱、同一个虚拟环境里跑完整套:

结果
第一遍 50 个失败、6,587 个通过、328 个跳过(约 9 分钟)
第二遍(同一份代码,什么都不改) 50 个失败、6,587 个通过、328 个跳过

两遍完全一致,这次没有飘——这点比很多项目干净。

那 50 个失败我逐个查了来源,其中 49 个是我这边环境的问题,不是它的:

失败数 原因 归属
30 没装它那个可选的 Terraform 语法包 我缺依赖(装上后这 41 条全过)
11 安装脚本要读完整 git 历史,我拉的是浅克隆 我缺历史
7 断网导致域名解析失败 我给断的网
1 缺打包工具 我缺 dev 依赖

但有一条是它自己的问题。我把 PyYAML(一个解析文档头部的库)卸掉之后,它有一条用例稳定失败:

一个文档的开头写成嵌套结构时,那个嵌套块会被整个丢掉。它自己的用例注释里写着「嵌套块不许被抹平」——注释说的正是它做不到的那件事。

根子在它的处理逻辑里:优先用 PyYAML,装不上就退回一个只认「平铺的键值对」的降级解析器,嵌套结构在降级路径上被跳过,而且不报错。而 PyYAML 不在它的核心依赖里——只装主包的用户,默认走的就是这条降级路。它自己的贡献指南让开发者用「装全部可选依赖」的方式建环境,所以这条线在它的持续集成里是绿的;一个只跑一条安装命令的用户,拿到的是另一套行为。

它的文档里,我照着敲的第一条命令就没跑通

主页上给了一段真实输出演示,是最吸引人的那种:在一个 9,000 多个节点的图上,问两个概念怎么连起来。我照着敲:

主页上写的 我实际拿到的
打印一条 3 跳的路径 Ambiguous:FastAPI 在两个文件里都叫这个名字,拒绝回答
「核心节点」里 APIRouter 有 47 条关系 实测 158 条

第一条其实不是 bug——它新版本改成「名字有歧义就不猜」,这是更安全的行为,只是主页没跟着更新。第二条我核过,就是文档没同步。

谁该用它,谁先别急

值得用:你有一个几万行、几十万行的代码库,想让 AI 助手先看懂骨架再干活,又不想把源码传到云上——它的本地建图是真能省时间的,几十秒一张图,之后随便查。

先别急:你要拿「省了多少倍」去说服团队或老板。这个数字目前的口径是它自己算的、分母可能来自估算、题目是挑出来的,同一个人用同一份图重算都能差出一倍。

同类的另有两条路:一条是它自己在主页推的「常驻更新版」平台(14 天试用),一条是站内评测过的 Understand-Anything(同样做代码知识图谱,走的是另一个角度)。

我的判断

装它,用来把代码库变成一张能查的图——值得。信它主页上那个「省多少倍」——先自己跑一遍那条算分命令。

我对这件事的判断是这样的:一个项目在 189 天里发了 227 个版本、写了 11.8 万行测试、还主动把「英文版已经删掉的数字」从英文说明里清掉——它在认真做工程,不是在刷榜。但「省 token」这种能用数字说清的卖点,一旦分母是估出来的、题目是挑出来的,它就从结论退化成了宣传。

下次看到任何工具说「省了 X 倍」,先问一句:分母是什么。问完你会发现,一半的数字会当场缩水。

本文所有数字来自 2026-10-10 在隔离沙箱内的实测:被测项目克隆到沙箱自己的工作目录,宿主主目录被临时文件系统覆盖,全程断网运行,未接触任何生产环境凭证。被测版本 0.9.84,对应提交 `2cb81c6`。

关注 AI商业快讯,每天一篇 AI 热点深度解读。

相关阅读:

Understand-Anything 实测:80k Star 的代码知识图谱,让 AI 从「读代码」变成「教代码」

Understand-Anything 实测:80k Star 的代码知识图谱,让 AI 从「读代码」变成「教代码」

20 万行代码的新团队,没有架构文档,最懂系统的工程师刚离职——这是每个开发者都怕遇到的场景。传统方式是逐文件翻代码,平均需要 2-3 周才能建立基本的系统认知。Understand-Anything 用一个多 Agent 流水线扫描整个项目,生成可交互的知识图谱,把「读代码」变成「看地图」。80,770 Star、6,790 Fork、MIT 开源——它可能是目前最火的代码理解工具。

工作原理

Tree-sitter + LLM 混合架构

Understand-Anything 的核心是「确定性结构 + 语义理解」的双层架构:

第一层:Tree-sitter(确定性)

  • 解析源码为具体语法树(CST)
  • 提取结构事实:imports、exports、函数/类定义、调用关系、继承链
  • 预构建 importMap,避免重复推导
  • 基于指纹的变更检测,支持增量更新

第二层:LLM(语义)

  • 读取解析后的结构 + 原始源码
  • 生成纯英文摘要、标签、架构层分类
  • 业务领域映射、导览生成、语言概念标注

这种分离保证了结构图的可复现性(同一代码 → 同一边),同时保留了意图理解(文件是「干什么的」而不仅是「导入了什么」)。

5+2 Agent 流水线

/understand 命令编排 5 个专用 Agent,/understand-domain 加第 6 个,/understand-knowledge 加第 7 个:

Agent 职责 用途
project-scanner 发现文件、检测语言和框架 /understand
file-analyzer 提取函数、类、imports,生成图节点和边 /understand
architecture-analyzer 识别架构层(API/Service/Data/UI/Utility) /understand
tour-builder 生成按依赖排序的导览 /understand
graph-reviewer 验证图完整性和引用完整性 /understand
domain-analyzer 提取业务领域、流程、步骤 /understand-domain
article-analyzer 从 wiki 文章提取实体和隐式关系 /understand-knowledge

File analyzer 并行运行,最多 5 个并发 worker,每批 20-30 个文件。

功能拆解

核心模块

模块 一句话 核心能力 适用场景
结构图探索 代码库变可点击地图 每个文件/函数/类是节点,带纯英文摘要和关系 新人入职、代码审查
领域视图 代码映射业务流程 域/流程/步骤的水平图 向非技术人员解释系统
导览生成 自动创建学习路径 按依赖排序的架构 walkthrough 新人 onboarding
Diff 影响分析 提交前看影响范围 /understand-diff 显示变更波及的模块 PR review、变更管理
模糊/语义搜索 按含义找代码 「哪些部分处理认证?」→ 跨图搜索结果 日常开发、调试
Persona 自适应 UI 根据角色调整详情 初级/PM/高级用户看到不同深度 多角色团队协作
知识库分析 Wiki 变力导向图 从 Karpathy 模式 LLM wiki 提取实体和关系 团队知识管理
Figma 分析 设计稿变知识图谱 页面→屏幕→组件/变体/实例,设计 token 模型 设计-开发协作
增量更新 只分析变更文件 –auto-update post-commit hook 自动维护图 持续集成
多语言输出 6 种语言支持 en/zh/zh-TW/ja/ko/ru 国际化团队

平台兼容性

平台 状态 安装方式
Claude Code ✅ 原生 Plugin marketplace
Cursor ✅ 自动发现 Clone 即用
VS Code + Copilot ✅ 自动发现 Clone 即用
Codex ✅ 支持 install.sh codex
Gemini CLI ✅ 支持 install.sh gemini
OpenCode ✅ 支持 install.sh opencode
Copilot CLI ✅ 支持 copilot plugin install
Kiro ✅ 支持 install.sh kiro
共 15+ 平台 ✅ 一行脚本

这是它最大的差异化优势——不是绑定某个编辑器的私有功能,而是跨平台的共享产出物。

实测数据

增长数据

指标 数值
GitHub Stars 80,770
Forks 6,790
Contributors 48+(Lum1104 贡献 523 commits)
Open Issues 290
创建时间 2026-03-15
最新版本 v2.9.0(2026-07-10)
许可证 MIT
主要语言 TypeScript 71.3%, JavaScript 15.8%, Python 8.8%

5 个月从 0 到 80k Star,AI 工具类增长最快之一。

Token 成本

据 Augment Code 分析和官方文档:

  • 首次扫描:消耗大量 Token(200k 行代码可能花费数十美元)
  • 增量更新:仅分析变更文件,Token 消耗大幅降低
  • 推荐:大项目用 Token 订阅或本地模型(如 Ollama)

Before vs After 对比

维度 传统方式 Understand-Anything
新人建立系统认知 2-3 周翻代码 1 天跑完流水线 + 看导览
变更影响评估 手动 grep + 阅读 /understand-diff 一键查看
架构文档 不存在或已过期 自动生成 + 增量维护
跨团队共享 口口相传 提交 JSON,所有人共享

已知局限

  1. LLM 成本自担:多 Agent 流水线调用真实 LLM,费用不低
  2. 图质量依赖代码质量:命名混乱、无关注点分离的代码库,图也会混乱
  3. 首次扫描耗时:200k 行代码即使 5 并发也要跑一阵
  4. 可能过期:不启用 –auto-update,图会漂移
  5. 290 个 Open Issues:活跃开发中,部分功能可能不稳定

安装 + 适用场景 + 结语

安装

Claude Code(最简):

/plugin marketplace add Egonex-AI/Understand-Anything
/plugin install understand-anything

其他平台(一行脚本):

curl -fsSL https://raw.githubusercontent.com/Egonex-AI/Understand-Anything/main/install.sh | bash

最适合谁

  • ✅ 新入职工程师:1 天建立系统认知,不用翻代码
  • ✅ 技术经理/PM:领域视图解释业务逻辑
  • ✅ 开源维护者:贡献者快速理解项目结构
  • ✅ 多平台团队:不同编辑器,同一份共享图

不适合谁

  • ❌ 小项目(<1k 行):杀鸡用牛刀
  • ❌ 单人项目:没有共享需求
  • ❌ 预算敏感:首次扫描 Token 成本不低
  • ❌ 代码质量差的项目:图会反映混乱而非澄清混乱

对不同角色的意义

对个人开发者,它是理解陌生代码库的利器——接手遗留项目或研究开源项目时,5 分钟生成全景图。对团队,它是 onboarding 的基础设施——新人第一天就有交互式架构地图。对组织,它把「系统知识」从个人大脑里解放出来,变成可版本控制的团队资产。

相关阅读

本文数据来源:GitHub 仓库公开数据、Augment Code 报告、DEV.to 评测文章。截至 2026 年 8 月 28 日。