在 AI 编程工具的持续演进中，如何让代码智能体高效理解项目上下文，始终是绕不开的核心难题。AutoDev 最新推出的预上下文引擎，试图用更务实的方式解决这一挑战——离线构建代码的语义化数据，从而大幅提升代码检索与生成的响应速度。简单来说，就是将检索增强生成（RAG）中的“资料查找”环节，从运行时动态查询，变为预先整理好的知识卡片。

首先来看预生成上下文的核心定义：它是指在用户发起查询或生成请求之前，系统针对特定代码仓库、文档或 SDK，离线构建一组语义化的上下文数据。这些数据经过理解、加工与组织，在运行时可以被快速检索和引用。其目的是让代码智能体在生成、解释或检索代码时，输出更准确、相关性更强、响应速度更快。

在 AutoDev Workbench 中，这一思想被拆解为分析端与后端。分析端的具体实现，就是名为 AutoDev Context Worker 的工具。你可以直接使用以下命令为代码仓库生成上下文：

npx @autodev/context-worker@latest

PS：npx 是 Node.js 的包管理工具，可以直接运行 npm 包中的命令。

引子：寻找更高效的 RAG 方式

RAG 是 AI 应用里绕不开的关键技术。尽管在 AutoDev 的 VSCode 版本中，我们已经构建了多种基于向量化的 RAG 方案，但一直以来的直觉是——对大部分项目而言，纯向量化的 RAG 性价比并不高。

性价比低的向量化代码检索

为什么说性价比低？理由很直接：

• 向量化索引本身就是一个成本高昂的过程，无论你使用本地还是云端方案。
• 实时刷新向量化索引是另一个令人头疼的难点，特别是在本地机器上运行时，资源消耗相当可观。
• 最关键的是，代码库里并没有海量的文档知识，更多的是代码本身的语义信息。用向量化检索代码，多少有些大炮打蚊子的意味。

从2025年的技术趋势来看，基于向量化的 RAG 已经逐渐退居二线。像 Cursor 这类工具，也只会在 AI 第一次检索不到相关信息时，才退而求其次使用向量化方式。

内部框架等固定知识的预生成

另一点在于，作为一个 AI 编程工具，我们经常要面对大量内部框架、SDK、API 这类固定知识的查询。这些知识相对稳定，用户的问题模式也颇为明确——他们不会问“如何使用 Spring Boot 构建 Web 应用”，而是会问“如何在 Spring Boot 中使用 xx 框架”。

针对这类需要提供固定知识的场景，大致可以归纳为几类：

• 内部开发框架：既能处理单个组件的问题，也能解决多个组件协同使用时的排查需求，往往需要了解部分底层代码信息。
• SDK 与 API：用户通常不想深究实现细节，只想知道如何用它们完成特定任务。
• 其他公共代码库：比如如何调用某个公共库来完成一个特定功能。

对于这些场景，完全可以用更高效的方式来生成本地化、结构化的上下文信息。

Context Worker：预生成代码上下文

正是为了应对上述场景，才有了 Context Worker 这个工具。它专门用于深度解析和分析代码，帮助开发者和 AI 更高效地理解代码库。

AutoDev Context Worker 是一个用于深度解析和分析代码的工具，旨在为开发者提供更好的上下文理解和智能化的代码处理能力。

设计与目标

Context Worker 的底层脱胎于我们先前的 VSCode 版本，我们将其中核心的代码解析和分析功能抽取出来，独立成一个工具。在此基础上，我们进一步扩充了多语言支持，现在它可以处理 Java、JavaScript、TypeScript、Python、Golang、Rust、C/C++、Ruby、C# 等十几种主流语言。

结合 AutoDev Workbench 的服务端能力，Context Worker 为开发者提供了三个层面的支持：

• 深度项目解析与 AST 构建：对整个项目或指定模块范围进行深度解析，构建完整的抽象语法树（AST），识别所有函数、类、接口及其签名和注释。同时分析项目依赖（包括内部模块间和外部库依赖），初步构建出依赖图。
• 自动化代码摘要与“意图”标注：对于缺乏良好注释的代码块，尝试使用 LLM 预先生成简洁的摘要或“意图描述”。对一些关键的架构组件或核心算法，可以预先打上特定的标签或元数据，方便后续检索时直接命中。
• 构建项目级知识图谱：将解析出的代码实体（类、函数、变量等）及其关系（调用、继承、实现、引用等）编织起来，围绕领域模型构建知识图谱，并标注实体的语义和上下文信息。

使用 AutoDev Context Worker

使用方式相当直接，运行一条命令即可：

npx @autodev/context-worker --path /path/to/project --upload --server-url https://your-server/api/context --non-interactive

该命令会启动 Context Worker，对指定目录下的代码进行解析和分析。下面是一个生成数据的示例片段：

接口:UserRepository
文件:/path/to/UserRepository.java
接口定义：
```java
public interface UserRepository extends JpaRepository {
    Optional findByUsername(String username);
    List findByEmail(String email);
}
```
===实现类(1)===
实现类:UserRepositoryImpl
文件:/path/to/UserRepositoryImpl.java
```java
@Repository
public class UserRepositoryImpl implements UserRepository {
    // ...实现代码...
    @Override
    public Optional findByUsername(String username) {
        // ...方法实现...
    }
    @Override
    public List findByEmail(String email) {
        // ...方法实现...
    }
}
```

Context Worker 自动分析代码中的接口、实现类、方法等信息，生成结构化的上下文知识。你可以把这些信息存入知识库，后续调用 AI 来生成对应的 name 和 description 描述，就能在不同场景中直接使用了。

使用 MCP 获取上下文知识

进一步地，结合 AutoDev Workbench 提供的 MCP（Model Context Protocol）服务，AI 编程工具可以通过 MCP 接口直接获取到已知问题所需的上下文知识——整个过程完全是按需、高效地进行。

总结

总的来看，预上下文引擎并不是要推翻 RAG，而是找到了一种更务实、更轻量的方式，专门针对代码场景（尤其是固定知识与内部框架）做优化。这套思路的核心在于：把“运行时查”变成“预先存”，把“通用的向量搜索”变成“精准的结构化匹配”。对于有大量固定知识需要频繁查询的团队来说，这或许是一条更值得探索的路。