随着，我们在辅助测试和 SQL 的完善，在 AutoDev 中具备了基础的辅助遗留系统改造功能：
辅助迁移测试的 API 数据生成。辅助知识管理的文档生成。基于注释文档的活文档业务体系。面向对象的遗留代码重构。PL/SQL 代码生成与迁移 Java 代码。详细可以参见 AutoDev 场景文档系列：https://ide.unitmesh.cc/scenes/legacy-migration.html 。
遗留系统迁移的 AI 范式在过去的几年里，Thoughtworks 在行业内分享了一系列遗留系统改造的经验，绞杀者模式 vs 修缮模式、N 步重构法等。作为一个写过几个重构工具的砖家，我也在五年前编写了《系统重构与迁移指南》（https://migration.ink/）。
从模式上来说，遗留系统重构的过程可以简单分为：
理解现有业务设计与拆分模块构建测试防护网代码重构以迁移根据不同的系统在实现上略有差异，回到 IBM 的 COBOL 迁移工具的设计中，几乎以上述的过程是相似的：
理解。通过可视化的方式分析代码、数据、依赖重构。将 COBOL 程序解耦为模块化的 COBOL 架构转换。先为目标代码编写测试，再生成对应的 Java 代码。但是，在不同的场景上会出现一些差异，这也是我们在设计工具时所需要考虑的。
AI 遗留系统重构工具设计结合我们丰富的遗留系统重构经验，我们还是可以按上述的几个步骤来构建 AI 工具。
理解业务：业务理解与可视化遗留系统的一大痛点是没有知道业务知识，所以在生成式 AI 的加持下，问题域可以变为：
如何结合从现有的代码中知道业务的实现。即结合语义化搜索与 RAG，将用户的查询转换为代码搜索，最后交由 AI 来总结。如何可视化业务逻辑。在不同的场景之下，实现功能的要求也是不一样的。从可视化的角度来说，我们可以将代码转换为 DSL，再结合可视化工具来展示。如结合我们以往的工具，我们在 AutoDev 的文档生成功能中添加了活文档（Living Documentation）的功能，你可以结合注解从现有的逻辑中可视化业务。
如下是一个结合 AutoDev 生成活文档的示例：
@ScenarioDescription( given = "a file with name $filename and program text $programText", when = "the function tryFitAllFile is called with maxTokenCount $maxTokenCount, language $language, and virtualFile $virtualFile", then = "the function should return an ErrorScope object with the correct values")
随后，就可以清晰地呈现已有的逻辑实现。
测试构建：测试数据生成与集成测试生成通常来说，为了代码修复后功能是正常的，需要针对于 API 级别进行功能测试。所以，我们需要结合 API 测试工具或者是最外层的 Controller 进行测试。
测试数据测试。在结合生成式 AI 时，我们可以结合静态分析从入口生成测试数据。即我们在 AutoDev 中提供的测试数据生成功能。集成测试生成。可以结合直接使用 AutoDev 的一键生成测试功能，可以生成对应的 Controller 测试等。
有了足够的测试防护网之后，我们就可以开始进行对应的代码转换。
代码翻译：从 xx 语言到 xx 语言尽管 AI 翻译跨语言的代码时，并不是那么准确，可能出现一些 API 错误。诸如于，在 PL/SQL 中的函数写法不一致，导致在翻译成 Java 时会出现函数不存在。因此，我们需要一次性的将一段存储过程的代码翻译完，以确保翻译是通过的。
对应的，这个功能在 AutoDev 上的实现便是自定义 Prompts，以支持更丰富的翻译功能。
针对特定语言翻译：PL/SQL 示例由于不同语言间存在一些能力等的差异，所以我们需要考虑到不同的语言的场景。诸如于，在 AutoDev 中针对于 PL/SQL 构建了相似的功能：
从 SQL 代码生成 entity 代码。从 SQL 代码生成 Java 测试。从 SQL 代码生成 Java 代码。
考虑到对于语言的理解，能力还是有待进一步完善的。
总结总而言之，言而总之，遗留系统还是一个颇为理想的 AI 辅助场景。AI 可以增强我们现有的重构方式，但是是否存在新的方式是一个特别有意思的问题。
