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