在新版本的 AutoDev 中,我们又融入了一系列软件开发的实践,以更好地辅助开发人员的日常工作。这些新的特性,融合了我们对于 AI 辅助编码的新理解。诸如于:
还要最重要的中文 prompt 支持 —— 以更好地适应国内的模型和开发习惯,以及一系列的 bugfix 和新特性。
生成式 AI 辅助编码的两条技术路线是:重新生成还是代码变更。Unit Mesh 是我们设计的 AI 编码的重新生成架构范式,当来了新需求时,每次都生成新的代码。 哪怕是重新生成的效果再好,也受限于生成式 AI 的能力。因此,在实际落地的过程中,AutoDev 这样的辅助代码变更工具,才是当前适合于我们的演进路径。
代码变更,意味着我们需要人类和 AI 能理解现有的代码,以做出合适的决策建议。而如果我们预期 AI 能理解代码、需求,并编写出规范化的代码, 就依赖于我们构建了研发的知识工程体系。两个典型的场景是:现有需求总结和重构。
尽管结合 RAG 技术,可以提供足够没用的信息,以生成可能更适用用户意图的信息,但是并不适合开发人员的日常高频场景上使用。 因此,如何在 AI 辅助工具中构建规范与最佳实践,并内建软件开发知识工程,以拉升基线水平是一个非常有意思的挑战。
如果你探索过使用 AI 来构建代码时,你会发现:AI 懂的重构手法你都懂,但是看别人使用 AI 重构似乎非常顺手。这是为什么呢? 重构通常依赖于好的上下文,即需要开发人员拥有大量的先验经验。简单来说就是:表达意图与构建意图所有的上下文。
简单来说,当你缺少一个代码改进的方向时,无法给 AI 一个明确的意图,剩下的就要靠 AI 随机了 —— 因此,大部分情况下,AI 只是进行简单的重命名、方法提取之类基本的重构手法。而:
理解这一点,在工具上实现辅助重构就变得非常简单了。
在研发数字化程度足够高时,我们可以轻松从一个线上的日常位置,自动关联到对应的需求变更原因。即从线上的日记信息,关联到发布与构建信息、代码库, 结合代码的变更行数,再结合变更信息(提交信息),找到对应的需求。
然,现实是遇到以下的两类场景,你就跪了:
这两类场景,都是从 1-60 的能力辅助范围,可以大大节省我们的时间。可是,我们可能会遇到的问题是,我们处于的位置是 0 的阶段,缺少对应的数字化。
为了解决上述的多种问题,我们引入了一系列的新特性,以将规范、实践、软件知识工程融合到我们的工具中。
在“标准”的 DevOps 实践中,在流水线门禁中,限制提交信息的格式,以保证提交信息的质量。因为代码的变更提交信息直接关联到了需求与代码的关系, 对于研发数字化来说,是一个非常重要的环节。在结合 AI + IDE 时,过程应该是:
诸如于:refactor(rename): handle exceptions and improve logging for rename suggestions #129
。 简单来说,借助生成式 AI
的能力,
将提交信息生成的过程自动化,在提升开发人员体验的同时,也构建了研发孪生的基石。
PS:由于 Rename 可能是高频场景,所以需要手动在配置页开启:AutoDev
-> AutoDev Coder
-> Enable Rename suggestion
。
如上所述,重构依赖于好的上下文或者意图,而代码中的坏味道就是一个非常好的意图。结合 IDE 自带的代码检查工具,我们可以获取到代码中的坏味道信息, 并将其转化为 AI 可以理解的信息,生成重构完后的代码,或者对应的重构建议。
类似的工具,还有诸如于 [Alibaba Java Coding Guidelines](虽然官方已经不维护了,但是毕竟开源),只需要获取对应的静态分析结果,
诸如于:Variable 'content' is never used
,便可以让生成式 AI 发挥更大的作用。
当然了,在 AutoDev 1.8 中,我们优化了(复制了 JetBrains)的提示词,同时还提供了随机的重构建议,以鼓励用户在不满意的情况下,尝试更多的重构。
当代码发生变更时,原有的函数名、类名,便与原先的语义发生变化。而为了让后续的代码检索更加方便,需要将代码实体命名更加语义化。因此结合 #132 与 #129,我们添加了 AI 重命名的功能。
在这个场景下,当用户使用了 IDE 的重命名功能,AI 就会生成 5 个对应的函数名、类名建议,以供用户选择。
相似的,当我们在终端中使用 CLI 时,我们也需要 AI 的帮助。诸如于,创建发布分支是一个常见的工作,在这个场景下,我们需要分支格式,诸如于 release_v20240406 的格式。
为了让 AI 具备如此的能力,我们需要在上下文内置日期,以让他知道今天、明天;以及诸如于操作系统、Shell 工具等,以生成合适于当前工具上下文的命令。
此时,只需要问 AI:
git checkout -b feature/20240406
git checkout -b release-20240406
对于组织内部来说,我们可以结合更多的规范等信息。
在新版本中,还有一些其它的新特性更新。
yml#L1C1-L2C12
如何将大量的日常性工作,融入到开发者的日常工作中,是一个非常有意思的探索。 对于 AutoDev 来说,我们要面临一个新挑战是,如此多的功能,难以让不熟悉插件的开发人员快速上手。
围观我的Github Idea墙, 也许,你会遇到心仪的项目