AutoDev 1.8 融合 DevOps 规范和实践,构建演进式 AI 辅助编码
在新版本的 AutoDev 中,我们又融入了一系列软件开发的实践,以更好地辅助开发人员的日常工作。这些新的特性,融合了我们对于 AI 辅助编码的新理解。诸如于:重构:AI 重命名、坏味道重构、重构建议。提交信息优化:结合用户输入的,提交信息生成CLI 生成:结合用户输入的,生成 CLI 命令还要最重要的中文 prompt 支持—— 以更好地适应国内的模型和开发习惯,以及一系列的 bugfix 和.
在新版本的 AutoDev 中,我们又融入了一系列软件开发的实践,以更好地辅助开发人员的日常工作。这些新的特性,融合了我们对于 AI 辅助编码的新理解。诸如于:
重构:AI 重命名、坏味道重构、重构建议。
提交信息优化:结合用户输入的,提交信息生成
CLI 生成:结合用户输入的,生成 CLI 命令
还要最重要的中文 prompt 支持 —— 以更好地适应国内的模型和开发习惯,以及一系列的 bugfix 和新特性。
演进式 AI 辅助编码
生成式 AI 辅助编码的两条技术路线是:重新生成还是代码变更。Unit Mesh 是我们设计的 AI 编码的重新生成架构范式,当来了新需求时,每次都生成新的代码。哪怕是重新生成的效果再好,也受限于生成式 AI 的能力。因此,在实际落地的过程中,AutoDev 这样的辅助代码变更工具,才是当前适合于我们的演进路径。
代码变更,意味着我们需要人类和 AI 能理解现有的代码,以做出合适的决策建议。而如果我们预期 AI 能理解代码、需求,并编写出规范化的代码, 就依赖于我们构建了研发的知识工程体系。两个典型的场景是:现有需求总结和重构。
现有需求总结。理解用户输入,检索到对应的现有代码实现逻辑,由AI 来总结已有的逻辑实现
重构。AI 重构的难度介于自动生成代码与架构设计之间,是一个非常不错的探索场景。
尽管结合 RAG 技术,可以提供足够没用的信息,以生成可能更适用用户意图的信息,但是并不适合开发人员的日常高频场景上使用。因此,如何在 AI 辅助工具中构建规范与最佳实践,并内建软件开发知识工程,以拉升基线水平是一个非常有意思的挑战。
引子 1:如何让 AI 更好地重构出理想的代码?
如果你探索过使用 AI 来构建代码时,你会发现:AI 懂的重构手法你都懂,但是看别人使用 AI 重构似乎非常顺手。这是为什么呢?重构通常依赖于好的上下文,即需要开发人员拥有大量的先验经验。简单来说就是:表达意图与构建意图所有的上下文。
简单来说,当你缺少一个代码改进的方向时,无法给 AI 一个明确的意图,剩下的就要靠 AI 随机了 —— 因此,大部分情况下,AI 只是进行简单的重命名、方法提取之类基本的重构手法。而:
如果你告诉 AI,你要重构多个 if 到策略模式,那么它就会给你生成策略模式的代码。
如果你给了 AI 对应的继承关系,那么它就会考虑到继承关系。
如果你给了 AI 一些坏味道,那么它就会考虑到坏味道。
理解这一点,在工具上实现辅助重构就变得非常简单了。
引子 2:AI 辅助理解需求与实现
在研发数字化程度足够高时,我们可以轻松从一个线上的日常位置,自动关联到对应的需求变更原因。即从线上的日记信息,关联到发布与构建信息、代码库, 结合代码的变更行数,再结合变更信息(提交信息),找到对应的需求。
然,现实是遇到以下的两类场景,你就跪了:
AI 理解现有需求。大量的系统中,需求是没有有效记录(细节等)的,最后以代码中的实现为主。
AI 匹配需求变更点。代码中必然存在大量的 yydsSort、cxkdlq 词汇,这一类词汇连人类也是无法理解的。
这两类场景,都是从 1-60 的能力辅助范围,可以大大节省我们的时间。可是,我们可能会遇到的问题是,我们处于的位置是 0 的阶段,缺少对应的数字化。
融合规范、实践的工具落地
为了解决上述的多种问题,我们引入了一系列的新特性,以将规范、实践、软件知识工程融合到我们的工具中。
示例 1:提交信息生成,构建研发孪生
在“标准”的 DevOps 实践中,在流水线门禁中,限制提交信息的格式,以保证提交信息的质量。因为代码的变更提交信息直接关联到了需求与代码的关系, 对于研发数字化来说,是一个非常重要的环节。在结合 AI + IDE 时,过程应该是:
IDE 中接入内部 OA 系统,以获取当前的用户信息。
根据用户信息,获取当前用户的需求信息,如需求 ID。
结合需求 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 1445200dcf59f00612e454263f87fbb3.png](https://i-blog.csdnimg.cn/blog_migrate/f66091365f5b7ef1f0a642c0a222f384.png)
在这个场景下,当用户使用了 IDE 的重命名功能,AI 就会生成 5 个对应的函数名、类名建议,以供用户选择。
示例 4:终端 CLI 增强,统一常见范式
相似的,当我们在终端中使用 CLI 时,我们也需要 AI 的帮助。诸如于,创建发布分支是一个常见的工作,在这个场景下,我们需要分支格式,诸如于 release_v20240406 的格式。
![Shell Suggest ec7b338dd3d003a2cae2109de6eab499.png](https://i-blog.csdnimg.cn/blog_migrate/13d76280bf646db383f349f171fc9edb.png)
为了让 AI 具备如此的能力,我们需要在上下文内置日期,以让他知道今天、明天;以及诸如于操作系统、Shell 工具等,以生成合适于当前工具上下文的命令。
此时,只需要问 AI:
"创建今天的分支",就会生成对应的分支名:
git checkout -b feature/20240406
"创建新的发布分支",就会生成对应的分支名:
git checkout -b release-20240406
对于组织内部来说,我们可以结合更多的规范等信息。
AutoDev 1.8 其它新特性:中文提示词等
在新版本中,还有一些其它的新特性更新。
辅助开发特性
中文配置页。可以通过语言选择,选择中文配置页。
中文提示词。当选择了中文配置页后,提示词也会变成中文。
更便捷的 LLM 服务器测试。你可以在配置页,直接测试 LLM 是否可用。
2024.1 版本支持。即 241 兼容性处理。
智能体特性
AutoSQL 优化。在 SQL 生成中,新增了更多的错误信息处理。
代码引用优化。支持到第 N 个 column 形式的字符
yml#L1C1-L2C12
总结
如何将大量的日常性工作,融入到开发者的日常工作中,是一个非常有意思的探索。对于 AutoDev 来说,我们要面临一个新挑战是,如此多的功能,难以让不熟悉插件的开发人员快速上手。
更多推荐
所有评论(0)