0


AutoDev 1.8 融合 DevOps 规范和实践,构建演进式 AI 辅助编码

在新版本的 AutoDev 中,我们又融入了一系列软件开发的实践,以更好地辅助开发人员的日常工作。这些新的特性,融合了我们对于 AI 辅助编码的新理解。诸如于:

  • 重构:AI 重命名、坏味道重构、重构建议。
  • 提交信息优化:结合用户输入的,提交信息生成
  • CLI 生成:结合用户输入的,生成 CLI 命令

还要最重要的中文 prompt 支持 —— 以更好地适应国内的模型和开发习惯,以及一系列的 bugfix 和新特性。

演进式 AI 辅助编码

生成式 AI 辅助编码的两条技术路线是:重新生成还是代码变更。Unit Mesh 是我们设计的 AI 编码的重新生成架构范式,当来了新需求时,每次都生成新的代码。哪怕是重新生成的效果再好,也受限于生成式 AI 的能力。因此,在实际落地的过程中,AutoDev 这样的辅助代码变更工具,才是当前适合于我们的演进路径。

acc962cfa06accc90a61fe08977f6edb.png

代码变更,意味着我们需要人类和 AI 能理解现有的代码,以做出合适的决策建议。而如果我们预期 AI 能理解代码、需求,并编写出规范化的代码, 就依赖于我们构建了研发的知识工程体系。两个典型的场景是:现有需求总结和重构。

  • 现有需求总结。理解用户输入,检索到对应的现有代码实现逻辑,由AI 来总结已有的逻辑实现
  • 重构。AI 重构的难度介于自动生成代码与架构设计之间,是一个非常不错的探索场景。

尽管结合 RAG 技术,可以提供足够没用的信息,以生成可能更适用用户意图的信息,但是并不适合开发人员的日常高频场景上使用。因此,如何在 AI 辅助工具中构建规范与最佳实践,并内建软件开发知识工程,以拉升基线水平是一个非常有意思的挑战。

引子 1:如何让 AI 更好地重构出理想的代码?

如果你探索过使用 AI 来构建代码时,你会发现:AI 懂的重构手法你都懂,但是看别人使用 AI 重构似乎非常顺手。这是为什么呢?重构通常依赖于好的上下文,即需要开发人员拥有大量的先验经验。简单来说就是:表达意图与构建意图所有的上下文

78cb4ff520abd91675b58d04b980aa80.png

简单来说,当你缺少一个代码改进的方向时,无法给 AI 一个明确的意图,剩下的就要靠 AI 随机了 —— 因此,大部分情况下,AI 只是进行简单的重命名、方法提取之类基本的重构手法。而:

  • 如果你告诉 AI,你要重构多个 if 到策略模式,那么它就会给你生成策略模式的代码。
  • 如果你给了 AI 对应的继承关系,那么它就会考虑到继承关系。
  • 如果你给了 AI 一些坏味道,那么它就会考虑到坏味道。

理解这一点,在工具上实现辅助重构就变得非常简单了。

引子 2:AI 辅助理解需求与实现

在研发数字化程度足够高时,我们可以轻松从一个线上的日常位置,自动关联到对应的需求变更原因。即从线上的日记信息,关联到发布与构建信息、代码库, 结合代码的变更行数,再结合变更信息(提交信息),找到对应的需求。

然,现实是遇到以下的两类场景,你就跪了:

  • AI 理解现有需求。大量的系统中,需求是没有有效记录(细节等)的,最后以代码中的实现为主。
  • AI 匹配需求变更点。代码中必然存在大量的 yydsSort、cxkdlq 词汇,这一类词汇连人类也是无法理解的。

这两类场景,都是从 1-60 的能力辅助范围,可以大大节省我们的时间。可是,我们可能会遇到的问题是,我们处于的位置是 0 的阶段,缺少对应的数字化。

融合规范、实践的工具落地

为了解决上述的多种问题,我们引入了一系列的新特性,以将规范、实践、软件知识工程融合到我们的工具中。

示例 1:提交信息生成,构建研发孪生

eacfc147ba7ef39067a5063a43c60c62.png

在“标准”的 DevOps 实践中,在流水线门禁中,限制提交信息的格式,以保证提交信息的质量。因为代码的变更提交信息直接关联到了需求与代码的关系, 对于研发数字化来说,是一个非常重要的环节。在结合 AI + IDE 时,过程应该是:

  1. IDE 中接入内部 OA 系统,以获取当前的用户信息。
  2. 根据用户信息,获取当前用户的需求信息,如需求 ID。
  3. 结合需求 ID 和代码变更信息,生成提交信息。

诸如于:

refactor(rename): handle exceptions and improve logging for rename suggestions #129

。简单来说,借助生成式 AI 的能力, 将提交信息生成的过程自动化,在提升开发人员体验的同时,也构建了研发孪生的基石。

PS:由于 Rename 可能是高频场景,所以需要手动在配置页开启:

AutoDev

->

AutoDev Coder

->

Enable Rename suggestion

示例 2:标识坏味道,改进代码质量

如上所述,重构依赖于好的上下文或者意图,而代码中的坏味道就是一个非常好的意图。结合 IDE 自带的代码检查工具,我们可以获取到代码中的坏味道信息, 并将其转化为 AI 可以理解的信息,生成重构完后的代码,或者对应的重构建议。

类似的工具,还有诸如于 [Alibaba Java Coding Guidelines](虽然官方已经不维护了,但是毕竟开源),只需要获取对应的静态分析结果, 诸如于:

Variable 'content' is never used

,便可以让生成式 AI 发挥更大的作用。

当然了,在 AutoDev 1.8 中,我们优化了(复制了 JetBrains)的提示词,同时还提供了随机的重构建议,以鼓励用户在不满意的情况下,尝试更多的重构。

示例 3:语义化重构,可检索的代码实体

当代码发生变更时,原有的函数名、类名,便与原先的语义发生变化。而为了让后续的代码检索更加方便,需要将代码实体命名更加语义化。因此结合 #132 与 #129,我们添加了 AI 重命名的功能。
AutoDev Rename
AutoDev Rename

在这个场景下,当用户使用了 IDE 的重命名功能,AI 就会生成 5 个对应的函数名、类名建议,以供用户选择。

示例 4:终端 CLI 增强,统一常见范式

相似的,当我们在终端中使用 CLI 时,我们也需要 AI 的帮助。诸如于,创建发布分支是一个常见的工作,在这个场景下,我们需要分支格式,诸如于 release_v20240406 的格式。
Shell Suggest
Shell Suggest

为了让 AI 具备如此的能力,我们需要在上下文内置日期,以让他知道今天、明天;以及诸如于操作系统、Shell 工具等,以生成合适于当前工具上下文的命令。

此时,只需要问 AI:

  • "创建今天的分支",就会生成对应的分支名: git checkout -b feature/20240406
  • "创建新的发布分支",就会生成对应的分支名: git checkout -b release-20240406

对于组织内部来说,我们可以结合更多的规范等信息。

AutoDev 1.8 其它新特性:中文提示词等

3ebe18c29effcc27d483e4611182bf82.png

在新版本中,还有一些其它的新特性更新。

  • 辅助开发特性- 中文配置页。可以通过语言选择,选择中文配置页。- 中文提示词。当选择了中文配置页后,提示词也会变成中文。- 更便捷的 LLM 服务器测试。你可以在配置页,直接测试 LLM 是否可用。- 2024.1 版本支持。即 241 兼容性处理。
  • 智能体特性- AutoSQL 优化。在 SQL 生成中,新增了更多的错误信息处理。- 代码引用优化。支持到第 N 个 column 形式的字符 yml#L1C1-L2C12

总结

如何将大量的日常性工作,融入到开发者的日常工作中,是一个非常有意思的探索。对于 AutoDev 来说,我们要面临一个新挑战是,如此多的功能,难以让不熟悉插件的开发人员快速上手。


本文转载自: https://blog.csdn.net/gmszone/article/details/137485091
版权归原作者 Phodal 所有, 如有侵权,请联系我们删除。

“AutoDev 1.8 融合 DevOps 规范和实践,构建演进式 AI 辅助编码”的评论:

还没有评论