本文摘要向量RAG在代码库问答里常召回错函数跨文件调用链答非所问。确定性AST建图能给出每条边的代码出处但反射与动态派发调用不产生边。动态调用密集的代码库不适合纯静态建图仍需运行时追踪兜底。一、问题与结论在Claude Code里问「谁调用了PaymentProcessor.charge」向量检索召回的是另一个模块里名字相近的charge_fee换成知识图谱查询返回空列表。两种失败形态不同根因也不同RAG卡在召回图谱卡在建图。换问法、调top_k只能缓解前者。local deterministic AST parsing只为源码中显式存在的结构建边getattr、装饰器注册、字符串键派发这些位置不产生目标方法的边。缺失的边不带「不确定」标记而是完全不存在。查询侧无法区分「无人调用」与「调用被动态隐藏」容易误导重构决策。来源边界下文关于 Graphify 机制的表述来自其仓库自述local deterministic AST parsing、every edge explained、no vector store。来源未提供版本号、变更日志与语言支持清单因此不对其具体实现行为做断言只分析「确定性 AST 解析」这条技术路线的能力边界。二、排查与选择依据怎么判断是查询问题还是建图问题在源码里全局搜charge(确认调用点确实存在查图谱中dispatch的出边看是否只剩getattr这类系统函数边调用点在源码里有、图里没有问题在建图继续改查询措辞是无效劳动。本地建图与/graphify接入仓库自述提供/graphifyskill面向Claude Code、Cursor、Codex、Gemini CLI。通用形态是在目标代码库根目录启动 CLI、触发/graphify建图之后用自然语言提问输出为边列表每条边附来源位置与解释。具体命令参数、输出字段与建图耗时来源未提供这里不写虚构示例。【未验证】替代方案与取舍方案选择条件代价边界确定性 AST 建图调用关系在源码中显式可见如 Go、Java 严格模式建图成本低边可逐条解释动态调用、跨仓库实现不建边AST 运行时追踪有测试覆盖到动态路径追踪有性能开销需跑测试只覆盖被执行过的路径向量检索兜底需要跨仓库、语义级候选定位召回不稳定需人工过滤可能答非所问需回源码核实不该用纯 AST 建图的场景eval驱动的 DSL、热加载插件系统、问答目标以跨仓库调用链为主。这些情况下图谱只能当索引结论必须靠人工或运行时数据交叉验证。三、关键原理每条边的来源都能回指到具体代码位置边代码形态出处调用边obj.method()该行Call节点文件:行号依赖边from a import bImport节点继承边class A(B)ClassDef基类列表而getattr(obj, name)里AST 只能看到getattr这个调用本身name指向哪个方法要等运行时求值handlers[key](args)的目标由字典内容决定app.route注册的入口由框架内部派发。这些位置不产生不确定边而是不产生边。deterministic的含义是可复现同一代码库每次建图结果一致。但一致不等于完整它是稳定地缺少动态调用边。四、可运行示例环境Python 3.10无第三方依赖同目录两个文件。dispatch_demo.pyclassPaymentProcessor:defcharge(self,amount:int)-str:returnfcharged{amount}processors{pay:PaymentProcessor()}defdispatch(action:str,amount:int)-str:targetprocessors[action]fngetattr(target,charge)returnfn(amount)print(dispatch(pay,100))edge_scan.py用标准库ast做确定性解析列出静态可见的调用名importastwithopen(dispatch_demo.py,encodingutf-8)asf:treeast.parse(f.read())callsset()fornodeinast.walk(tree):ifisinstance(node,ast.Call):fnnode.funcifisinstance(fn,ast.Name):calls.add(fn.id)elifisinstance(fn,ast.Attribute):calls.add(fn.attr)print(静态可见调用:,sorted(calls))print(是否包含 charge:,chargeincalls)操作步骤python edge_scan.py预期输出按ast.walk语义推导未在本机执行【未验证】静态可见调用: [PaymentProcessor, dispatch, fn, getattr, print] 是否包含 charge: False实际输出python dispatch_demo.py打印charged 100fn在运行时指向PaymentProcessor.charge。两条输出的差异就是建图缺口——调用真实发生图里没有这条边。常见失败是反复调整提问措辞、怀疑索引没建好。原因不是查询而是边不存在。修复办法是对这类模块叠加运行时追踪或在团队文档里标注「此处图谱不完整」。五、验证结果与边界动态调用侧getattr、字符串键派发、装饰器路由、配置映射OPERATION_MAP写在 YAML 里时更糟映射关系可能双重丢失在纯 AST 图中都没有边UserService的方法会呈现为孤立节点。跨仓库依赖侧本地建图的输入是单个代码库外部包的调用链即使有import边也只指向包名回答不了「库里哪个实现被调用」。跨仓库边是否补全来源未说明。【未验证】何时仍需向量检索兜底跨仓库语义问答、文档与代码对照、动态调用密集模块的候选定位。做法是先用向量检索圈出范围再回到源码与图谱逐条核实边两者互为交叉验证不互相替代。思考低置信度候选边应与确定性边同图存放还是单独分层跨仓库调用链靠多库联合建图解决还是交给向量检索兜底参考资料Graphify-Labs/graphify