PS：在我们等待了几个月之后，国内终于有模型（DS V3-0324）能支持 AutoDev 的能力，也因此是时候发布 AutoDev 2.0 了！

2023 年 4 月，我们开始了 AutoDev 的第一个功能：AutoCRUD，经过两年的快速迭代，我们干掉了这个功能。因为新的 AutoDev 2.0 来了，智能体 驱动的 AI 编程改变了我们过去的架构。在 AutoDev 2.0 中，你可以：

• 编码智能体 Sketch 进行自动化编程
• 自动化编程的规划器 AutoDev Planner
• 系统迁移 Bridge 辅助旧系统重构
• 观察者 Observer，动态观察 IDE 中的代码变化
• 模型协议 MCP 接入工具生态
• 在不同场景使用多种开源模型（编程、推理、Apply、补全等）
• ……

更棒的是 AutoDev 2.0 是开源的，你可以自由使用、修改、分享，让我们一起来探索这个无限可能的世界！与此同时，我们是最好的 JetBrains IDE 平台上的第二代 AI 编程工具，你可以尽情利用 JetBrains 的插件生态，让 AutoDev 2.0 更加强大！

编码智能体 Sketch​

我们开发 AutoDev 2.0 的动机来源于：DeepSeek V3 模型的推出。我们在 Shire 智能体语言上构建了 Sketch View，并率先将其应用到多文件编程支持。 随后，我们将其应用到 AutoDev 2.0 中，通过丰富的 IDEA 插件生态，来构建更好的 IDE 编程体验。

交互式决策视图：Sketch View​

Sketch View 提供了是一种新的交互式视图，它可以帮助你更好地理解架构、进行决策。Sketch View 的特点有：

• 交互式设计。多种化的 Patch/Diff 处理， 并针对生成代码进行 Lint 检查等
• 开发者体验。前端应用在启动 dev 服务时， 自动打开 WebView 查看编译正确
• 质量与安全。生成依赖文件时，可提供依赖的安全检查

并且，你还可以用它来查看代码的结构，以及更好地编写代码。

隔离环境的工具调用：DevIns​

我们在 AutoDev 1.0 中设计了 DevIns DSL 来构建隔离环境的指令抽象，基于 DevIns 指令，AutoDev 可以：

• 安全操作。对指令进行更安全的检查，诸如 Shell、SQL，而不是依赖于 LLM 的不靠谱分析。
• 模型无关。即可以在不同的模型上使用 CoT 来进行工具调用，而不依赖于 function tool。
• 关键上下文。即基于 IDE 的 PSI 接口丰富了语法分析计算与架构视图，提供系统的关键上下文。

同时，DevIns 能和 MCP 生态非常好的结合在一起，以便于更好地调用工具。

可见的任务规划：AutoDev Planner​

Planner 是 Sketch 的核心功能，它提供了一种新的任务规划体验。你可以通过 AutoDev Planner 来：

• 可见的任务规划。通过 Pin 及 Planner ToolWindow 的可以看到当前的任务进度
• 动态的任务规划。AI 会根据上下文动态调整任务规划（取决于模型，有时候并不会实时更新）
• 手动执行未完成的任务。用户可以手动执行未完成的任务，以便更好地调整任务规划

结合诸如于 DeepSeek R1 这一类推理模型，AutoDev Planner 可以更好地规划任务，以适应用户需求。

被动式错误观测：Observer​

Observer 是在 Sketch 中新增的一个功能，它可以帮助你更好地观察代码的变化。Observer 可以观察：

• 测试失败。当测试失败时，Observer 可以自动带上上下文（相关代码）发给模型
• 构建失败。当构建失败时，诸如 Gradle、Maven 的构建日志会被自动发送给模型
• 添加依赖失败。当添加依赖失败时，Observer 会自动将问题反馈给模型
• ……

通过被动式的错误观测，AutoDev 可以更好地理解代码的变化，以提升开发效率。

旧系统改造智能体：AutoDev Bridge（试验性）​

Bridge 是我们针对遗留系统迁移的一个新功能，它主要包括：

• 迁移路径。基于"探索-感知-响应"框架，通过大型语言模型智能生成系统迁移路径
• 架构视图。利用 AI 进行工具调用对现有系统进行深度扫描，生成符合C4模型标准的架构蓝图
• 业务逻辑分析。结合抽象语法树(AST)解析和运行时调用链追踪技术，实现业务逻辑的精准还原
• 执行迁移。生成包括单元测试、集成测试和端到端测试在内的多层次验证方案，确保迁移后系统功能完整性

作为一个试验性功能，AutoDev Bridge 并没有完全成熟，但是我们相信它会在未来的迁移中发挥重要作用。

DevOps 生态集成：双向 MCP​

MCP（模型上下文协议）是一个非常好的开放协议，它可以帮助 AI 智能体更好地理解上下文。在 AutoDev 2.0 中，我们将 MCP 与 JetBrains 插件生态 进行了双向集成，以便于更好地调用工具。

• MCP 即工具。通过 DevIns 指令对 MCP 进行封装，来调用第三方工具
• AutoDev 即服务。将 AutoDev 作为一个 MCP 服务，可以被任何 Agent Tool 调用

如此一来，将 AutoDev 与整个工具生态进行了无缝集成，丰富系统的上下文能力，降低幻觉的产生。

其它​

我们重新写了 UI 配图页面，详细参考新文档进行配置：https://ide.unitmesh.cc/quick-start

AutoDev 1.x 功能​

AutoDev 1.x 的功能依然保留，删除了一些用得比较少的功能，如 AutoCRUD。

工具问题依旧，效率真能提升吗？​

哪怕效率提升再多，效能提升依然有限。你们在写代码上的时间到底有多少？？？？？？？？？？？？

安装 AutoDev 2.0​

你可以通过 GitHub 来下载最新版本的 AutoDev 插件：https://github.com/unit-mesh/auto-dev 。

也可以 Settings → Plugins → Marketplace → Manage Plugin Repositories → Add，添加 https://plugin.unitmesh.cc/updatePlugins.xml 然后搜索 AutoDev 进行安装。

我们还在努力重新上架到 JetBrains 插件市场，但是你还可以通过下载源码来手动安装。

最近，我们在 AutoDev 上构建了新的功能：AutoDev Planner，它是一个基于 DeepSeek R1 推理模型构建的编码任务规划功能。当然了，除了 DeepSeek R1 之外，你也可以使用其它模型。

在 AutoDev Planner 中，AI 将会根据你的输入和收集的上下文，生成一个用于后续编码的任务计划。随后，这个编码计划可以用其它指令遵循更好的模型，比如 DeepSeek V3，来生成代码、编辑代码等。

引子 1：AI 编码任务的进度显性化​

在进行 AI 编码 Agent 的设计时，一个非常有意思的点是，用户对于编码任务的感知是怎样的，即用户应该能显性看到进度，还是隐性感知进度。

Copilot Workspace：早期的 AI 显性任务​

去年，我尝试使用 GitHub Copilot Workspace 来帮助我进行前端的开发工作。我尝试了几十个小的需求点，哪怕只是简单的 i18n 翻译，它的表现并没有 我想象中的那么好，大抵是受限于 GPT 4 的能力限制。而 Copilot Workspace 的思路确实非常不错：

• Brainstorm。对用户的 Task 进行头脑风暴（Brainstorm）
• Task。将 Task 转换为一个可编辑的 Plan
• Execute。执行 Plan，生成代码 Pull Request
• PR。将变更以 Pull Request 的形式提交

你可以显性看到 AI 思考、编辑、执行的过程，当然它没有动态的去调整他的计划，而是一次性生成（基于 2024 年的认知）。

Cursor：AI 隐性任务下的自动化重试​

回到，最近一年多特别火热的 AI 编码工具 Cursor，它构建了非常好的 AI Editor 体验，用户抛出一个问题。它会：

• 自动收集 IDE 中的上下文
• 对代码进行编辑
• 在代码出现 Lint 问题时，自动修复；在代码出现错误时，自动重试
• ……

你可以通过文字大概理解 AI 到底干了点什么，但是很快大量地重试，让你感知不到过程的存在。

JetBrains Junie：动态的 AI 任务规划​

JetBrains Junie 算是最新 AI 编码工具，它构建了一个动态的 AI 任务规划体验。用户抛出一个问题。它会：

• 结合分析问题，理解用户意图，生成一个任务计划
• 按步骤执行每个任务，并根据需求再获取上下文
• 在任务执行过程中，动态调整计划，以适应用户需求

在过程中，你可以看到它的计划在不断调整和迭代，直到最终完成用户的 issue 或者不能完成。

引子 2：推理模型规划任务的想象空间​

众所周知，2024 年底的推理模型或者说“可深度思考模型”，带来了更多的想象空间与可能性。我们在 AutoDev Sketch（类 Cursor Composer 自动编码 Agent） 中做了一系列的实验， 发现与其它的国内模型相比，DeepSeek R1 在相同上下文的情况下，比普通模型更容易生成更好的工具调用（ 基于DevIns 指令）。 与 DeepSeek V3 相比，DeepSeek R1 调用了更多的工具。

理想情况下，我们应该用 R1 进行首轮工具对话和第二轮的任务规划，但是 R1 的速度确实太慢了，从时间上来算相当于多调用了一轮 API。但是，依旧可以 看到 R1 的优势，相信大家也有相似的感受和体验。

当然我们没有做大规模的实验，毕竟构建非常好的测试数据集是特别花费时间的。

AutoDev Planner：Agent 编程的任务规划​

基于上述的思考，我们构建了新的拟人功能：AutoDev Planner 以强化 Sketch 的任务规划能力。AutoDev Planner 的核心功能是：

• 可见的任务规划。通过 Pin 及 Planner ToolWindow 的可以看到当前的任务进度
• 动态的任务规划。AI 会根据上下文动态调整任务规划（取决于模型，有时候并不会实时更新）
• 手动执行未完成的任务。用户可以手动执行未完成的任务，以便更好地调整任务规划
• 规划 Review。用户可以手动调用模型来 Review 任务规划（为什么不是自动的，因为 token 对普通用户来说是非常昂贵的）

总体思路还是非常简单的，就只是调用模型生成计划，然后展示这个交互。

关键点 1：基于推理模型的任务规划​

由于推理模型与普通的模型在理解 prompt 和遵循指令的能力是有差异的，我们原先用于 V3 的 prompt 并不适用于 R1。因此，我们需要重新设计 prompt 以适应 R1 的能力。

简单来说，就是当完成了初步的上下文收集之后， 而且用户配置了推理模型之后，我们会调用 R1 来生成一个任务计划。这个任务计划会包含：任务、步骤及 其相关的进度情况，随后我们会将这个计划展示给用户。

关键点 2：任务规划的可交互性​

与其它的 AI 编码工具不同，我们认为任务规划是一个非常重要的交互，因此我们提供了一些交互功能：

• 任务的状态显示：
  • 完成的任务将会被标记为完成
  • 未完成的任务可以手动执行
• Pin。用户可以将任务 Pin 到 IDE 的某个位置，以便更好地关注
• 文件交互。考虑到模型的能力，当文件出现在任务中，可以点击文件名打开文件
• 编辑。当用户觉得任务规划不合适时，可以暂停并及时调整任务。
• review。用户可以手动调用模型来 Review 任务规划

通过可视化任务来构建更好的 AI 编码体验，这是 AutoDev Planner 的初衷。

总结​

AutoDev Planner 是一个基于推理模型的任务规划功能，它可以帮助用户更好地理解 AI 编码任务的进度，以及更好地调整任务规划。当然，它还有很多不足之处， 欢迎在 GitHub 上提出 issue 和 PR。

欢迎下载最新版本体验：https://github.com/unit-mesh/auto-dev/releases

在 Agentic Coding 这一话题下，工具使用（Tool Use/Function calling）是一个非常有意思的话题。完成一个软件开发任务，需要使用到大量的工具， 除去在 IDE 及其插件生态本身提供的功能外，还会使用到大量的外部工具，如 Git、Docker、Kubernetes、Jenkins 等等。如何让 AI 知道更多工具的存在以及如何使用这些工具，是一个非常有意思的话题。

所以，我花了一天的时间在 AutoDev 中实现了相关的功能，即 AutoDev 作为一个 MCP 服务，可以被任何 Agent Tool 调用；AutoDev 作为一个 MCP 客户端，可以调用任何 MCP 服务。

引子 1：从渐进性 AI Agent 方案，到 AutoDev 即 MCP 服务​

在更庞大的 AI Agent 话题之下，比如自动化的 Computer Use 场景下，IDE 也只是一个可调用的 Agent 工具。从当前的 AI Agent 进度来看，现在的 Agent Tool 使用是一种渐进式的 AI Agent 方案 —— 毕竟写过 E2E 测试的同学都知道：操作 UI 的效率是非常之低的；以至于我们在编写 AutoDev 时，并没有写多少 UI 自动化测试。

我们现在考虑的 AI Coding 是以 IDE 为中心的，但是还存在一个场景是以 Agent Tool 为中心的。即：

• Agent 通过操纵 Browser 去获取需求信息；
• Agent 打开 IDE 去编写代码；
• Agent 打开 DevOps 工具去发布代码；
• ……

既然借助 Agent Tool 来调用工具是 2025 年的一个趋势，那么我们为什么不将 AutoDev 作为一个 MCP 服务呢？即 AutoDev 作为一个 MCP 服务，让任何 Agent Tool 都可以调用 AutoDev 的服务。哪怕是 Cursor、Cline、GitHub Copilot 等等，都可以调用 AutoDev 的服务，以获取 IDE 中的高质量上下文。

引子 2：从 MCP 即 Agent Tool 生态，到 MCP 服务即 AutoDev 指令​

在过去，我们在 AutoDev 中优先考虑的是借助 IDE 的生态，以及自身的插件体系，以实现 AI 更好的支持端到端的开发流程。但是，随着我们在 AutoDev 集成了更丰富的插件能力之后，我们依然需要大量的 Agent Tool。

Agent Tool 决定 AI IDE 的基线能力​

不可否认，在我们研究了大量的 AI Coding 工具之后，我们会发现，大量的 AI Editor 基于 VSCode 时在 tool 上提供的能力非常之相似，以至于我们 可以用一张图来描述它们的能力。但是，在 IDE 上的 AI Coding 插件则提供了更加丰富的能力，如 AST、Debug、FQN 查找等等。

典型的基于 VSCode 的 AI Coding 工具，提供了十个左右的工具，而基于 JetBrains 的 AI Coding 插件（如 AutoDev、JetBrains Junie）则提供了 20 个左右的工具，而这些只是基础的 IDE 上的能力。

而随着 AI Coding 进一步向需求、部署、运维等方向发展，相关的工具生态势必会更加丰富。

MCP 开源生态已经形成​

MCP（Model Context Protocol）是由 Anthropic 公司（Claude 模型） 推出的一个协议，它通过提供一种标准化的接口，LLM 应用可以访问外部信息、工具和资源。尽管我们在 AutoDev 提供了强大的自定义能力，诸如于 Custom Agent 等能力，但是：

• 有些工具是我们无法预知的，如某些公司内部的工具；
• MCP 等工具的生态是非常丰富的，并且正在成为一个标准。（尽管国内可能有一些不同）

但是，自打 Cursor、Cline 等编程工具引入了 MCP 之后，大量的 MCP 服务已经在国外形成了一个生态，特别是已经有了非常多的开源实现。

AutoDev x MCP：双向赋能​

基于上述的思考，我们基于 MCP 相关的插件（MCP Plugin）和生态（io.modelcontextprotocol），构建了 AutoDev x MCP 的双向赋能方案。即：

• AutoDev 作为一个 MCP 服务，可以被任何 Agent Tool 调用；
• AutoDev 作为一个 MCP 客户端，可以调用任何 MCP 服务。

通过这两种方式来沉淀我们在 MCP 方面的能力。

AutoDev 作为 MCP 服务端​

我们基于 JetBrains 的 MCP 方案，提供构建了 AutoDev 作为一个 MCP 服务的能力（注：需要在配置中开启 MCP 能力）。你只需要通过 JSON 来配置即可 ，如下是 Cline 插件中的配置示例：

{
  "mcpServers": {
    "AutoDev": {
      "command": "npx",
      "args": [
        "-y",
        "@jetbrains/mcp-proxy"
      ],
      "disabled": false,
      "autoApprove": []
    }
  }
}

在当前的版本里，我们只基于官方提供的能力，加了一些数据库相关的能力，其它能力需要等有合适的国产 MCP 服务后再进行扩展。

AutoDev 作为 MCP 客户端​

相似的，你需要在 AutoDev 的 Custom Agent 页面配置相关的 MCP 服务，如下是 MCP 官方提供的示例

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Volumes/source/ai/auto-dev"
      ]
    }
  }
}

随后，这个 MCP 服务提供的工具，就可以在 AutoDev 中被调用了。如下是转换为 DevIns 后的示例：

/list_directory

{
 "path": "/Volumes/source/ai/autocrud/docs/mcp"
}

现在，借助于强大的 AutoDev DevIns Command，你可以在 AutoDev 中调用任何 MCP 服务，当然 Agent 也是可以的。

其它​

人生苦短，我有 AI。

• 详细文档见：https://ide.unitmesh.cc/mcp
• 欢迎下载和使用最新版本 AutoDev（v2.0.0-rc.2）进行体验。下载地址：https://github.com/unit-mesh/auto-dev/releases/tag/v2.0.0-rc.2

在 2023 年，基于当时的模型能力有限，我们在 AutoDev 设计了一系列的遗留系统功能的特性。而在 2025 年，经过自动编程智能体 AutoDev Sketch 的一系列 迭代，我们开始思考如何将 AI 智能体应用到遗留系统中，便产生了 AutoDev Bridge 这个想法。

为什么大模型能做得更好？​

过去，我们公司 Thoughtworks 在这方面有非常多的积累，包括从迁移策略的设计、安全防护网的搭建等等，但是不论哪种迁移模型（绞杀者、修缮者等）最后 都是需要人工介入的。而在 2025 年，已经有越来越多的 AI 智能体能够做到自动化迁移，因此我们进一步完善了我们的开源方案。

在遗留系统迁移上，为什么大模型能做得更好呢？

• 设计合理的路径规划。通常来说，优先基于成本考虑，而大模型作为一个知识库，能非常好的给你成本评估。
• 生成架构蓝图。结合目录结构、依赖信息、API，AI 能针对于当前系统描绘出初步的架构蓝图。
• 提炼代码中的业务知识。结合 AST 等，分析现有代码的业务逻辑，再基于其重写。
• 跨语言翻译。与生成代码不同的是，LLM 能非常好的将其翻译成目标语言，只需要几十秒到几分钟的时间。
• 迁移防护网的增强。即生成自动化测试来验证迁移的正确性，实现实现精准回归测试。（注：在前端依然有所不足）
• ……

所以，我们只需要思考两件事：

• 如何让 AI 能借助工具更好地理解遗留系统？
• 如何借助降低迁移的风险？

AutoDev Bridge 如何加速老旧系统迁移？​

基于对遗留系统迁移的理解，我们设计了 AutoDev Bridge 的初步方案。它主要包括：

• LLM 生成的迁移方案。（基于“探索-感知-响应”方案）
• 基于 C4 的当前架构现状分析。（基于 AI 工具调用）
• 结合 AST 与调用链的业务逻辑分析。（AI 理解代码）
• 生成迁移测试用例。
• AI 辅助的代码翻译。
• ……

借助与 IDE 的紧密集成，AutoDev Bridge 能获得非常准确的 IDE 上下文，以进一步降低 AI 幻觉的产生。

探索-感知-响应：LLM 生成的迁移方案​

在过去，我们将遗留系统迁移定义为 Cynefin 中的复杂问题，即你无法预测结果，只能通过实践来发现。于是乎，我们参考了 Cynefin 的思想，设计了现有的 AutoDev Bridge 的思维框架，即你要先探索、再感知、再响应。由于，我们预期的是模型在行动前是需要有一个蓝图（C4 模型），所以我们将这个过程分为三个阶段：

• 探索：通过初步调用工具，获取系统的基本信息，如目录结构、依赖关系等。
• 感知：基于探索的结果，生成初步的架构蓝图、迁移方案。
• 响应：进行迁移方案的验证、生成迁移测试用例、生成迁移代码。

落地到国内的模型能力下，就会由由 V3 来进行探索，R1 进行方案设计，由 V3 进行响应。

面向架构视图的工具设计​

为了更好让 AI 理解当前系统的架构，我们面向架构视图设计了一系列的工具。

注：显然 DeepSeek 不能很好理解 C4 模型，还需要进一步的优化。

业务知识提取与理解​

在业务逻辑分析中，我们主要是基于 API 的 AST 与调用链的业务逻辑分析。即先通过 webApiView 获取所有的 API，再通过 knowledge 获取 API 的调用链。 如：

/knowledge:GET#/api/blog/*

在有了从 Controller 到 Repository 的调用链后，AI 就可以非常好地理解当前 API 的业务逻辑。

当然，这只是一个简单的示例，实际上，AI 还需要结合搜索等工具，进一步获得更多的上下文。

总结​

随着，我们研究的进一步深入，我们会逐步完善这个方案，以实现更好的自动化迁移。

欢迎在 GitHub 上持续关注我们：https://github.com/unit-mesh/auto-dev

A little over two weeks ago, after the release of DeepSeek V3, we introduced multi-file editing capabilities for Shire.

Following extensive testing, we discovered that DeepSeek V3 performs exceptionally well in programming scenarios, especially in multi-file editing contexts.

This inspired us to add a new feature—AutoDev Composer—to AutoDev, which had long lacked major updates. In developing this feature, we drew inspiration from a number of mature tools:

• The impressive Sketch rendering mechanism on Shire
• Complex system prompts from tools like Cursor and WindSurf
• The bug-ridden StreamDiff mode from Continue
• …and more

Now, there’s no need to switch to a VSCode-like IDE to craft prompts and then return to IntelliJ IDEA for debugging. With AutoDev Composer, you can handle everything directly within IntelliJ IDEA.

As an amateur project, we’ve put in a lot of effort to make this happen! 😊

Introduction paragraph text here.

在上一个版本中，我们构建了 AutoDev 的自定义 Agent 功能，即用户可以通过自定义能力来构建自己的智能体，以实现对于软件开发任务的智能辅助。 而在这个版本中，我们开始构建一个新的 AI Agent 语言：DevIns，即 Development Instruction。即 DevIns 可以让用户更快速描述软件开发任务， 同时，还可以自动化处理来自 AI Agent 返回的内容。

Introduction paragraph text here.

在开源 AI IDE 插件 AutoDev 的 #51 issue 中，我们设计了 AutoDev 的 AI Agent 能力，半年后我们终于交付了这个功能。

在 AutoDev 1.7.0 中，你将可以接入内部的 AI Agent，并将其无缝与现有的 AI 辅助能力结合在一起。

Introduction paragraph text here.

生成式 AI 在软件研发和知识管理上，有着非常大的潜力，也因此这项技术被越来越多的企业所采用。而在一些新兴的技术上，诸如于鸿蒙操作系统，它带来了一些新 的理念、开发工具 DevEco Studio、新的语言 ArkTS、新的 UI 框架 ArkUI 等等。从模式上来说，它与生成式 AI 结合企业内部的基础设施过程非常相似。

因此，我们开始在 AutoDev 中探索如何结合这些新知识的可能性，同时降低开发人员的学习负担。

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

鸿蒙操作系统 + 生成式 AI 的三个试验式功能​

在初步听鸿蒙团队介绍完 HarmonyOS 的一些自研工具之后，便有了三个在 AutoDev 试验的思路：

• 添加 ArkTS 支持。ArkTS 是鸿蒙生态中基于 TypeScript 扩展的应用开发语言。
• 自动 ArkUI 页面生成。ArkUI 是一套构建分布式应用界面的声明式 UI 开发框架。它与我们先前引入的 AutoPage 并没有太多的区别，可以结合思维链进行代码和 UI 生成。
• UI 布局迁移。即将其它语言、框架编写的代码，交由生成式 AI 转化成适用于鸿蒙的代码。

作为阅读过 Gradle、Intellij Community、DevEcoStudio 源码，以及《前端架构：从入门到微前端》作者，我大抵算是对于 TypeScript、 ArkUI、 声明式 UI 有一定的经验，所以我自信的开始了 AutoDev 的新功能开发 —— 然后就踩了一堆坑。

1. ArkTS 语言的 AI 支持​

在我下载安装完 DevEco Studio 之后，发现 AutoDev 居然不支持 TypeScript？？？经过我在 WebStorm 反复测试后，发现是 IDE 的关系。结合 PSIViewer 插件后， 才发现差异之后，DevEco Studio 的 JavaScript/TypeScript 语言是自己实现的，诸如于：com.huawei.ace.language.psi.impl.JavaScriptIdentifierNameImpl。

原因不外乎：

• Intellij 平台中的 JavaScript 插件是收费的，没有开源版本。
• 鸿蒙直接针对于 TypeScript 语法进行扩展，会比实现一个新的更简单。

所以 DevEco Studio 自研了一个 JavaScript/TypeScript 模块，支持 JavaScript 语法高亮、代码提示、代码格式化等功能。与此同时，DevEco Studio 添加了 ArkTS 语言，即 TypeScript 扩展语法。

这就意味着，使用 DevEco Studio + AutoDev 时，会出现三种新的文件类型：

• Huawei JavaScript
• Huawei TypeScript
• Huawei ArkTS

头疼。。

为此，在 AutoDev 中采取的方法是，其于标准 PSI 做初步的抽象，以实现对于文档生成的支持。而如果要做好则需要：

1. 基于反射来重复利用 JavaScript PSI
2. 融入 DevEco Studio 的 JavaScript 支持

当然，考虑到调试上的难度，以前代码中各种现的 xxStudio 字眼（新的自研 IDE 平台？？），我暂时放弃了上述的做法：大体上鸿蒙 IDE 会有自己的 AI 能力。

2. AutoArkUI：RAG 增强的 ArkUI 代码生成​

ArkUI 是一套构建分布式应用界面的声明式 UI 开发框架。

与 ArkTS 相比，要结合 ArkUI 显得稍微复杂一些。 所以，我在当前版本里考虑的是：结合经典 UI 的元素生成页面，即：

• 布局。诸如于：线性布局（Row、Column）、层叠布局（Stack）、弹性布局（Flex）等。
• 组件。诸如于：按钮（Button）、单选框（Radio）、切换按钮（Toggle）等。

而由于 ChatGPT 是不包含 HarmonyOS 的最新知识的，所以需要采用类似于 AutoPage 的两步生成特性。

1. 分析用户的需求，选择合适的布局与组件。
2. 根据用户的需求与详细的布局、组件信息，生成对应的 ArkUI 代码。

上述的两步便是 AutoDev 中 AutoArkUi 生成 UI 的特性，详细可以参考 AutoDev 的代码，以及对应的 prompt。如下是对应的步骤 1 的 prompt：

• User: // maybe send Android Layout code, maybe some requirements
• Your Answer: [FlexLayout, Button, CheckBox, Checkbox, Button]

考虑到编程语言 DSL（领域特定语言）极易受用户语言的影响，所以采用的是英语的方式，避免无端生成中文 DSL 。

3. 迁移 Android/iOS/小程序 应用​

生成式 AI 具备极好的代码翻译能力。诸如于 IBM 在 Cobol 转化为 Java 上的工程化设计，以及我们在 AutoDev 中设计的遗留系统改造能力，其所针对的 都是生成 AI 在这方面的能力。

所以，我们也在 AutoDev 中内置了这个功能，只是当前支持的只是布局上的迁移。但是，考虑到这种生成方式依旧有一系列的问题，有待我们进一步寻找更好的方式。 类似的问题在生成 ArkUI 也是存在的。

相似的，这个功能目前是与 AutoArkUI 融合在一起的，理论上通过静态代码分析是最简单的，有待未来进一步完善。

4. RAG 增强的聊天上下文：C++ NAPI 等​

在试验了多次之后，会发现对于 HarmonyOS 这种新知识，ChatGPT 是不知道的。所以，需要基于 AutoDev 的上下文接口，创建基于 HarmonyOS 的上下文。 当然的版本（1.6.4）里， 添加的是：This project is a HarmonyOS project. （毫无意义的废话），再结合不同语言来写一些上下文：

• TypeScript/JavaScript/ArkTS. Which use TypeScript (ArkTS) as the main language, and use Flutter like TypeScript UI framework.
• CPP/"C/C++"/CCE. Which use C++ as the main language, and NAPI for building native Addons.

大体来说，就是告诉 AI：

• 编写 ArkUI/前端代码的时候，考虑一下这个项目是类似于 Flutter 的声明式 UI 。
• 编写原生代码的时候，考虑一下这个项目是基于 NAPI 来构建插件的。

当然了，这些是基于我的初步理解所构建的上下文，

未来​

考虑到上述的功能，就是几小时内实现的，就不要有太高的期望了。

当前版本依旧有诸多问题：

• 转换 Android 布局易瞎编。除了需要知道更多的转换规则，还需要知识更多的属性，而这些部分是通过传统的代码分析工具解决的
• 组件和布局信息的 hardcode。懂的都懂
• 缺少示例代码。没有动态生成的示例代码，使得 RAG 的效果是有限的
• 诸如于 C++ 语言的支持
• 微信小程序等小程序平台的转换

然而我并非 Android、小程序应用迁移到鸿蒙应用的专家，所以还是有一系列的挑战。等我心情好的时候，再考虑写一些更好玩的新特性。

Introduction paragraph text here.

去年年初，我们开源 AutoDev 的初衷是：

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

而今我们在朝这一目标的努力又更进一步了：一键生成精准的单元测试。在这篇文章中，我们将介绍从 1.4 版本（适用于团队的 Team AI）到 1.5.3 版本的一些特性：

• 精准的自动化测试生成。增强了静态代码分析能力，使得生成的构造函数更加准确；优化针对于 Spring 项目区分如何测试 Controller、Service 的 prompt；提供不同类型的测试模板能力。
• 本地模型强化。提供了适合于 AutoDev 的 AutoDev Coder 数据集与模型；支持本地的数据记录功能，方便于进行数据蒸馏；支持部分的系统 prompt 覆盖，即你可以更好的使用自己的模型。
• 多语言注释文档。新增 JavaScript、Rust、 Python 语言的支持，并且优化了 Kotlin 的文档生成逻辑。
• 自动流程优化。添加了 PrePush Review，即在 commit 之前，你可以使用 AI 来 review；大大简化提交信息生成的上下文，区分文件变更、依赖变更等场景，使生成的 token 更少。

欢迎来加入我们：https://github.com/unit-mesh/auto-dev/，构建自己的 AI 辅助全流程编码助手。

在开发的过程中，我们选取了 ArchGuard 作为 AutoDev 全流程 AI 辅助的试点，ArchGuard 是一个使用 Kotlin 编写的开源架构治理平台。在过程中持续积累数据和经验，以更好地支撑 Kotlin 语言的使用体验。

1. 精准测试生成​

结合在 ArchGuard 项目中生成了 90 个测试类 200+ 测试的用例经验，我们持续优化了的测试生成逻辑（估计还有一些 bug）。

因此，在 AutoDev 中有概率直接生成直接可用的单元测试。

精准上下文​

在当前的版本里，测试的上下文除了会包含相关的类信息，还有完整的输入和输出类信息。即通过静态代码分析，获取 Service 相关的信息，也会获取每个函数的输入和输出等等信息。当一个被测试类是一个 Spring 相关的类，会判断是否是 Controller 和 Service，再给定一些测试规则。

代码实现参考 JavaTestContextProvider、KotlinTestContextProvider 的实现。

单元测试模板：团队 AI​

在 ArchGuard 中，由于不可知的历史原因，需要编写一些特殊的注解 —— 而模型并非每次都能生成想要的。考虑到，这样的情况也会出现在大部分的项目中。因此，针对于 Controller 和 Service 与其它测试，你可以自定义单元测试的模板。

每个项目的测试逻辑是不一样的，加上我们推荐采用 prompt 即代码的方式来管理，你更可以将它分享给你的团队。

相关文档：https://ide.unitmesh.cc/customize/custom-test-template.html 。

API 测试数据精准生成​

相似的，在使用 AutoDev 的 API 测试数据生成功能时，我们也结合静态代码分析优化了对应的上下文能力，可以直接生成可用的测试数据。

详细见：JavaTestDataBuilder 和 KotlinTestDataBuilder 相关实现。

2. 针对本地模型优化​

现在，只需要通过打开 AutoDev 配置页的 AutoDev Coder ，你可以针对私有化的模型做更多的配置。

公开模型数据的蒸馏​

为了更好的测试公开的大语言模型，以及进行内部模型与工具的适配。我们在新版本中添加了 Recording Instruction In Local 的功能，即您可以记录与 AI 交互的数据，并以此作为内部模型微调与评估的样本。

同时，还方便于进行对应的 AutoDev Debug。

插件 prompt 覆盖​

通过配置页，同样可以配置诸如Explain code、Refactor code、Fix issue、Generate test四个基本的 AutoDev Chat 相关的 prompt。

在进一步优化和构建内部的上下文之后，也将使用模板的方式释放出更多上下文接口。

3. 多语言文档​

在文档上，现在可以支持 Python、 Rust、 JavaScript 语言的注释文档生成。同时，由于 OpenAI 经常为 Kotlin 类生成无用的函数注释，我们也针对这个功能进行了优化，只选取类前的注释代码。

4. 自动流程优化​

自动化是 AutoDev 追求的主要特性，我们也在今年针对于日常开发流程初了更多的设计。在这个版本里，主要提供两个新特性。

PrePush 检视​

即在代码提交前，你可以让 AI 来辅助你进行一些初步的 review，以避免出现一些不必要的错误。

更流畅的提交信息生成​

在 ArchGuard 项目中使用 AutoDev 重构时，我们生成了 167 次的提交信息，占所有功能的 1/3 。也因此，我们花了更多的时间在生成更好的提交信息上 —— 如何更好地控制 token。

其它​

未来我们还将关注于：

• 流程自动化的强化。即支持更好的向前和向后流程接入，加速开发人员的编码速度。
• 交互体验优化。我们已经在代码库中引入了更好的加载和出错显示，未来也将持续丰富，毕竟没有 UX，交互上都是靠抄。
• 测试覆盖率的提升。在过去的一段时间里，由于 UI 测试速度缓慢，并且在 IDE 架构复杂，AutoDev 的测试覆盖率是相对较低。而在静态分析相关的场景，则需要进行充分的测试，所以我们在为 AutoDev 添加更多的单元测试，以使得它更加稳定。

如果你也有兴趣，欢迎来挖坑：https://github.com/unit-mesh/auto-dev/ 。