我们会在 GitHub 上持续更新这个教程: https://github.com/phodal/build-ai-coding-assistant，欢迎在 GitHub 上讨论。
2023 年，生成式 AI 的火爆，让越来越多的组织开始引入 AI 辅助编码。与在 2021 年发布的 GitHub Copilot 稍有差异的是，代码补全只是重多场景中的一个。大量的企业内部在探索结合需求生成完整代码、代码审查等场景，也引入生成式 AI，来提升开发效率。
在这个背景下，我们（Thoughtworks）也开发了一系列的开源工具，以帮助更多的组织构建自己的 AI 辅助编码助手：
AutoDev，基于 JetBrains 平台的全流程 AI 辅助编码工具。
Unit Eval，代码补全场景下的高质量数据集构建与生成工具。
Unit Minions，在需求生成、测试生成等测试场景下，基于数据蒸馏的数据集构建工具。
由于，我们设计 AutoDev 时，各类开源模型也在不断演进。在这个背景下，它的步骤是：
构建 IDE 插件与度量体系设计。基于公开模型 API，编写和丰富 IDE 插件功能。
模型评估体系与微调试验。
围绕意图的数据工程与模型演进。
也因此，这个教程也是围绕于这三个步骤展开的。除此，基于我们的经验，本教程的示例技术栈：
插件：Intellij IDEA。AutoDev 是基于 Intellij IDEA 构建的，并且自带静态代码分析能力，所以基于它作为示例。我们也提供了 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 方面的经验相对比较有限，难免会有一些错误，所以，我们也希望能够与更多的开发者一起，来构建这个开源项目。
结合 JetBrains 2023《开发者生态系统》报告的人工智能部分 ，我们可以总结出一些通用的场景，这些场景反映了在开发过程中生成式 AI 可以发挥作用的领域。以下是一些主要的场景：
代码自动补全：在日常编码中，生成式 AI 可以通过分析上下文和学习代码模式，提供智能的代码自动补全建议，从而提高开发效率。
解释代码：生成式 AI 能够解释代码，帮助开发者理解特定代码片段的功能和实现方式，提供更深层次的代码理解支持。
生成代码：通过学习大量的代码库和模式，生成式 AI 可以生成符合需求的代码片段，加速开发过程，尤其在重复性工作中发挥重要作用。
代码审查：生成式 AI 能够进行代码审查，提供高质量的建议和反馈，帮助开发者改进代码质量、遵循最佳实践。
自然语言查询：开发者可以使用自然语言查询与生成式 AI 进行交互，提出问题或请求，以获取相关代码片段、文档或解释，使得开发者更轻松地获取需要的信息。
其它。诸如于重构、提交信息生成、建模、提交总结等。
而在我们构建 AutoDev 时，也发现了诸如于创建 SQL DDL、生成需求、TDD 等场景。所以。我们提供了自定义场景的能力，以让开发者可以自定义自己的 AI 能力，详细见：https://ide.unitmesh.cc/customize。
场景驱动架构设计：平衡模型速度与能力
在日常编码时，会存在几类不同场景，对于 AI 响应速度的要求也是不同的（仅作为示例）：
PS：这里的 32B 仅作为一个量级表示，因为在更大的模型下，效果会更好。
因此，我们将其总结为：一大一中一微三模型，提供全面 AI 辅助编码：
高质量大模型：32B~。用于代码重构、需求生成、自然语言代码搜索与解释等场景。
高响应速度中模型：6B~。用于代码补全、单元测试生成、文档生成、代码审查等场景。
向量化微模型：~100M。用于在 IDE 中进行向量化，诸如：代码相似度、代码相关度等。
重点场景介绍：补全模式
AI 代码补全能结合 IDE 工具分析代码上下文和程序语言的规则，由 AI 自动生成或建议代码片段。在类似于 GitHub Copilot 的代码补全工具中， 通常会分为三种细分模式：
行内补全（Inline）
类似于 FIM（fill in the middle）的模式，补全的内容在当前行中。诸如于： ，补全为： ， 以实现： 。
我们可以 Deepseek Coder 作为例子，看在这个场景下的效果：
在这里，我们就需要结合光标前和光标后的代码。
块内补全（InBlock）
通过上下文学习（In-Context Learning）来实现，补全的内容在当前函数块中。诸如于，原始的代码是：
补全的代码为：
块间补全（AfterBlock）
通过上下文学习（In-Context Learning）来实现，在当前函数块之后补全，如：在当前函数块之后补全一个新的函数。诸如于，原始的代码是：
补全的代码为：
在我们构建对应的 AI 补全功能时，也需要考虑应用到对应的模式数据集，以提升补全的质量，提供更好的用户体验。
编写本文里的一些相关资源：
Why your AI Code Completion tool needs to Fill in the Middle
Exploring Custom LLM-Based Coding Assistance Functions
重点场景介绍：代码解释
代码解释旨在帮助开发者更有效地管理和理解大型代码库。这些助手能够回答关于代码库的问题、 提供文档、搜索代码、识别错误源头、减少代码重复等， 从而提高开发效率、降低错误率，并减轻开发者的工作负担。
在这个场景下，取决于我们预期的生成质量，通常会由一大一微或一中一微两个模型组成，更大的模型在生成的质量上结果更好。结合，我们在 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 的静态代码分析能力。
相似上下文：基于相似式搜索的上下文，可以构建更多的上下文，以生成更多的代码和测试等，与平台能力无关。
简单对比如下：
在支持 IDE 有限时，相关上下文的才会带来更高的性价高。
相似上下文架构：GitHub Copilot 案例
GitHub Copilot 采用了相似上下文的架构模式，其精略的架构分层如下：
监听用户操作（IDE API ）。监听用户的 Run Action、快捷键、UI 操作、输入等，以及最近的文档操作历史（20 个文件）。
IDE 胶水层（Plugin）。作为 IDE 与底层 Agent 的胶水层，处理输入和输出。
上下文构建（Agent）。JSON RPC Server，处理 IDE 的各种变化，对源码进行分析，封装为 “prompt” （疑似） 并发送给服务器。
服务端（Server）。处理 prompt 请求，并交给 LLM 服务端处理。
在 “公开” 的 Copilot-Explorer 项目的研究资料里，可以看到 Prompt 是如何构建出来的。如下是发送到的 prompt 请求：
其中：
用于构建 prompt 的 部分，是由 promptElements 构建了，其中包含了： , , , , , , 等类型。从几种 的名称，我们也可以看出其真正的含义。
用于构建 prompt 的 部分，则是由光标所在的部分决定的，根据 tokens 的上限（2048 ）去计算还有多少位置放下。而这里的 Token 计算则是真正的 LLM 的 token 计算，在 Copilot 里是通过 Cushman002 计算的，诸如于中文的字符的 token 长度是不一样的，如： ，其中 context 中的内容的 length 为 20，但是 tokenLength 是 30，中文字符共 5 个（包含 ）的长度，单个字符占的 token 就是 3。
如下是一个更详细的 Java 应用的上下文示例：
在计算上下文里，GitHub Copilot 采用的是 Jaccard 系数 (Jaccard Similarity) ，这部分的实现是在 Agent 实现，更详细的逻辑可以参考： 花了大半个月，我终于逆向分析了Github Copilot。
相关资源：
上下文工程：基于 Github Copilot 的实时能力分析与思考
相关上下文架构：AutoDev 与 JetBrains AI Assistant 案例
如上所述，相关代码依赖于静态代码分析，主要借助于代码的结构信息，如：AST、CFG、DDG 等。在不同的场景和平台之下，我们可以结合不同的静态代码分析工具， 如下是常见的一些静态代码分析工具：
TreeSitter，由 GitHub 开发的用于生成高效的自定义语法分析器的框架。
Intellij PSI （Program Structure Interface），由 JetBrains 开发的用于其 IDE 的静态代码分析接口。
LSP（Language Server Protocol），由微软开发的用于 IDE 的通用语言服务器协议。
Chapi (common hierarchical abstract parser implementation) ，由笔者（@phodal）开发的用于通用的静态代码分析工具。
在补全场景下，通过静态代码分析，我们可以得到当前的上下文，如：当前的函数、当前的类、当前的文件等。如下是一个 AutoDev 的生成单元测试的上下文示例：
在这个示例中，会分析 函数的上下文，获取函数的输入和输出类： 、 信息，以及 BlogService 类信息，作为上下文（在注释中提供）提供给模型。在这时，模型会生成更准确的构造函数，以及更准确的测试用例。
由于相关上下文依赖于对不同语言的静态代码分析、不同 IDE 的 API，所以，我们也需要针对不同的语言、不同的 IDE 进行适配。在构建成本上，相对于相似上下文成本更高。
IDE、编辑器作为开发者的主要工具，其设计和学习成本也相对比较高。首先，我们可以用官方提供的模板生成：
IDEA 插件模板
VSCode 插件生成
然后，再往上添加功能（是不是很简单），当然不是。以下是一些可以参考的 IDEA 插件资源：
Intellij Community 版本源码
IntelliJ SDK Docs Code Samples
Intellij Rust
当然了，更合适的是参考AutoDev 插件。
JetBrains 插件
可以直接使用官方的模板来生成对应的插件：https://github.com/JetBrains/intellij-platform-plugin-template
对于 IDEA 插件实现来说，主要是通过 Action 和 Listener 来实现的，只需要在 中注册即可。详细可以参考官方文档：IntelliJ Platform Plugin SDK
版本兼容与兼容架构
由于我们前期未 AutoDev 考虑到对 IDE 版本的兼容问题，后期为了兼容旧版本的 IDE，我们需要对插件进行兼容性处理。所以，如官方文档：Build Number Ranges 中所描述，我们可以看到不同版本，对于 JDK 的要求是不一样的，如下是不同版本的要求：
并配置到 中：
后续配置兼容性比较麻烦，可以参考 AutoDev 的设计。
补全模式：Inlay
在自动代码补全上，国内的厂商主要参考的是 GitHub Copilot 的实现，逻辑也不复杂。
采用快捷键方式触发
其主要是在 Action 里监听用户的输入，然后:
采用自动触发方式
其主要通过 监听用户的输入，然后：根据不同的输入，触发不同的补全结果。核心代码如下：
再根据不同的输入，触发不同的补全结果，并对结构进行处理。
渲染补全代码
随后，我们需要实现一个 Inlay Render，它继承自 。
日常辅助功能开发
结合 IDE 的接口能力，我们需要添加对应的 Action，以及对应的 Group，以及对应的 Icon。如下是一个 Action 的示例：
如下是 AutoDev 的一些 ActionGroup：
在编写 ShowIntentionsGroup 时，我们可以参考 AutoDev 的实现来构建对应的 Group：
多语言上下文架构
由于 Intellij 的平台策略，使得运行于 Java IDE（Intellij IDEA）与在其它 IDE 如 Python IDE（Pycharm）之间的差异性变得更大。我们需要提供基于多平台产品的兼容性，详细介绍可以参考：Plugin Compatibility with IntelliJ Platform Products
首先，将插件的架构进一步模块化，即针对于不同的语言，提供不同的模块。如下是 AutoDev 的模块化架构：
在 中，我们需要添加对应的 ，以及 ，如下是一个示例：
而在 中，我们需要添加对应的 ，以及 ，如下是一个示例：
随后，Intellij 会自动加载对应的模块，以实现多语言的支持。根据我们预期支持的不同语言，便需要对应的 ，诸如于：
最后，在不同的语言模块里，实现对应的功能即可。
上下文构建
为了简化这个过程，我们使用 Unit Eval 来展示如何构建两种类似的上下文。
静态代码分析
通过静态代码分析，我们可以得到当前的函数、当前的类、当前的文件等。再结合路径相似性，寻找最贴进的上下文。
上述的代码，我们可以通过代码的 Imports 信息作为相关代码的一部分。再通过代码的继承关系，来寻找相关的代码。最后，通过再路径相似性，来寻找最贴近的上下文。
相关代码分析
先寻找，再通过代码相似性，来寻找相关的代码。核心逻辑所示：
详细见：SimilarChunker
VSCode 插件
TODO
TreeSitter
TreeSitter 是一个用于生成高效的自定义语法分析器的框架，由 GitHub 开发。它使用 LR（1）解析器，这意味着它可以在 O（n）时间内解析任何语言，而不是 O（n²）时间。它还使用了一种称为“语法树的重用”的技术，该技术使其能够在不重新解析整个文件的情况下更新语法树。
由于 TreeSitter 已经提供了多语言的支持，你可以使用 Node.js、Rust 等语言来构建对应的插件。详细见：TreeSitter。
根据我们的意图不同，使用 TreeSitter 也有不同的方式：
解析 Symbol
在代码自然语言搜索引擎 Bloop 中，我们使用 TreeSitter 来解析 Symbol，以实现更好的搜索质量。
随后，根据不同的类型来决定如何显示：
Chunk 代码
如下是 Improving LlamaIndex’s Code Chunker by Cleaning Tree-Sitter CSTs 中的 TreeSitter 的使用方式：
度量体系设计
常用指标
代码接受率
AI 生成的代码被开发者接受的比例。
入库率
AI 生成的代码被开发者入库的比例。
开发者体验驱动
如微软和 GitHub 所构建的：DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity
评估数据集：HumanEval
模型选择与测试
在结合公开 API 的大语言模型之后，我们就可以构建基本的 IDE 功能。随后，应该进一步探索适合于内部的模型，以适合于组织内部的效果。
模型选择
现有的开源模型里采用 LLaMA 架构相对比较多，并且由于其模型的质量比较高，其生态也相对比较完善。因此，我们也采用 LLaMA 架构来构建，即：DeepSeek Coder。
OpenBayes 平台部署与测试
随后，我们需要部署模型，并提供一个对应的 API，这个 API 需要与我们的 IDE 接口保持一致。这里我们采用了 OpenBayes 平台来部署模型。详细见： 目录下的相关代码。
如下是适用于 OpenBayes 的代码，以在后台提供公网 API：
随后，在 IDE 插件中，我们就可以结合他们来测试功能。
大规模模型部署
结合模型量化技术，如 INT4，可以实现 6B 模型在消费级的显卡上进行本地部署。
（TODO)
模型微调
有监督微调（SFT）是指采用预先训练好的神经网络模型，并针对你自己的专门任务在少量的监督数据上对其进行重新训练的技术。
数据驱动的微调方法
结合 【SFT最佳实践 】中提供的权衡考虑：
样本数量少于 1000 且需注重基座模型的通用能力：优先考虑 LoRA。
如果特定任务数据样本较多且主要注重这些任务效果：使用 SFT。
如果希望结合两者优势：将特定任务的数据与通用任务数据进行混合配比后，再使用这些训练方法能得到更好的效果。
这就意味着：
通常来说，我们测试是结合 IDE 的功能，以及代码补全的功能，因此，我们需要合并两个数据集。
数据集构建
根据不同的模型，其所需要的指令也是不同的。如下是一个基于 DeepSeek + DeepSpeed 的数据集示例：
下面是 LLaMA 模型的数据集示例：
数据集构建
我们构建 Unit Eval 项目，以生成更适合于 AutoDev 的数据集。
代码补全。行内（Inline）、块内（InBlock）、块间（AfterBlock）三种场景。
单元测试生成。生成符合上下文的单元测试。
而为了提供 IDE 中的其他功能支持，我们结合了开源数据集，以及数据蒸馏的方式来构建数据集。
开源数据集
在 GitHub、HuggingFace 等平台上，有一些开源的数据集。
Magicoder: Source Code Is All You Need 中开源的两个数据集：
https://huggingface.co/datasets/ise-uiuc/Magicoder-OSS-Instruct-75K
https://huggingface.co/datasets/ise-uiuc/Magicoder-Evol-Instruct-110K
在 License 合适的情况下，我们可以直接使用这些数据集；在不合适的情况下，我们可以拿来做一些实验。
数据蒸馏
数据蒸馏。过去的定义是，即将大型真实数据集（训练集）作为输入，并输出一个小的合成蒸馏数据集。但是，我们要做的是直接用 OpenAI 这一类公开 API 的模型：
生成符合预期的数据集。
对数据集进行筛选，以保证数据集的质量。
对数据集进行扩充，以保证数据集的多样性。
对数据集进行标注，以保证数据集的可用性。
微调示例：OpenBayes + DeepSeek
在这里我们使用的是，以及 DeepSeek 官方提供的脚本来进行微调。
云 GPU： OpenBayes
GPU 算力：4090x2 （目测和微调参数有关，但是我试了几次 4090 还是不行）
微调脚本：https://github.com/deepseek-ai/DeepSeek-Coder
数据集：6000
我在 OpenBayes 上传了的 DeepSeek 模型：OpenBayes deepseek-coder-6.7b-instruct，你可以在创建时直接使用这个模型。
数据集信息
由 Unit Eval + OSS Instruct 数据集构建而来：
150 条补全（Inline，InBlock，AfterBlock）数据集。
150 条单元测试数据集。
3700 条 OSS Instruct 数据集。
而从结果来看，如何保持高质量的数据是最大的挑战。
测试视频：开源 AI 辅助编程方案：Unit Mesh 端到端打通 v0.0.1 版本
参数示例：
运行日志：
其它：
详细的 Notebook 见：code/finetune/finetune.ipynb
-
统一提示词（Prompt）。统一工具-微调-评估底层的提示词。
代码质量管道。诸如于代码复杂性、代码坏味道、测试坏味道、API 设计味道等。
可扩展的质量阈。自定义规则、自定义阈值、自定义质量类型等。
即要解决易于测试的数据集生成，以及易于评估的模型评估问题。
IDE 指令设计与演化
AutoDev 早期采用的是 OpenAI API，其模型能力较强，因此在指令设计上比较强大。而当我们需要微调里，我们需要更简单、易于区分的指令来构建。
模板指令
如下是在 AutoDev 中精简化后的 Prompt 示例：
其中包含了：
技术栈上下文
测试技术栈上下文
代码块（类、函数）的输入和输出信息
而这个模板指令，也是我们在 Unit Eval 中所采用的指令。
统一指令模板
为了实现统一的指令模板，我们引入了 Apache Velocity 模板引擎来实现，并通过 Chocolate Factory 实现底层的通用逻辑：
工具侧。在 IDE 插件中，直接通过 Velocity 模板引擎、基于 Chocolate Factory 来实现指令的生成。
数据集成。在 Unit Eval 中，生成适用于模板的数据集。
结果评估。基于 Chocolate Factory 的实现，对模板的结果进行评估。
高质量数据集生成
年初（2023 年 4 月），我们做了一系列的代码微调探索， 在那篇 《AI 研发提效的正确姿势：开源 LLM + LoRA 》里，企业应该开始着力于：
规范与流程标准化
工程化的数据准备
高质量的脱敏数据
代码复杂度。在当前的版本设计里，可以直接通过代码复杂度来决定是否放代码文件进入数据库。
不同的坏味道检查类型。诸如于代码坏味道、测试坏味道等。
特定的规则检查。Controller 的 API 设计、Repository 的 SQL 设计 等。
而基于 ArchGuard 中所提供的丰富代码质量和架构质量分析能力，诸如 OpenAPI、 SCA（软件依赖分析）能力，我们也在思考未来是否也加入相关的设计。
实现高质量数据集生成
如下是 Unit Eval 0.3.0 的主要代码逻辑：
随后是根据不同的质量门禁，来进行不同的质量检查：
在过虑之后，我们就可以由不同语言的 Worker 来进行处理，诸如 JavaWorker、PythonWorker 等。
根据用户选择的上下文策略，我们就可以构建出不同的上下文，如：相关上下文、相似上下文等
在上下文策略中检查代码质量
SimilarChunksStrategyBuilder 主要逻辑如下
使用配置中指定的规则检查以识别存在问题的数据结构。
收集所有具有相似数据结构的数据结构。
为每个被识别的数据结构中的函数构建完成生成器。
过滤掉具有空的前置和后置光标的完成生成器。
使用JavaSimilarChunker计算块补全的相似块。
为每个完成生成器创建SimilarChunkIns对象，包括语言、前置光标、相似块、后置光标、输出和类型的相关信息。
返回生成的SimilarChunkIns对象的列表。
在规则检查里，我们可以通过不同的规则来检查不同的代码质量问题，如：代码坏味道、测试坏味道、API 设计味道等。