feat(ai4se): 添加 DIIDACT 框架代码迁移示例

引入了 DIIDACT 框架的详细描述，包括代码迁移的三个阶段，并重点介绍了 AI 在编辑生成和验证阶段的应用。同时，添加了迁移过程中使用的输入示例和迁移工具包的自动化扩展功能说明。

src/ai4se-google-dev-activity-driven.md

@@ -71,3 +71,41 @@ ML 建议的修复方案。
 我们在使用构建修复的变更列表和未使用的变更列表之间监测了这些指标，发现没有可检测的差异。
 
 
+### DIIDACT 框架：[代码迁移](https://research.google/blog/accelerating-code-migrations-with-ai/)
+
+多年来，谷歌一直使用专门的基础设施来执行复杂的代码迁移。该基础设施使用静态分析和如 [Kythe](https://kythe.io/)
+和 [Code Search](https://abseil.io/resources/swe-book/html/ch17.html)
+等工具来发现需要更改的位置及其依赖关系。然后使用如 [ClangMR](https://clang.llvm.org/docs/RefactoringEngine.html) (Clang’s
+refactoring engine)等工具进行更改。
+
+
+我们将迁移过程概念性地分为三个阶段：
+
+- 确定需要修改的代码库位置
+- 编辑生成和验证
+- 更改审查和发布
+
+虽然这些阶段中的每一个都受益于 AI，我们主要关注第 2 阶段。
+
+为了生成和验证代码更改，我们利用了在谷歌内部代码和数据上微调过的 Gemini 模型版本。
+
+每次迁移需要以下输入：
+
+- 一组文件和预期更改的位置：路径 + 文件中的行号
+- 一到两个描述更改的提示
+- [可选] 少量示例，以确定文件是否确实需要迁移
+
+多阶段代码迁移过程的示例执行。
+
+![](images/Google-AI_code_migrations.jpg)
+
+用户提供的文件位置通过预先存在的静态工具和人工输入的组合进行收集。我们的迁移工具包会自动扩展这组文件，添加其他相关文件，包括：测试文件、接口文件和其他依赖项。
+这一步骤尚未由 AI 驱动，但使用了符号交叉引用信息。
+
+在许多情况下，用户提供的迁移文件集并不完美。由于过滤输入列表可能很繁琐，一些文件可能已经部分或完全迁移。因此，为了避免冗余更改或在编辑生成过程中混淆模型，
+我们提供了少量示例，并要求模型预测文件是否需要迁移。
+
+编辑生成和验证步骤是我们发现自动系统最有益的地方。我们的模型在谷歌的单体代码库和流程数据上按照 DIDACT 方法进行了训练。在推理时，
+我们用自然语言指令以及模型的一般指令对每一行预计需要更改的地方进行标注。在每次模型查询中，输入上下文可以包含一个或多个相关文件。
+
+模型然后预测文件之间的差异（diff），并且可以更改相关部分，以确保最终代码正确。