当 AI 编程助手修改一个函数时，它真的理解这个改动会影响多少其他模块吗？现实中，Cursor、Claude Code、Windsurf 等工具虽然强大，却并不真正「懂得」代码库的架构结构。这导致了看似局部的小改動可能引发级联破坏。GitNexus 试图从根本上解决这一问题 —— 它是一个完全运行在浏览器端的零服务器代码知识图谱引擎，无需后端 API，所有代码分析都在本地完成。
核心定位：客户端知识图谱引擎
GitNexus 提供两种使用模式。CLI 模式配合 MCP（Model Context Protocol）为 AI 代理提供深度代码感知能力，通过七个子工具让代理在编辑时能够查询依赖关系、影响范围和调用链。Web UI 模式则完全在浏览器中运行，用户可以直接上传 GitHub 仓库或 ZIP 文件，获得交互式知识图谱可视化和基于 Graph RAG 的智能问答。整个系统最显著的特性是隐私优先：CLI 模式下所有操作本地执行，不产生任何网络请求；Web UI 模式下代码永不离开浏览器，仅依赖浏览器内部的 WebAssembly 运行时。
从支持的语言范围来看，GitNexus 覆盖了主流编程语言，包括 TypeScript、JavaScript、Python、Java、C、C++、C#、Go 和 Rust。这使得它足以应对大多数现代代码库的索引需求。
技术栈解析：WASM runtime 的全链路实现
浏览器端运行代码分析引擎面临两个核心挑战：解析性能和数据存储。GitNexus 的解决方案是全面拥抱 WebAssembly。
Tree-sitter WASM 负责代码解析。Tree-sitter 是一套通用的语法分析器生成框架，能够为每种语言构建增量式 AST（抽象语法树）。在浏览器环境中，GitNexus 使用官方提供的 Tree-sitter JavaScript 绑定配合 WASM 编译后的语言 Grammar。每个源文件经过解析后，引擎从中提取关键信息：函数定义、类声明、方法签名、导入导出关系、函数调用点等。这些信息构成了知识图谱的原始节点和边。
KuzuDB WASM 负责图数据的存储与查询。Kuzu 是一款嵌入式图数据库，其 WebAssembly 版本完整支持 Cypher 查询语言和列式存储结构。GitNexus 在浏览器中实例化 Kuzu 数据库，将解析结果转化为图节点与边：节点类型包括 File、Module、Class、Function、Variable、Symbol，边类型则包括 CONTAINS、IMPORTS、CALLS、DECLARES、OVERRIDES、REFERS_TO 等。这种建模方式使得后续的路径查询、影响分析和调用链追溯成为可能。
transformers.js 提供语义嵌入能力。GitNexus 在浏览器中使用 HuggingFace 的 transformers.js 库，配合 WebGPU 或 CPU 后端为代码片段生成向量表示。这些向量与图索引结合，构成混合搜索能力 —— 既支持传统的 BM25 关键词检索，也支持语义相似度匹配，再通过 RRF（Reciprocal Rank Fusion）融合两种结果。
索引管道：六阶段流水线
GitNexus 的索引过程是一条清晰的多阶段流水线，每个阶段专注于特定任务，最终合并为完整的知识图谱。
第一阶段是结构遍历。系统递归扫描代码库的文件树，建立目录与文件的层级关系，生成 CONTAINS 边。这一阶段还负责语言过滤，只保留支持的源文件类型。
第二阶段是 AST 解析。Tree-sitter 对每个文件进行语法分析，产出完整的抽象语法树。从 AST 中，系统提取符号定义（函数、类、接口、变量）和符号引用（调用点、导入点），为后续的图构建准备原材料。
第三阶段是导入解析。对于模块化语言，解析 import/require 语句，将跨文件的依赖关系映射为 IMPORTS 边。这一步需要语言感知的解析逻辑，以正确处理相对路径、别名和动态导入。
第四阶段是调用图构建。系统将函数调用点与目标函数关联，生成 CALLS 边。为提高准确性，GitNexus 引入置信度评分机制，综合考虑符号名称匹配、参数类型推断和上下文信息。
第五阶段是聚类分析。使用 Graphology 库实现的社区检测算法，将相关符号划分为功能聚类。每个聚类代表一个逻辑模块或业务领域，聚类内部成员共享调用关系或类型依赖。
第六阶段是流程追踪。从入口点（如 main 函数、API 路由处理器）出发，系统沿调用链向后追溯，识别完整的执行流程。这些流程信息对于影响分析和 bug 追踪至关重要。
智能工具：七把面向代理的利刃
索引完成后，GitNexus 通过 MCP 协议暴露七个精心设计的工具，供 AI 代理在编辑过程中调用。
list_repos 用于发现所有已索引的代码库。当代理连接时，首先调用此工具确认可用的上下文范围。
query 执行过程分组的混合搜索。用户输入查询后，系统同时运行 BM25、语义向量和 RRF 融合，返回按执行流程组织的搜索结果，包含相关符号、所在文件和所属流程。
context 提供 360 度符号视图。以某个函数或类为焦点，返回其传入调用、传出调用、导入依赖、导出依赖，以及它参与的所有执行流程。这种全景视图让代理无需多次查询即可获得完整上下文。
impact 是最核心的工具之一。它执行爆炸半径分析，回答「修改这个符号会影响哪些代码」。分析结果按深度分组，并附带置信度评分，帮助代理判断影响范围和风险等级。
detect_changes 与 Git 集成，接收当前的 diff 信息，映射到受影响的图节点。它能够识别哪些执行流程会被改动影响，以及整体风险级别。
rename 执行多文件协调重命名。系统先在图中定位所有引用（高置信度），再通过文本搜索补充图索引可能遗漏的用例（需人工复核），最终产出完整的修改集合。
cypher 允许高级用户直接编写 Cypher 查询。对于标准工具无法覆盖的特定分析需求，这一接口提供了最大的灵活性。
这七把工具的设计理念是「预计算结构化智能」。传统 Graph RAG 需要代理发起多次查询才能逐步探索图结构，而 GitNexus 在索引阶段已经完成了调用链追溯、影响范围评估和置信度计算，工具返回的即是最完整的答案。
Graph RAG 实现：从自然语言到图查询
Web UI 模式下的智能问答基于 Graph RAG 架构实现。用户用自然语言提问，如「认证中间件的实现逻辑是什么」，系统将此问题转化为两步处理：首先通过混合搜索定位相关符号，然后沿图结构追溯这些符号参与的调用流程，最终返回结构化的答案。
更进一步的实现可以结合 WebLLM 等浏览器端 LLM，直接在客户端将自然语言翻译为 Cypher 查询语句。这样整个问答闭环都在浏览器内完成，无需任何云端 API。
隐私与安全模型
GitNexus 在设计上确保数据主权归属用户。CLI 模式将索引存储在项目根目录的 .gitnexus/ 文件夹中（自动加入 .gitignore），全局注册表位于用户主目录的 ~/.gitnexus/，仅保存路径和元数据。Web UI 模式下，所有数据保存在浏览器内存或 IndexedDB 中，API 密钥也仅存在于 localStorage。代码本身开源可审计，用户可以自行验证数据流向。
实践路径与参数建议
若要在项目中部署 GitNexus，推荐的启动流程如下。首先通过 npm 全局安装 CLI：npm install -g gitnexus。在项目根目录执行 gitnexus analyze 完成首次索引（约 5 分钟，取决于代码库规模）。随后运行 gitnexus setup 自动配置 MCP 客户端。若仅需浏览器端探索，可直接访问 gitnexus.vercel.app 并上传 ZIP 文件。
对于浏览器端使用，内存限制是需要关注的工程参数。官方文档指出 Web UI 模式建议控制在约 5000 个文件以内，超出此规模可能导致浏览器内存压力。对于更大规模的代码库，建议使用 CLI 模式配合本地 KuzuDB 原生实例。
资料来源
- GitNexus 官方仓库：https://github.com/abhigyanpatwari/GitNexus
- KuzuDB WASM 官方文档：https://www.npmjs.com/package/@kuzu/kuzu-wasm