太长不读性：

适用于 AutoDev 的编码大模型 AutoDev Coder 6.7B 第一个勉强可用的版本出来的。

• HuggingFace 首页：https://huggingface.co/unit-mesh （暂时没有资质提供直接下载，🐶🐶）。
• 数据集下载地址：https://huggingface.co/datasets/unit-mesh/autodev-datasets

PS：由于 AutoDev 1.5.1 在 JetBrains 市场等待审批，而老外们正在休完假，所以模型在 1.5.1 上的体验会比 1.5.0 略微好一点。

除此，在有了更好的算力支持，经过更好的补全测试之后，我们也会将原来的 Inlay 补全模式加回来。

AutoDev Coder 6.7B v1 试验版​

当前版本基于 LLaMA 架构下的 DeepSeek Coder 6.7b instruct 模型微调的。

注意事项：作为试验版，主要是为了磨合模型、数据工具与 IDE 插件，以达成更好的协调。因此，在生成质量还需要进一步提高。

AutoDev Coder 64k 数据集​

如下是 AutoDev Coder v1 64k 的指令组成：

其中的 summary.jsonl 是由我们开源的代码微调数据框架 UnitGen 生成（https://github.com/unit-mesh/unit-gen）。

我们挑选了几十个开源软件 Java 和 Kotlin 语言，根据 AutoDev 插件的指令生成，主要分为三类：

• 补全（行内、行间、块间）
• 文档生成
• 注释生成

详细说明可以见 UnitGen 项目和文档：https://github.com/unit-mesh/unit-gen。

FAQ：AutoDev Coder 模型评估​

暂时还在设计中。由于我们需要结合 AutoDev 指令与不同的语言如 Java、 Kotlin 、TypeScript 等语言，而非各种开源模型中喜欢用的 Python 体系，所以需要重新思考怎么设计。

我们前期采用 OSS Instruct 等指令集作为自然语言生成代码的补充，后来发现有一半的指令（～50，000 ）与 Python 相关，后来从中刷选出 Java 大概在 ~5，000 左右。在 AutoDev 中采用结果并不是很好。

FAQ：AutoDev 指令​

AutoDev 采用的是相关上下文策略，所以在指令上与其它工具有所差异。详细见：https://github.com/unit-mesh/auto-dev

在过去的两个月里，随着 Thoughtworks 内部的大规模 AI 辅助软件交付（AI4SoftwareDelivery）的展开 —— 在全球，有上千名的 Thoughtworker 这一个涉及不同角色、不同地区，以及几十场内部分享的活动。

我们也在 AutoDev 加入了更多的新特性，以持续探索如何在 IDE 里更好的协助团队进行提效。为此，作为目前国内最好的开源 AI 辅助编程工具，我们在 AutoDev 1.4.0 引入了几个比较有趣的特性，以探索规模化的 AI 研发提效。

AutoDev GitHub：https://github.com/unit-mesh/auto-dev

团队 Prompts：代码化 Prompt，以在团队扩散​

为了响应我同事们对于 TDD （测试驱动开发）的热情，即 #49 issue 中对于《支持TDD开发模式，根据指定测试生成对应实现》，我们构建了 Team Prompts 的功能。现在，你可以在你的代码库里，直接编写 Prompt，AutoDev 将读取您编写的 Prompt，并成为 AI 辅助功能的一部分。

这意味着：

• 您可以在团队里，共享你的 prompt，而不再是个性化的配置。
• 您组织里的不同团队，可以在各自的团队里分享自己的 AI 经验。
• 您不再需要定制更多的 IDE 需求，只需要提供接口能力即可。

Team Prompts 示例​

让我们来看一个简单的示例，首先你需要在你的代码库里创建（或者配置） Prompt 文件夹，然后使用编写你的一系列 Prompt，诸如于 TDD 里可以是：

• Tasking.vm，用于根据需求拆分出对应的测试用例。
• TDD-Red.vm，根据生成的测试用例，编写第一个失败的测试。
• TDD-Green.vm，根据生成的测试，编写、优化对应的实现代码。
• TDD-Refactor.vm，重构实现的代码。

在这些 prompt 文件里，只需要根据 AutoDev 的配置文件引入对应的上下文变量（参考：https://ide.unitmesh.cc/variables ） 即可。诸如：

---
priority: 2023
interaction: ChatPanel
---
```user```

你是一个资深的软件开发工程师，你擅长使用 TDD 的方式来开发软件，你需要根据新的测试用例，来改进原有的代码实现。

原有的实现代码是：$context.underTestFileCode($methodName)

新的测试代码是：

${selection}

请根据新的测试，优化 class under test 部分的代码。请返回对应的方法的代码，使用 ``` 开始你的代码块：

Prompt 开头的部分是一个 Markdown 的 YAML FrontMatter，用于做一些简单的配置，在这里的 priority 用于配置菜单中的优先级，interaction 即是用于配置交互方式，如：

• ChatPanel 用于直接输出在右侧的聊天窗口；
• AppendCursorStream 则是用 Stream （打字机效果）的方式在当前文档输出。

Context 则是内置的一些系统函数，用于提供额外的能力支持。

Team Prompts vs Custom Prompt​

在 AutoDev 1.1 中，我们提供了 Custom Prompt 的功能，它的主要意图是为个人提供一些个性化的配置，而 Team Prompts 则是针对于团队来提供团队统一的配置能力。

通过 Team Prompts 这样的方式，我们可以编写一系列适用于不同场景的 AI 指令，并快速分享给团队的所有人。

我们将持续演进 Team Prompts，以更方便地让大家使用。

自定义活文档：持续辅助遗留系统重构​

与普通的文档生成、注释生成相对，我们觉得从底层支持对于代码的注释生成，进而辅助系统进行重构显得更有意义。

AutoDev 文档生成​

在参考了 JetBrains AI Assistant 的文档生成思想之后，我们也在 AutoDev 中添加了文档生成这种聊胜于无的功能 —— 从个人角度而言，在有了 AIGC 之后，这种功能象征意义大于实际意义。直到我需要我为 Chocolate Factory 添加文档的时候，发现这个功能真好用。

没啥说的，选中一个类、方法、变量，右键一下，或者按一下 Alt + Enter 就可以生成了。如果原先的方法和类中已经有文档，那么将会根据现有的代码和文档重新生成（大概率，取决于 AI 的脾气了）。

如果您在实现的一个对外的 SDK，那么我更建议你采用我们在《* *开发者体验：探索与重塑**》中定义的《文档工程 》的方式。诸如于我们在 Chocolate Factory 中提供的，根据测试用例代码和注释来生成真正可靠的代码。

自定义活文档生成​

作为曾经的遗留系统重构专家，写过几个流行的重构工具、电子书，以及我们公司同事在大型保险公司的经历来看，直接根据代码生成注解形式的文档，可以大大节省阅读大量的成本。并且在已有的代码 + 新的文档的注释基础上，我们可以更好地构建 RAG 能力，进而快速从代码中梳理出真正有用的知识。

为此在 AutoDev 里，只需要添加一些 examples，就可以让 LLM 来生成对应的文档。示例：

"documentations": [
    {
        "title": "Living Documentation",
        "prompt": "编写 Living Documentation。按如下的格式返回：",
        "start": "",
        "end": "",
        "type": "annotated",
        "example": {
        "question": "...",
        "answer": "..."
    }
}

再根据不同的场景，生成对应的注解格式，所以你也可以用它来生成 Swagger 注解，这样就可以直接生成 API 文档了。

代码检视​

如我们在先前的文档《* AIGC 重塑软件工程 Code Review 篇* 》所介绍，我们是通过在 AutoDev 结合 DevOps 平台来共同完成代码检视的。

IDE 侧应该如何检视代码​

在 IDE 侧，我们更推荐的方式是理解业务场景，结合部分的语法问题进行 review。其主要原则是，从我们日常的工作习惯来说，我们会选取多次提交（诸如一个需求的所有代码提交），再进行 Code Review。又或者是单个文件在历史周期上的变化，所以我们在设计上也是围绕于日常的使用习惯来配置的。

结合需求系统的 Code Review​

对于考虑 AIGC 来进行研发提效的团队而言，大部分的团队已经具备了相当 DevOps 成熟度，诸如于在提交信息里结合需求 ID 来进行提交，诸如于 feat(devops): init first review command #8。

在这种场景之下，AutoDev 会根据这里的 8 去获取对应的需求系统的信息，以此作为业务上下文，来补充我们所需要的业务上下文，进而作为 LLM 的补充信息。

总结​

作为一个开源项目，我们依旧有大量地不足，如果你遇到什么问题，欢迎在 GitHub 提出 issue：https://github.com/unit-mesh/auto-dev 。

四月，在那篇《AutoDev：AI 突破研发效能，探索平台工程新机遇》，我们初步拟定了 AI 对于研发的影响。我们有了几个基本的假设：

• 中大型企业将至少拥有一个私有化的大语言模型。
• 只有构建端到端工具才能借助 AI 实现增质提效。

围绕于这些假设，我们开始构建 AutoDev，将并将它开源。也在我的博客里，写下开发中的所有心得，以期望能帮助到国内的企业构建自己的 AI 辅助编程能力。

作为一个开源项目，还是先上 GitHub 地址：https://github.com/unit-mesh/auto-dev 。

围绕开发者体验，设计三种辅助模式​

起初，我并没有一个明确的开发蓝图。作为一个天天写代码的、所谓的专家级程序员，我是看我缺什么功能便写什么功能。

随后，围绕于所有的功能，我将其总结为三种辅助模式：

• 聊天模式
• Copilot 模式
• 补全模式

自动模式：规范化的代码生成​

触发方式：自动模式都在 Context Actions 下，即与上下文相关的 actions。方式自然是那个那能的快捷键：⌥⏎ (macOS) 或者 * Alt+Enter* (Windows/Linux)。

设计的初衷是：类似于我们在先前设计 ClickPrompt 时的一键模式。而代码并不是像网的各种炫酷的 demo，你需要考虑团队已有的软件规范和约定，否则生成的代码依旧是不可用的。于是，围绕于可配置，以及一些隐性知识的场景，我们构建了三个体现 AutoDev 的 auto 的场景：

• 自动 CRUD。读取需求系统的需求，由一个手动编码的 agent，来不断进行交互。寻找合适的 controller，修改方法，添加新的方法等等。当前支持 Kotlin、JavaScript 语言。
• 自动生成测试。根据选定的类、方法，一键生成测试，并自动运行（在 RunConfiguration 合适的情况下）。当前支持 JavaScript、Kotlin、Java 语言。
• 自动代码补全。根据光标位置，自动进行代码填充。由于精力不够，在不同语言能力有些差异，在 Java 语言下，会结合读取代码规范；在 Kotlin、Java 语言会根据参数、返回值自动添加类作为上下文；在其它语言下，会通过“类似”（不要问是不是抄的）于 GitHub Copilot、JetBrains AI Assistant 的相似度算法进行计算。

每个自动模式都包含了一系列的自动上下文工作。如下图为可见的、自动代码补全的上下文示例：

在这个上下文里，结合了一些配置好的规范，以及 BlogController 类相关的 field、parameters、return type，诸如 BlogService 等。

除此，还有一些隐藏的上下文，诸如于，我们在 AutoDev 配置中声名的语言：

You MUST Use 中文 to return your answer !

所以，其实吧，因为只有这么两个 “中文”，目测有大概 50% 的机率不会触发，我在考虑要不要重复三遍。

伴随模式：围绕日常体验设计​

在设计伴随模式时，除了围绕于自己的需求设计，还调研、参考了一系列现有工具的实现，诸如于 AI Commit 等等。

由于，伴随模式都需要等待 LLM 返回结果，所以就都扔到 AutoDev Chat 模式下了。

不过，我现在发现了在 JetBrains AI Assistant 出来之后，它成了 AutoDev 的最大竞争对手，当然也是参考对象。诸如于，下图的 Explain with AI、Explain error message with AI 的体验就做得很好。在这一点上，确实有待我进一步学习的。

像 AutoDev，你只能选中，然后再 Fix This。

除了上述的功能，你还可以用 AutoDev 来：

• 生成提交信息
• 生成 release note
• 解释代码
• 重构代码
• …………

总之，别人有的，AutoDev 都可以有，还可以让你直接 create DDL。

聊天模式：一个边缘的功能​

在腾出了时间之后，我们重新设计（其实是借鉴了 JetBrains，谁让他不支持广大的中国区用户）了 AutoDev 的 UI，并且支持一键 Chat 的方式，如图一中的 Context Actions。

你可以在这里和它聊天。

LLM as Copilot 的思考​

对于现阶段来说，LLM 是一个 Copilot。它不会不改变软件工程的专业分工，但增强每个专业技术，基于AI的研发工具平台辅助工程师完成任务，影响个体工作。

它应该解决“我懒得做”及“我重复做”的事儿，诸如于写单元测试、编写代码、解决 issue、提交代码等等。作为一个程序员，我们应该多挖一些坑，多做一些有创造性的设计。

在 AutoDev 里，我们关注的是：AI 如何更好地辅助人类完成工作，并且它应该是伴随在工程师的 IDE 旅程上，尽可能让工程师不离开 IDE 就可以工作。

而对于 LLM as Copilot 这一理念来说，越来越多的工具将完善一点。

作为一个资深的 AI 应用工程师，我们正在思考 LLM as Co-Integrator 将如何真正的提升效能。

FAQ​

如何接入国产、私有化 LLM ？​

在项目的源码里，我们提供了一个 Custom LLM Server 的 Python 接口示例，需要将接口转为 AutoDev 所能接受的。由于精力有限，我只测试过公司内部部署的 ChatGLM2，所以接口并不是很完善。如果大家有其它需要，可以来 GitHub issue 讨论。

为什么只有 Intellij 版本？​

作为一个开发过新的语言插件、深入过 Intellij Community、Android Studio 源码，并且优化过 Harmony OS IDE 架构的人，我真的只擅长 JetBrains IDE 的开发。

什么时候会有 VS Code 版？​

简单来说：短期内不会有。

虽然，我也认真研究过 VS Code、X Editor 等编辑器的源码，但是兄弟姐妹们，VS Code 只是一个编辑器，不是一个 IDE 啊，它缺少太多的接口了。而如果只是简单的功能，现有的开源版本已经有很好的实现了。

除了上面的原因，还有：

其一：集成度低，开发困难。方式 1：VS Code 的 Tokenization 引擎是基于 TextMate 语法，那由 ****Oniguruma 结合又长又臭的正则表达式实现，非常不 靠谱；方式 2：基于 LSP 引擎，据我先前所试的，远景很美好。

其二：没有可供参考的代码和实现样板。如我们的 README 所提及：JetBrain plugin development is no walk in the park! Oops, we cheekily borrowed some code from the GitHub Copilot, JetBrains Community version and the super cool JetBrains AI Assistant plugin in our codebase. But fret not, we are working our magic to clean it up diligently!

所以，理想的方式是像 GitHub Copilot 一样，开发一套 IDE 无关的 Agent 机制，结合 TreeSitter 来实现编程语言相关的处理。

其它​

AutoDev 的思想是将 LLM（Large Language Model）作为辅助开发者的 Copilot，通过提供辅助工具来解决一些繁琐的任务，让工程师能够更专注于有创造性的设计和思考。

几个月前，我们朝着探索：**如何结合 AIGC 的研发效能提升的目标？**开源了 AutoDev，如 GitHub 所介绍的：

AutoDev 是一款基于 JetBrains IDE 的 LLM/AI 辅助编程插件。AutoDev 能够与您的需求管理系统（例如 Jira、Trello、Github Issue 等）直接对接。在 IDE 中，您只需简单点击，AutoDev 会根据您的需求自动为您生成代码。您所需做的，仅仅是对生成的代码进行质量检查。

随着，我们对于 LLM 能力边界的探索，发现了一些更有意思的模式，这些探索的模式也融入了 AutoDev 中。

PS：在 JetBrains 插件中搜索 AutoDev 并安装，配置上你的 LLM，如 OpenAI 及其智能体、开源 LLM 等即可使用。

WHY AutoDev？对于 GenAI + 软件研发结合的理解​

于生成式 AI 来说，我们依旧保持先前分享时相似的观点：

1. GenAI 可以在研发流程的几乎每个环节产生提效作用。
2. 对于标准化流程提效比较明显，不规范的小团队提升有限。
3. 由于 prompt 编写需要耗费时间，提效需要落地到工具上。

所以，在设计 AutoDev 时，我们的目标是：

1. 端到端集成，降低交互成本。即从 prompt 编写到与 LLM 交互，再复制回工具中。
2. 自动收集 prompt 的上下文生成内容、代码
3. 最后由人来修复 AI 生成的代码。

那么，手动整理规范、自动收集上下文，以提升生成内容的质量，便是我们做工具里所要探索的。

AutoDev 0.7 新特性​

从四月份的大 DEMO，到如今的新版本里，我们持续研究了 GitHub Copilot、JetBrains AI Assistant、Cursor、Bloop 等 IDE/编辑器的代码、实现逻辑等。每个工具都有其独特的卖点，再结合我日常的一引起开发习惯，添加了一系列探索性的新功能。

详细见 GitHub：https://github.com/unit-mesh/auto-dev

特性 1：架构规范与代码规范内建​

LLM 的复读机模式（生成机机制），会根据当前上下文的编程习惯，复读出相似的代码。即在使用诸如 GitHub Copilot 这一类的 AI 代码生成功能时，它会根据我们如何处理 API，来生成新的 API 代码。如果我们的代码使用了 Swagger 注解生成 API 代码，那么在同一个 Controller 下也会生成相似的代码。

这也意味着问题：如果前人写的代码是不规范的，那么生成的代码亦是不规范的。因此，我们在 AutoDev 添加了配置 CRUD 模板代码的规范：

{
  "spec": {
    "controller": "- 在 Controller 中使用 BeanUtils.copyProperties 进行 DTO 转换 Entity",
    "service": "- Service 层应该使用构造函数注入或者 setter 注入，不要使用 @Autowired 注解注入。",
    "entity": "- Entity 类应该使用 JPA 注解进行数据库映射",
    "repository": "- Repository 接口应该继承 JpaRepository 接口，以获得基本的 CRUD 操作",
    "ddl": "-  字段应该使用 NOT NULL 约束，确保数据的完整性"
  }
}

在一些特殊的场景下，只有这个规范是不够的，还需要配置示例代码。在有了这个配置之后，当我们在生成 Controller、Service 等代码时，可以直接用上述的规范生成。

特性 2：深入开发者日常编程活动​

在四月份发布的时候 ，AutoDev 集成了基本的编程活动能力：AI 填充代码、添加代码注释、重构代码、解释代码等等。

而在开发 AutoDev 自身功能的时候，我们发现了一些更有意思的需求，也集成到了 IDE 中。

• 一键生成提交信息。在我们使用 IDEA 的 UI 功能写提交信息时，可以一键生成参考的提交信息。
• 一键生成发布日志。在提交历史中，选中多个 commit，根据提交信息，来生成 CHANGELOG。
• 错误信息一键分析。编写代码时，DEBUG 遇到错误，选中错误信息，可以自动结合错误代码，发送给 LLM 进行分析。
• 代码测试代码。

再加上，AutoDev 最擅长的拉取需求进行自动 CRUD 的功能，在功能上更加完备了。

特性 3：多语言的 AI 辅助支持​

四月份，我们发现 LLM 非常擅长于 CRUD，所以选中了 Java 语言作为测试与场景，只构建了 Java 语言的自动 CRUD 功能。而像我最近几年经常用的 Kotlin、Rust、TypeScript，都没有支持，而这就对我不友好了。

于是，参考了 Intellij Rust 的模块化结构，重新组织了分层、模块，并以 Intellij Plugin 的扩展点 （XML + Java）重塑了整个应用的基础架构。

以下围绕新架构下产生的新扩展点：

• 语言数据结构扩展点。原先的设计中，这部分用于在 token 不够时，使用 UML 来表达原来的代码。随后，我们参考（抄袭）了 JetBrains AI Assistant 的语言扩展点功能，即不同的语言的数据结构在自身的扩展中实现。
• 语言 prompt 扩展点。不同语言也有自身的 prompt 差异，这些差异也被移到各自的模块中实现。
• 自定义 CRUD 工作流。现有的 CRUD 实现，绑定的是 Java 语言特性，而每个语言有自身的不同实现方式，也交由语言自身去实现。

当然了，当前依旧只有 Java/Kotlin 支持是最好的。

特征 4：更广泛的 LLM 支持​

AutoDev 在设计初衷面向我们的第二个假设是：每个大公司都会推出自己的 LLM。每个 LLM 都有自身的特点，所以我们需要有更多的 LLM 支持。

• OpenAI 及其智能体。目前是测试最多的，也是最完整的。
• Azure OpenAI。作为一个在国内合法使用 OpenAI 的渠道，我们也在先前的版本中进行了初步的支持，并逐步地完善了这个功能。
• 其它 LLM。虽然，还没有找到合适的国内 LLM API 进行适配，但是已经在接口上构建了这样的能力。

欢迎大家结合自己的 LLM 尝试。

特征 5：更智能的 prompt 策略​

回到我们 5 月份的那篇《**上下文工程：基于 Github Copilot 的实时能力分析与思考》**里，我们详细分析了 GitHub Copilot 的 prompt 策略。围绕于这个策略，会有基本的 promptElements 诸如：BeforeCursor, AfterCursor, SimilarFile, ImportedFile, LanguageMarker, PathMarker, RetrievalSnippet 等。

在发现了 JetBrains AI Assistant 也在尝试使用类似的方式来构建其 prompt 策略时。我们也进一步参考，并完善了 AutoDev 的 prompt 策略，以让其更智能。

• 代码上下文策略。
  • Java 语言 + CRUD 模式下，会尝试按相关代码（BeforeCursor）、调用代码的所有方法、调用代码行、相关代码的 UML 等方式构建。
  • Java 语言其它模式下，会使用 DtModel 来构建类 UML 的注释，作为相关任务的参考。
  • Python 语言，会根据 import 来相似代码段来构建生成 prompt 作为注释，作为 LLM 的参考。
• 计算策略。剩下的则是根据 token 是否超限，来不分配适合的上下文。

作为一个所谓的 “智能上下文” 策略，现有的策略还需要进一步优化。

其它​

有兴趣的话，欢迎来 GitHub 讨论代码：https://github.com/unit-mesh/auto-dev 。

围绕于探索 AI 对软件研发的影响，并在有了 LLM 微调工程化能力之后，我们上周末又开源了一个适用于 AI 研发提效的工具：AutoDev。如此一来，我们便构建了接近完整的 AI 在研发效能提升。

在这篇文章中，我们将基于 Unit Mesh、DevTi、AutoDev 等一系列的探索，分享 AI 对于研发效能的影响，以及对于平台工程带来的新机遇。

PS：整个体系站在一个基本假设是：中大型企业将至少拥有一个私有化的大语言模型。

GitHub： https://github.com/unit-mesh/auto-dev

引子 1：DevTi = 软件开发工程化 + LLM 微调​

DevTi（Development + Titanium）一款基于大语言模型的研发效能提升的开源项目。旨在基于 LLM 的微调来提供全面智能化解决方案，助力开发人员高效完成开发任务，以实现自动化用户任务拆解、用户故事生成、自动化代码生成、自动化测试生成等等。

简单来说，DevTi 是 AI + 研发效能领域的小模型的工具链 —— 借助于 DevTi，你可以快速训练出适用于软件研发的微调模型。一个简化的流程，如下图所示：

为了进行相关的模型微调或者训练，在其中的每一个阶段里，我们都需要准备数据、处理数据、生成 prompt 等，如准备一系列的用户故事、代码生成的数据。所以，作为工程师，需要准备一系列的编程基础设施或者模块。

DevTi 所包含的模块如下所示：

它包含了 4.5 个模块：

• Collector（Python, JavaScript），数据收集。这个模块负责从不同的数据源（如 GitHub、Stack Overflow、CodePen 等）收集代码片段、问题、答案等数据，以便用于微调。
• Processor（Kotlin），数据处理。这个模块负责对收集到的数据进行清洗、格式化、标注等预处理操作，以提高数据质量和一致性。
• Prompter（Python），Prompt 设计、调整、优化等。这个模块负责根据用户的需求和场景，设计合适的 Prompt 来引导大语言模型生成期望的输出，例如用户故事、代码片段、测试用例等。
• Train（Python），训练相关的 Notebook。这个模块包含了一些 Jupyter Notebook 文件，用于展示如何使用不同的大语言模型微调（如 ChatGLM、LLaMA等）来完成不同的研发任务，例如代码生成、代码补全、代码注释等。
• Chain。待定

随后，便可以围绕于 DevTi 构建工具链，如 IDE 工具、看板工具等等。

引子 2：AutoDev = IDE 插件 + AI API 调用​

AutoDev 是一款高度自动化的 AI 辅助编程工具。AutoDev 能够与您的需求管理系统（例如 Jira、Trello、Github Issue 等）直接对接。在 IDE 中，您只需简单点击，AutoDev 会根据您的需求自动为您生成代码。您所需做的，仅仅是对生成的代码进行质量检查。

简单来说，AutoDev 定位是适用于私有化大语言模型 + 高度集成的 AI 编程助手。AutoDev 提供了一种 AutoCRUD 模式，其设计理解的过程是：

1. 从需求管理系统获取需求，并进行需求分析。
2. 结合源码与需求系统，选择最适合变更的入口（如 Java 中的 Controller）
3. 将需求与 Controller 交给 AI 分析，以实现代码的代码。
4. 根据 Controller 逐步自动完成其它部分代码（实现中…）

另外一种模式则是普通的 Copilot 模式，可以接入现有的大模型工具，实现一系列的 AI 代码辅助相关功能。

GitHub： https://github.com/unit-mesh/auto-dev

接入 LLM，我们不仅可以生成代码，还可以生成单元测试代码，从而提高测试效率和覆盖率。

让我们再展开看一看，基于现有的 AI 能力，会有哪些新可能性。

平台工程的变化与新机遇​

而除了我们上述的 demo 之外，我们相信它带会其它带来一系列的变化。对于中大型组织的基础设施或者平台团队来说，要接入 AI 能力需要有更多的变化与机遇。

平台工程是一种用来构建和运维支持软件交付和生命周期管理的自助式内部开发者平台的机制和架构。平台工程可以提高开发者的体验和生产力，提供自动化的基础设施操作。平台工程是软件工程组织的新趋势，它可以优化开发者的工作流程，加速产品团队交付客户价值。

平台工程的核心思想是将平台视为一种产品，由专业的平台团队来创建和维护，为内部的客户（如开发者、数据科学家等）提供可复用的服务、组件和工具。

需求：自动化收敛、分析与完善​

在现有的场景之下，已经有一系列的关于结合 AI 进行需求管理的尝试：

• 自动化完善。对用户的反馈和数据的分析，自动识别和补充缺失的需求信息，例如自动识别用户提出的问题并转化为需求描述，自动补全需求的关键词和标签等。
• 自动化分析。通过训练自带的领域知识，可以更好地评估和优化需求，发现潜在的问题和机会，提高需求的效率和效果。
• 自动化收敛。结合其它 AI 技术，比如智能推荐、对话系统、多方协作等，可以帮助您更好地沟通和协调需求，收集和整合用户的反馈和痛点，提高需求的满意度和一致性。
• 自动化迭代。结合人类反馈的 AI 数据，可以更好地更新和改进需求生成，适应不断变化的环境和用户需求，提高需求的持续性和创新性

尽管现有的几个方案：LangChain、llama-index 等暂时只支持 OpenAI，但是随着更多开源大语言模型的加入，未来会更易于落地。

工具链：智能的 IDE​

对于现有的场景来说，已经相当的丰富，诸如于：

• 自动化代码审查
• 自动化测试
• 自动化日志分析
• AI 辅助编程
• ……

诚然，诸如于 GitHub Copilot 等收费 AI 工具来说，对于大部分公司来说，贵可能是其次，重点是代码的安全性。而虽然国内各类新的模型层出不穷，但是大部分缺少编程相关的集成，又或者是编程能力比较弱。然而，市面上也有只用于编程相关的模型，如 Salesforce 在 Hugging Face 上提供的 16B CodeGen 模型。虽然，还需要经过一些小的微调，但是如 Replit 公司所言，效果还是非常不错的。

随后，便是类似于 AutoDev 针对于大语言模型进行的封装，简化普通开发人员的开发过程。

文档：超越搜索​

在有了 LLM 和各种智能问答的基础上，我们还可以加入内部各种工具的文档和代码，以提供更全面、更智能的文档服务。例如，LangChain 构建的问答式文档，可以对企业内部的各种文档进行语义理解和智能问答，进而简化开发人员的学习成本。

其它​

AI 正在带来一系列的变化，特别是对于中大型企业的平台工程团队来说，接入 AI 能力需要有更多的变化与机遇。例如，可以自动化收敛、分析与完善需求，构建智能的IDE，提供更全面、更智能的文档服务等。

我们依旧在探索中，欢迎来加入我们。