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

Posted by: Phodal Huang April 6, 2024, 4:27 p.m.

在新版本的 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 时，过程应该是：

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 重命名的功能。

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

示例 4：终端 CLI 增强，统一常见范式

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

为了让 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 来说，我们要面临一个新挑战是，如此多的功能，难以让不熟悉插件的开发人员快速上手。