git commit 或 git checkout 都会触发一次增量更新，AI 助手看到的图谱永远对应当前分支的状态。
关于 71.5× 这个数字

README 里写的是：在混合语料库上，相比直接读原始文件，Graphify 把 token 用量降低了 71.5 倍。这个数字来自项目自己的 worked/ 目录是在精挑过的数据集上跑出来的。
只从架构上讲这个倍数是合理的。一个一万个函数的代码库，问"什么调用了 process_payment？"，图谱遍历返回的是几个节点 ID；读原始文件回答同一个问题，得把所有可能包含答案的文件都加载进来。具体倍数完全取决于语料库规模和查询的精确度——稀疏的、结构性的查询收益最大，宽泛的概念性查询收益要小得多。
但是如果在公共测试集上把 Graphify 的图谱查询和原始文件、RAG 这两个基线放在一起做的独立基准。这种基准出现之前，71.5× 可能就是一个参考了，，因为实际倍数会随语料库规模、文件类型组合和查询模式而变。
Graphify 适合什么场景

适合：同一个仓库里既有代码、又有架构文档、设计 PDF 和录制会议这种混合媒体项目；在稳定的代码库上反复查询的场景，因为缓存收益会随时间累积；用 Claude Code 做编码助手、想压低单次会话 API 成本的团队；调用图复杂、语义搜索吃力的项目，比如深层继承链或大量基于回调的架构。
不太适合的也很清楚：文件不到 20 个的新项目，图谱本身的开销不划算；内容几乎全是散文文档的仓库，对开放式语义问题，扁平 RAG 大概率跑得过图谱遍历；AI 提供商的数据政策禁止把文档内容发给其 API 的环境——文档和图像走的就是 Pass 3，绕不开；以及需要可验证、可复现分析的项目，INFERRED 和 AMBIGUOUS 边如果照单全收，会把人带偏。
几个值得注意的局限

Graphify 是个人开源项目，目前版本 v0.4.10，没有机构背书。开发是活跃的，但是目前看长期维护怎么样不好说。如果要把它放进生产工具链，得保留一点谨慎。
包名也有点小问题：工具叫 graphify，PyPI 上的包却是 graphifyy（双 y）。README 说这是临时状态。安装前请先确认当前的规范包名——热门开发工具被抢注名字这种事不少见。
接下来值得关注的方向

MCP server 集成这块值得盯着。随着 MCP 在各类 AI 编码助手里逐步铺开，Graphify 把代码库图谱作为一组 LLM 可调用工具暴露出来的能力，会变成自主 agent 的一块基础设施——那些 agent 真正需要的，是对代码库的结构化理解，而不只是文件搜索。