大型行业网站,wordpress搬家文章,抖音小程序在哪里找,怎么给网站做seo优化上周微软发布了自家的 AI 编程和软件开发智能体框架#xff1a;AutoDev#xff0c;其与我们开发的 IDE 插件 AutoDev 有颇多的相似之处#xff0c;特别是一些设计思路#xff0c;以及在对于辅助软件开发任务的智能体以及一些基础设施上。 稍有不同的是#xff1a; 交互介质… 上周微软发布了自家的 AI 编程和软件开发智能体框架AutoDev其与我们开发的 IDE 插件 AutoDev 有颇多的相似之处特别是一些设计思路以及在对于辅助软件开发任务的智能体以及一些基础设施上。 稍有不同的是 交互介质。我们的 AutoDev 构建基于 IDE API 体系构建的而微软的 AutoDev 则是构建以 CLI 为主。隔离环境。我们设计了 DevIns 语言来构建隔离环境而微软的 AutoDev 则是基于 Docker 隔离环境。 当危我们的 AutoDev 开发人数比较有限所以相比于微软的 AutoDev 成熟度上是相对比较低的。考虑到我们的 AutoDev 是一年前开源的而微软的 AutoDev 是最近发布的他们这取名有点不厚道。 AI 驱动软件开发的本质“人类—AI—代码”的桥梁 对于 AI 驱动的自动编程来说无非就是让 AI 能理解好人类的需求然后实现 AI 与代码环境的自动交互。更详细来说便是 人类通过自然语言或者交互描述软件开发任务如解释代码、生成代码、运行测试等。AI 结合智能体与上下文理解人类的需求并生成对应的指令文本。代码环境接收指令文本并执行对应的操作再返回结果给人类或者 AI。 也因此我们所要构建的上是一个基于 “人类—AI—代码环境” 的沟通桥梁。实现让 AI 能理解人类的需求并不是一件复杂的事情通过额外的需求澄清、展开 就有初步得到格式化后的需求。而让 AI 与代码环境进行交互则是一件更复杂的事情即如何通过指令文本来实现的。 方式 1基于文本的函数调用 函数调用Function calling可以让开发人员声名一系列的函数将其与对应的说明传递给语言模型让语言模型根据这些说明来生成格式化的结果。随后 在对应的工具中调用对应的 API 来实现对应的操作。诸如于 Google AI 中语言模型生成的返回结果示例 {functionCall: {name: find_theaters,args: {movie: Barbie,location: Mountain View, CA}}
} 相似的方式还有让 AI 生成对应的代码如 shell 等然后执行对应的代码。 方式 2语言抽象的开发环境 我们对于自动化的探索是来自于 AutoDev 第一个需求针对 Spring 框架的 AutoCRUD。在这个需求中我们发现在复杂的软件开发任务中需要动态生成 高质量上下文以让 AI 能在对应的问题域中生成对应的代码。诸如于生成 Controller 代码需要知道现有 Controller规范以及对应的 Service、Repository 等代码。这一系列的信息意味着我们需要一个更高级别的语言来描述这些信息。 随后我们在 AutoDev 中构建了一系列 Auto 功能针对 React 的 AutoPage、针对鸿蒙操作系统的 AutoArkUI 等以探索更合适的语言抽象来描述 “人类—AI—代码环境”即 DevIns 语言。通过语言来作为人机接口并作为可执行的代码来实现对代码环境的操作。诸如于 /patch
patch
// the patch to apply通过形式化的方式来描述对 IDE 的操作易于让 AI 理解也易于让代码环境执行。 设计基于 IDE 的编程智能体开发 在设计 AutoDev 的自动编码功能时我们依旧是按照在 Unit Mesh 架构范式下的设计思路来设计的 即 AI 生成的都是可验证的代码。也因此在我们设计 AutoDev 的自动测试功能时也是基于这个思路来设计的。当然了在有了 DevIns 语言后就能实现 更多的自动化理论上。 接下来让我们从实际的需求出发以三个例子来看看日常的编码可以如何设计 验证生成代码是否工作进行安全的代码信息提交探索自动化问题辅助修复 当然了还可以有更多的不同示例这里就不一一列举了。 示例步骤 1经验证可工作的代码 不论是人类还是 LLM要验证一段代码是否工作正确最简单的方式就是运行它。运行它通常有多种方式 直接启动应用。通用 IDE 或者 CLI 来启动应用程序通过交互界面或者 API 来验证代码的正确性。单元测试验证代码。即通过生成单元测试以验证生成业务代码的正确性。构建 REPL 环境。而交互环境对于复杂应用的依赖管理并非易事所以并非那么容易。 与启动应用的效率相比显然通过测试驱动开发TDD来验证代码的正确性更加高效。因此在结合 IDE 时则需要多考虑一步如何运行测试以验证代码。 于是我们设计了一个简单的测试运行指令 /run:src/test/java/cc/unitmesh/MathHelperTest.java 这样当我们生成了代码后便可以通过运行测试来验证代码的正确性。由于 Intellij IDEA 支持不同的语言但是不同的语言运行方式等是不同的。而由于 JetBrains IDE 使用了统一的底层抽象 RunConfiguration因此我们构建了一个 RunService 来封装不同语言的运行方式 interface RunService {fun createConfiguration(project: Project, virtualFile: VirtualFile): RunConfiguration? nullfun runFile(project: Project, virtualFile: VirtualFile): String? { }
} 更详细可以参见 RunService.kt 代码。 示例步骤 2安全的 Git 操作 既然我们生成了可验证的代码那么下一步我们应该考虑的是结合 VCS 来进行代码提交。为了确保不执行不安全的操作我们不直接执行 Git 操作而 是借助于 IDE 的 VCS API 来执行对应的操作。 于是我们设计了 /commit 指令来提交代码 /commit
commit
feat: add new feature而对于需要更复杂的场景诸如于远程生成的任务来说我们通过 /patch 指令来 示例步骤 3自动化问题辅助修复 接下来我们的挑战就是如何在 IDE 获取运行结果并根据结果来进行对应的操作。于是我们在 AutoDev 中设计了一个 DevInsProcessProcessor 来 处理 DevIns 指令的执行结果 when {event.exitCode 0 - {val comment lookupFlagComment(devInFile!!).firstOrNull() ?: return/// handle flag comments}event.exitCode ! 0 - {project.serviceDevInsConversationService().tryFixWithLlm(scriptPath)}
} 即 成功。当 exitCode 为 0 时我们可以通过 flag comments 来决定如何处理失败。当 exitCode 不为 0 如 -1时我们则可以继续通过 AI 来尝试修复对应的问题 在失败的场景时我们需要构建完整的上下文输入、编译输出、 执行结果/LLM 返回结果以便于 AI 能更好的理解问题再给出对应的修复方案。 更详细可以参见 DevInsProcessProcessor.kt 代码。 其它 我们依旧还在设计适用于 IDE 的自动开发框架与 DevIns 语言如果大家有兴趣可以参与到我们的开发中来。 GitHubhttps://github.com/unit-mesh/auto-dev
