跳到主要内容

AutoDev 本地智能体,你的 Agent 自由工坊

· 阅读需 6 分钟

当下大多数 AI 编程助手,无论是 Copilot、Cursor,还是各种类 AutoGPT 项目,本质上都存在一个问题:AI 编码助手只是更强的补全器, 而不是具备行为能力的开发者副手。它们擅长补全代码,但缺乏结构化任务理解、缺乏上下文感知,更无法根据开发者的意图自我组织多步行为。 更重要的是:它们是“别人造好的助手,而不是你能定义的工具

AutoDev 的本地智能体系统,从根本上改变了这个逻辑。

AutoDev 的新范式:Prompt 即 Agent,配置即能力链

AutoDev 推出的本地智能体系统以两个核心理念为基础:

  1. 智能体的结构可声明、能力可组合、行为可扩展
  2. 一句 Prompt + 一段配置,生成一个完全私有、本地可运行的 Agent 编码助手

其核心架构允许开发者:

  • 自定义 agent 的能力链(例如先读文件、再检索相关函数、然后写测试并提交)
  • 注入自己的提示词风格、子任务规划逻辑,甚至嵌入插件模块
  • 在本地选择任意大模型(如 Deepseek、Qwen、GLM)完成推理

你还可以定义它在 IDE 的交互方式、在命令行的交互方式,甚至在 @ 的交互方式:

  • actionLocation:IDE 中的交互位置,诸如 ContextMenu、CommitMenu、@mention 等
  • interaction:输出方式,诸如 AppendCursor、RightPanel 等。

✅ 示例配置:一分钟声明你的 Agent

如下,我们将创建一个用户选中需求后,可以用鼠标右键点击生成 Protobuf IDL 的智能体:

---
name: "Design Profobuf IDL"
actionLocation: ContextMenu
variables:
"spec": /any/ { thread(".devin/shell/fetch-teamai-spec.sh") | jsonpath("$.[1].content") }
onStreamingEnd: { parseCode | saveFile | openFile }
---

请根据用户的输入和规范,生成相应的 Proto 文件。

规范如下:

$spec

用户的需求是:$selection

只需这一段 YAML,AutoDev 就能生成一个理解团队协议规范的智能体:

  • 自动调用 fetch-teamai-spec.s 脚本获取需求规范
  • 注入上下文信息并结合用户选中需求
  • 自动生成符合要求的 .proto 文件并打开编辑

这种原子化能力封装 + 跨工具联动方式,大大拓展了 agent 的实用边界。

✅ 示例配置二:编排的数据库设计智能体

---
name: "设计数据库"
variables:
"story": /any/ { thread(".devin/shell/github-issue.curl.sh") | jsonpath("$.body") }
afterStreaming: {
case condition {
default { execute("gen-sql.devin", $story, $output) }
}
}
---

你是一位专业的数据库管理员。根据用户的需求,你应该在列表中为用户选择最佳的表。

— 用户使用数据库:$databaseInfo
- 用户表:$tables

例如:

- 问题(要求):按用户类型计算平均行程长度。用户表:trips, users, Subscriber_type *
- 你应该回答:[trips, Subscriber_type]

----

以下是用户需求:

$story

请为用户选择最佳的表,只需以列表形式返回表名,无需解释。

只需这一段配置,AutoDev 会自动生成:

  • 一个能够理解数据库结构并执行 SQL 生成的智能体
  • 完全根据用户输入的数据库表和需求动态生成查询
  • 将查询结果传入到下一个智能体(gen-sql.devin)进行处理

✅ 示例配置三:在聊天中生成代码

只需要在配置中添加 agentictrue 的值,并将 $selection 改为 $input 变量,AutoDev 就会自动将用户的输入传递给智能体:

---
name: "Design Profobuf IDL"
actionLocation: ContextMenu
variables:
"spec": /any/ { thread(".devin/shell/fetch-teamai-spec.sh") | jsonpath("$.[1].content") }
onStreamingEnd: { parseCode | saveFile | openFile }
agentic: true
---

请根据用户的输入和规范,生成相应的 Proto 文件。

规范如下:

$spec

用户的需求是:$input

总结:智能体的未来,是“开发者驱动”的自由工坊

AutoDev 本地智能体系统给开发者带来了真正的控制权。

  • 你定义行为,而不是接受行为
  • 你组合模块,而不是等待功能更新
  • 你掌控模型,而不是被平台绑定

每个开发者都应该拥有属于自己的 AI 编程助手,而不是为一个 “通用 Copilot” 妥协。

这,就是 AutoDev 想做的事。

📌 项目地址: https://github.com/unit-mesh/autodev 📚 文档 & 快速上手: https://ide.unitmesh.cc/docs

AutoDev 2.0 正式发布!智能体 x 开源生态 = 无限可能

· 阅读需 8 分钟

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

也可以 SettingsPluginsMarketplaceManage Plugin RepositoriesAdd,添加 https://plugin.unitmesh.cc/updatePlugins.xml 然后搜索 AutoDev 进行安装。

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

AutoDev Planner

· 阅读需 8 分钟

最近,我们在 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

AutoDev MCP

· 阅读需 7 分钟

在 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。

AutoDev Bridge

· 阅读需 7 分钟

在 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 理解当前系统的架构,我们面向架构视图设计了一系列的工具。

工具名称 (name)描述 (desc)
componentView列出当前项目的所有UI组件列表,如React、Vue组件
containerView列出当前项目的所有模块
webApiView列出当前项目的所有Web API
stylingView列出当前项目的所有CSS、SCSS类
dir获取当前层级的目录结构
history获取当前文件的历史提交信息
knowledge从 API 调用链进行分析,默认 depth = 2(不可修改),即 Controller 到 Repository 的调用链

注:显然 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

AutoDev Composer the Intellij IDEA Cursor Alternative

· 阅读需 4 分钟

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.

Agent Language - DevIns

· 阅读需 7 分钟

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

Introduction paragraph text here.

AutoDev 1.7.0 AutoDev AI Agent

· 阅读需 4 分钟

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

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

Introduction paragraph text here.

AutoDev 1.6.4 HarmonyOS 应用开发体验提升

· 阅读需 9 分钟

生成式 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、小程序应用迁移到鸿蒙应用的专家,所以还是有一系列的挑战。等我心情好的时候,再考虑写一些更好玩的新特性。