AI 研发提效：构建 AI 辅助编码助手

Cover

2023 年，生成式 AI 的火爆，让越来越多的组织开始引入 AI 辅助编码。与在 2021 年发布的 GitHub Copilot 稍有差异的是，代码补全只是众多场景中的一个。大量的企业内部在探索结合需求生成完整代码、代码审查等场景，也引入生成式 AI，来提升开发效率。

在这个背景下，我们（Thoughtworks 开源社区）也开源了一系列的 AI 辅助工具，以帮助更多的组织构建自己的 AI 辅助编码助手：

AutoDev for Intellij，基于 JetBrains 平台的全流程 AI 辅助编码工具。
AutoDev for VSCode，基于 VSCode 编辑器的全流程 AI 辅助编码工具。
Unit Eval，代码补全场景下的高质量数据集构建与生成工具。
Unit Minions，在需求生成、测试生成等测试场景下，基于数据蒸馏的数据集构建工具。

由于，我们设计 AutoDev 时，各类开源模型也在不断演进。在这个背景下，它的步骤是：

构建 IDE 插件与度量体系设计。基于公开模型 API，编写和丰富 IDE 插件功能。
模型评估体系与微调试验。
围绕意图的数据工程与模型演进。

也因此，这个教程也是围绕于这三个步骤展开的。除此，基于我们的经验，本教程的示例技术栈：

插件：Intellij IDEA。AutoDev 是基于 Intellij IDEA 构建的，并且自带静态代码分析能力，所以基于它作为示例。我们也提供了 VSCode 插件版本：AutoDev for VSCode，你可以在这个基础上进行开发。
模型：DeepSeek Coder 6.7b。基于 Llama 2 架构，与 Llama 生态兼容
微调：Deepspeed + 官方脚本 + Unit Eval。
GPU：RTX 4090x2 + OpenBayes。（PS: 用我的专用邀请链接，注册 OpenBayes，双方各获得 60 分钟 RTX 4090 使用时长，支持累积，永久有效： https://openbayes.com/console/signup?r=phodal_uVxU ）

由于，我们在 AI 方面的经验相对比较有限，难免会有一些错误，所以，我们也希望能够与更多的开发者一起，来构建这个开源项目。

功能设计：定义你的 AI 助手

结合 JetBrains 2023《开发者生态系统》报告的人工智能部分，我们可以总结出一些通用的场景，这些场景反映了在开发过程中生成式 AI 可以发挥作用的领域。以下是一些主要的场景：

代码自动补全：在日常编码中，生成式 AI 可以通过分析上下文和学习代码模式，提供智能的代码自动补全建议，从而提高开发效率。
解释代码：生成式 AI 能够解释代码，帮助开发者理解特定代码片段的功能和实现方式，提供更深层次的代码理解支持。
生成代码：通过学习大量的代码库和模式，生成式 AI 可以生成符合需求的代码片段，加速开发过程，尤其在重复性工作中发挥重要作用。
代码审查：生成式 AI 能够进行代码审查，提供高质量的建议和反馈，帮助开发者改进代码质量、遵循最佳实践。
自然语言查询：开发者可以使用自然语言查询与生成式 AI 进行交互，提出问题或请求，以获取相关代码片段、文档或解释，使得开发者更轻松地获取需要的信息。
其它。诸如于重构、提交信息生成、建模、提交总结等。

而在我们构建 AutoDev 时，也发现了诸如于创建 SQL DDL、生成需求、TDD 等场景。所以。我们提供了自定义场景的能力，以让开发者可以自定义自己的 AI 能力，详细见：https://ide.unitmesh.cc/customize。

场景驱动架构设计：平衡模型速度与能力

在日常编码时，会存在几类不同场景，对于 AI 响应速度的要求也是不同的（仅作为示例）：

场景	响应速度	生成质量要求	大小预期	说明
代码补全	快	中	1~6B	代码补全是日常编码中最常用的场景，响应速度至关重要。
文档生成	中	中	16B	文档生成需要充分理解代码结构，速度和质量同样重要。
代码审查	快	中	16B	代码审查需要高质量的建议，同时响应速度也需尽可能快。
单元测试生成	快	中	6B~	单元测试生成的上下文较少，响应速度和AI质量同样重要。
代码重构	中	高	32B~	代码重构可能需要更多上下文理解，响应速度可适度减缓。
需求生成	中	高	32B~	需求生成是相对复杂的场景，响应速度可以适度放缓，确保准确性。
自然语言代码搜索与解释	中-低	高	32B~	自然语言代码搜索与解释是相对复杂的场景，响应速度可以适度放缓，确保准确性。

PS：这里的 32B 仅作为一个量级表示，因为在更大的模型下，效果会更好。

因此，我们将其总结为：一大一中一微三模型，提供全面 AI 辅助编码：

高质量大模型：32B~。用于代码重构、需求生成、自然语言代码搜索与解释等场景。
高响应速度中模型：6B~。用于代码补全、单元测试生成、文档生成、代码审查等场景。
向量化微模型：~100M。用于在 IDE 中进行向量化，诸如：代码相似度、代码相关度等。

重点场景介绍：补全模式

AI 代码补全能结合 IDE 工具分析代码上下文和程序语言的规则，由 AI 自动生成或建议代码片段。在类似于 GitHub Copilot 的代码补全工具中，通常会分为三种细分模式：

行内补全（Inline）

类似于 FIM（fill in the middle）的模式，补全的内容在当前行中。诸如于：BlotPost blogpost = new，补全为： BlogPost();，以实现：BlogPost blogpost = new BlogPost();。

我们可以 Deepseek Coder 作为例子，看在这个场景下的效果：

<｜fim▁begin｜>def quick_sort(arr):
    if len(arr) <= 1:
        return arr
    pivot = arr[0]
    left = []
    right = []
<｜fim▁hole｜>
        if arr[i] < pivot:
            left.append(arr[i])
        else:
            right.append(arr[i])
    return quick_sort(left) + [pivot] + quick_sort(right)<｜fim▁end｜>

在这里，我们就需要结合光标前和光标后的代码。

块内补全（InBlock）

通过上下文学习（In-Context Learning）来实现，补全的内容在当前函数块中。诸如于，原始的代码是：

fun createBlog(blogDto: CreateBlogDto): BlogPost {

}

补全的代码为：

    val blogPost = BlogPost(
    title = blogDto.title,
    content = blogDto.content,
    author = blogDto.author
)
return blogRepository.save(blogPost)

块间补全（AfterBlock）

通过上下文学习（In-Context Learning）来实现，在当前函数块之后补全，如：在当前函数块之后补全一个新的函数。诸如于，原始的代码是：

fun createBlog(blogDto: CreateBlogDto): BlogPost {
    //...
}

补全的代码为：

fun updateBlog(id: Long, blogDto: CreateBlogDto): BlogPost {
    //...
}

fun deleteBlog(id: Long) {
    //...
}

在我们构建对应的 AI 补全功能时，也需要考虑应用到对应的模式数据集，以提升补全的质量，提供更好的用户体验。

编写本文里的一些相关资源：

重点场景介绍：代码解释

代码解释旨在帮助开发者更有效地管理和理解大型代码库。这些助手能够回答关于代码库的问题、提供文档、搜索代码、识别错误源头、减少代码重复等，从而提高开发效率、降低错误率，并减轻开发者的工作负担。

在这个场景下，取决于我们预期的生成质量，通常会由一大一微或一中一微两个模型组成，更大的模型在生成的质量上结果更好。结合，我们在 Chocolate Factory 工具中的设计经验，通常这样的功能可以分为几步：

理解用户意图：借助大模型理解用户意图，将其转换为对应的 AI Agent 能力调用或者 function calling 。
转换意图搜索：借助模型将用户意图转换为对应的代码片段、文档或解释，结合传统搜索、路径搜索和向量化搜索等技术，进行搜索及排序。
输出结果：交由大模型对最后的结果进行总结，输出给用户。

作为一个 RAG 应用，其分为 indexing 和 query 两个部分。

在 indexing 阶段，我们需要将代码库进行索引，并涉及到文本分割、向量化、数据库索引等技术。其中最有挑战的一个内容是拆分，我们参考的折分规则是：https://docs.sweep.dev/blogs/chunking-2m-files 。即：

代码的平均 Token 到字符比例约为1:5（300 个 Token），而嵌入模型的 Token 上限为 512 个。
1500 个字符大约对应于 40 行，大致相当于一个小到中等大小的函数或类。
挑战在于尽可能接近 1500 个字符，同时确保分块在语义上相似且相关上下文连接在一起。

在不同的场景下，我们也可以通过不同的方式进行折分，如在 Chocolate Factory 是通过 AST 进行折分，以保证生成上下文的质量。

在 querying 阶段，需要结合我们一些传统的搜索技术，如：向量化搜索、路径搜索等，以保证搜索的质量。同时，在中文场景下，我们也需要考虑到转换为中文的问题，如：将英文转换为中文，以保证搜索的质量。

相关工具：https://github.com/BloopAI/bloop
相关资源：
- Prompt 策略：代码库 AI 助手的语义化搜索设计

其它：日常辅助

对于日常辅助来说，我们也可以通过生成式 AI 来实现，如：自动创建 SQL DDL、自动创建测试用例、自动创建需求等。这些只需要通过自定义提示词，结合特定的领域知识，便可以实现，这里不再赘述。

架构设计：上下文工程

除了模型之外，上下文也是影响 AI 辅助能力的重要因素。在我们构建 AutoDev 时，我们也发现了两种不同的上下文模式：

相关上下文：基于静态代码分析的上下文生成，可以构建更好质量的上下文，以生成更高质量的代码和测试等，依赖于 IDE 的静态代码分析能力。
相似上下文：基于相似式搜索的上下文，可以构建更多的上下文，以生成更多的代码和测试等，与平台能力无关。

简单对比如下：

	相关上下文	相似上下文
检索技术	静态代码分析	相似式搜索
数据结构信息	AST、CFG	Similar Chunk
跨平台能力	依赖于 IDE，或者独立的解析器	不依赖具体平台
上下文质量	极高	高
生成结果	极高