稍有不同的是：
交互介质。我们的 AutoDev 构建基于 IDE API 体系构建的，而微软的 AutoDev 则是构建以 CLI 为主。隔离环境。我们设计了 DevIns 措辞来构建隔离环境，而微软的 AutoDev 则是基于 Docker 隔离环境。当危，我们的 AutoDev 开拓人数比较有限，以是比较于微软的 AutoDev 成熟度上是相比拟较低的。考虑到我们的 AutoDev 是一年前开源的，而微软的 AutoDev 是最近发布的，他们这取名有点不厚道。
AI 驱动软件开拓的实质：“人类—AI—代码”的桥梁对付 AI 驱动的自动编程来说，无非便是让 AI 能理解年夜大好人类的需求，然后实现 AI 与代码环境的自动交互。更详细来说，便是：
人类通过自然措辞或者交互描述软件开拓任务，如阐明代码、天生代码、运行测试等。AI 结合智能体与高下文理解人类的需求，并天生对应的指令文本。代码环境吸收指令文本，并实行对应的操作，再返回结果给人类或者 AI。也因此，我们所要构建的上是一个基于 “人类—AI—代码环境” 的沟通桥梁。实现让 AI 能理解人类的需求，并不是一件繁芜的事情，通过额外的需求澄清、展开， 就有初步得到格式化后的需求。而让 AI 与代码环境进行交互，则是一件更繁芜的事情，即如何通过指令文本来实现的。
函数调用（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```commitfeat: 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.service<DevInsConversationService>().tryFixWithLlm(scriptPath) } }
即：
成功。当 exitCode 为 0 时，我们可以通过 flag comments 来决定如何处理失落败。当 exitCode 不为 0 （如 -1）时，我们则可以连续通过 AI 来考试测验修复对应的问题在失落败的场景时，我们须要构建完全的高下文：输入、编译输出、 实行结果/LLM 返回结果，以便于 AI 能更好的理解问题，再给出对应的修复方案。
更详细可以拜会 DevInsProcessProcessor.kt 代码。
其它我们依旧还在设计适用于 IDE 的自动开拓框架与 DevIns 措辞，如果大家有兴趣，可以参与到我们的开拓中来。
GitHub：https://github.com/unit-mesh/auto-dev