Graphify：把代码库变成可查询的知识图谱——从一条命令到背后设计

Graphify把代码库变成可查询的知识图谱从一条命令到背后设计AI Coding 工具有个尴尬的事实。它们把代码库当扁平文件系统。你每次提问它不是 grep就是逐文件从头读。10 万行代码的项目模型得翻几十个文件才能拼出答案。翻一次几千 tokens。翻十次context window 快满了。翻完发现漏了个关键关联再翻一轮。有个项目想解决这个问题。它叫 Graphify。YC S26 项目创始人 Safi Shamsi。2026 年 4 月上线。到 8 月已经 101,000 颗 star、9,800 个 fork。155 个 release。装好之后一条命令就能把整个项目变成一张知识图谱。AI 不再 grep 文件。改查图。从安装到第一张图30 秒uv tool install graphifyy graphify install然后在 AI 助手里输入/graphify .跑完graphify-out/下面多出三个文件文件用途graph.html交互式力导向图浏览器打开节点可点击、可筛选、可搜索GRAPH_REPORT.md文本摘要核心节点、意外关联、建议问题graph.json完整图谱数据后续查询全靠它不用重新读源码之后想查什么直接问图graphify query auth 和数据库之间怎么连接的 graphify path UserService DatabasePool graphify explain RateLimitergraphify path的交互最直观。问「FastAPI 和 ModelField 之间怎么走」。它一步一步点亮知识图谱上的跳转路径。3 跳走完。每跳标出是EXTRACTED源码里直接找到的还是INFERRED推理出来的。三遍扫描AST 白干LLM 只干语义活Graphify 的设计思路不浪费 LLM 调用。代码分析能用确定性算法解决绝不动模型。第一遍AST 提取本地零 LLMtree-sitter 解析大概 40 种语言。类、函数、import、继承、调用链全从语法树里抠出来。这一步完全不联网。代码不离开本机。0 token 消耗。第二遍语义提取LLM只对文档/图片/视频PDF、Word、Markdown、图片、视频/音频走这一步。视频用 faster-whisper 本地转录不调 API。只有文档和图片的语义理解要模型。用的是你 AI 助手当前会话的模型不用额外 API key。能单独装扩展能力uv tool install graphifyy[pdf] # PDF 提取 uv tool install graphifyy[video] # 视频/音频转录 uv tool install graphifyy[office] # .docx / .xlsx uv tool install graphifyy[sql] # SQL schema 提取第三遍图谱组装两遍提取的结果合入一张 NetworkX 图。Leiden 社区检测自动分簇。有意思的是分出的模块边界经常和目录结构对不上。等于给代码库找到一套「实际架构」。不是「目录架构」。PageRank 和 betweenness centrality 找出「上帝节点」。整个系统里连接度最高的概念一切数据流都经过它们。还有「意外关联」。不同模块之间八竿子打不着的两个东西图告诉你它们其实有桥。设计哲学不要向量库要真图Graphify 做了个和主流相反的选择不用向量数据库不用 embedding。现在大多数代码库 RAG 方案是 embed 所有文件。查的时候做语义相似度匹配。Graphify 觉得这条路对代码库不划算。代码里的关系是显式的import 语句、函数调用、类继承。这些不用拿余弦相似度来猜。把关系全部预计算存成图。查的时候直接遍历。比每次现场读源文件省 71.5 倍 token。每条边都带置信度标签EXTRACTED置信度 1.0源码里显式存在AST 掏出来的INFERRED0.4–0.9模型推理出来的关联AMBIGUOUS0.1–0.3不确定需要人看一眼这个设计让 AI agent 能区分「我找到了」和「我猜的」。用作者的话说「An honest graph — every claim about your code annotated with how we know it.」对比数据也很直观。在 LOCOMO 基准300 个代码理解问题上Graphify 的 recall10 是 0.497。mem0 只有 0.048。supermemory 0.149。差距 10 倍。LongMemEval-S 的问答准确率 76%。跟密集 RAG 打平。但 token 消耗只是它的零头。Skill 怎么组成的Graphify 不是黑盒。拆开看它是一组松耦合模块的管道detect() → extract() → build_graph() → cluster() → analyze() → report() → export()每一步都是纯函数。没有共享状态。一个环节挂了不影响其他。模块拆解模块做什么技术栈detect扫描目录识别文件类型合并 .gitignore .graphifyignorePython pathlibextract左轨AST 解析代码提取实体和关系tree-sitter~40 种语法extract右轨语义理解文档/图片/视频LLM 子 agent 并行faster-whisperbuild_graph合并两边结果去重建 NetworkX 图NetworkXclusterLeiden 社区检测给子系统贴标签igraph Leiden 算法analyzePageRank、betweenness centrality、意外关联排名NetworkXreport生成 GRAPH_REPORT.md graph.htmlJinja2 D3.jsexport输出 graph.json后续查询全用这个JSONAI 助手集成层Graphify 不是只生成一张图。它通过 hook让 AI 助手把「读文件之前先查图」变成默认行为Claude Code / Gemini CLIPreToolUse hook在 grep/Read 调用前拦截先跑graphify queryCodex / OpenCode / Cursor写入 AGENTS.md 或 .cursor/rules始终在线CodeBuddy / Kilo Code原生插件 hookMCP 服务器python -m graphify.serve graph.json暴露query_graph、shortest_path、get_neighbors等结构化工具任何支持 MCP 的客户端都能调用Hook 分两档。默认是软提示nudge。建议查图但不强制。strict 模式直接拦截第一次原始文件读取强制走图。之后恢复软提示。一个会话最多拦一次。越用越深PR 仪表盘、合并冲突预测、企业版基础功能之外Graphify 还有几个进阶用法PR 仪表盘。graphify prs列出所有 PR 的 CI 状态、审查进度、影响范围。graphify prs --triage用 AI 给审查队列排优先级。graphify prs --conflicts最实用。它找共享同一图谱社区的 PR标记合并冲突风险。两个 PR 改同一个模块的不同文件git 不报冲突。但逻辑上打架。图能看见。合并图谱。graphify merge-graphs a.json b.json把两个项目的图拼一起。对 monorepo或者跨仓库依赖分析有用。企业版。Graphify Labs 在开源版之上提供形式化验证prove-or-counterexample 检查代码变更、本地/私有云部署代码不出基础设施、审计日志tamper-evident、SSO/RBAC。给需要合规的团队。自动更新。graphify hook install装一个 git post-commit hook。每次提交自动增量重建图谱。只跑 AST不花 API 钱。团队里一个人跑/graphify .把graphify-out/提交进仓库。其他人 pull 下来直接用。从 grep 到查图Graphify 在解决一个很具体的问题AI 写代码时对代码库的理解成本。不是让它更聪明。是让它不用每次都从头读。技术上它用确定性算法tree-sitter AST包办代码分析的苦力活。把 LLM 留给它真正擅长的理解文档、图片、视频里的语义。经济上图谱建好之后每次查询省 71.5 倍 token。对大项目边际成本趋近于零。但它的设计选择更有意思。不用向量库用真图。每一条边标注置信度。模块间纯函数管道不共享状态。这些选择加起来做出一个「知道自己在对什么、在猜什么」的系统。AI 幻觉还没根治。能区分确定和猜测比全都拍胸脯靠谱。如果你的项目超过 1 万行代码多人协作文档分散在各个角落。值得花 30 秒装一个试试。