先说清楚：为什么要给代码库建图，而不是继续 grep
编码 agent 的强项是「改好一个文件」，弱项是「回答跨文件的结构问题」。你问它「认证是怎么一路走到数据库的」「改掉这个字段还有谁会受影响」，它只能靠反复 grep、把相关目录一股脑塞进上下文，然后在这些文件里自己拼结构——既慢又贵，而且很容易漏掉间接调用。Graphify 的做法不是让它读得更多，而是先把仓库变成一张图：代码、文档、SQL schema、配置、PDF 都解析成节点与边，问题变成「在图里找路径」「看谁连着谁」。它强调三点：本地确定性解析（tree-sitter，不走向量库）、每条边都能解释、结果可复现。
第一步：装上，并确认它认你的语言
官方 PyPI 包名是 graphifyy（注意是双 y），CLI 命令仍然是 graphify，要求 Python 3.10 以上。用 uv 装最省事，不会污染系统环境。装完先看版本，再跑一次 install，把 skill 注册到你的编码 agent 里。
uv tool install graphifyy
graphify --version
graphify install这里有个容易踩的坑：PyPI 上要认准 graphifyy 这个包，官方仓库只有 Graphify-Labs/graphify 一个。装错同名包，后面命令对不上会白折腾。
第二步：给一个仓库建图，先看它把什么当节点、什么当边
在仓库根目录建图，让它完整走一遍 AST 解析。第一次别拿最大的仓库试，先挑一个中小型项目，跑完打开产物看两件事：它把哪些东西识别成了节点（函数、类、文件、数据库表、文档章节），又用哪些关系连起来（调用、导入、引用、外键）。确认它认得出你项目的主语言，比什么都重要。
cd your-project
graphify build .
# 产物是一份图（节点 + 边），不是向量库；重复跑应得到一致的图第一次跑得慢是正常的——它在做确定性解析，而不是把源码切块丢进嵌入模型。慢一点换来的好处是：同样的输入应该得到同样的图，也就能拿来做前后对比。
第三步：改用「问题」提问，而不是「喂文件」
建完图之后，让 agent 按图来问：某个入口到数据库的路径是什么、这个函数被谁调用、哪个模块是连接度异常高的「上帝节点」、以及用 Leiden 聚类出来的社区里有哪些松耦合的子图。这一步的目标是让它先形成结构判断，再去动代码；顺序反了，就还是回到「读一堆文件再猜」的老路。
graphify path "auth.login -> db.write"
graphify explain src/auth/session.py
graphify communities第四步：用对照组量一量，它到底省没省上下文
「感觉聪明多了」不算结论。给同一批跨文件问题做两组对照：A 组让 agent 自己 grep 加读文件，B 组让它先看图再定位；两组用同一模型、同一批问题，记录三件事——消耗的 token、来回轮次、是否一次改对。最能说明问题的是前两项，因为它们直接对应成本；第三项决定它值不值得长期用。结论要写成能复跑的表格或脚本，而不是一句印象。
- 固定同一批 8-10 个跨文件问题，比如「改这个字段会影响哪些调用方」「这条链路有几个写库点」
- 两组都用同一模型与同一批问题，分别记录 token、轮次、是否一次改对
- 只在图覆盖得到的语言与仓库上比较，别拿它没解析的语言硬比
- 把对照做成脚本，下次换模型或换仓库时能重跑一遍
第五步：接进 agent，同时把边界说清楚
skill 装好之后，在支持的环境里用 /graphify . 触发，让它成为「改代码之前的第一步」，而不是又一个可选命令。支持的平台不少（Claude Code、Cursor、Codex、Gemini CLI 等），团队里最好统一一下：哪些改动必须先看图、哪些小修可以跳过，写进你们的协作约定，否则又会变成「有人用、有人不用」。
# 在支持的编码 agent 里
/graphify .边界同样要说清：Graphify 解析的是结构，不判断业务对错——它能告诉你「谁调用了谁」，不能告诉你「这样调用符不符合业务规则」；对动态拼接出来的调用（反射、字符串拼出来的导入）它会漏；仓库特别大时，建图本身的耗时与产物体积会变成新的成本。把它当成「更快形成结构判断」的工具，而不是替代测试与代码评审。
一句话总结：先用图看清结构，再动手改代码。它省下的不是打字时间，而是「改错地方」之后那一次返工。