用 Kiro 构建可重复的 PHP 到 Java 迁移引擎

这篇 AWS 机器学习博客给出了一套把 PHP 应用迁移到 Java 的可重复方法，核心是把迁移知识写成可版本化的技能文件，而不是依赖一次性的人工翻译。整套引擎由三部分组成：共享方法论、机械化的发现扫描器，以及八阶段工作流。它把原始 PHP 应用当作规格说明，在一致性验证工具确认之前不宣布 Java 版本正确。 工作区分为全局层与项目层。全局 .kiro/ 目录下存放两个技能：php-model-discovery 扫描器和 php-to-java-migration 八阶段手册，另有 core-workflow.md 指导文件；每个项目文件夹各自保存 PHP 源码、Java 输出和 .kiro/specs/ 下的规格。改进一次方法论，所有项目都能继承。 最重要的规则是“先发现再翻译”：在扫描器运行之前，不得阅读、猜测或手工翻译任何模型文件。扫描器 discover-models.php 是单文件、无依赖的 PHP 命令行工具，不执行目标代码，只把源码当作 token 读取，因此依赖未安装也能运行。它用三种策略扫描：Eloquent 模型发现（沿继承链走到 Illuminate\Database\Eloquent\Model）、Doctrine 的 #[ORM\Entity] 属性检测、以及外部 *.orm.xml 映射文件。输出是一份 JSON 清单，models[] 记录字段、类型转换、关系和可见性规则，flags[] 把歧义（例如由运行时表达式构造的 $fillable 列表）转成待人工复核的标记队列。 八阶段中，Phase 0 运行扫描器并汇总清单；Phase 1 在写 Java 之前先构建一致性验证工具，用请求/响应配对同时回放 PHP 原件和 Java 移植版，且必须能在故意破坏时失败，否则不予信任；Phase 2 生成 RULEBOOK.md 和 GAP_INVENTORY.md；Phase 3 用代表性文件压测规则手册。Phase 4 到 8 主要是自驱动循环：搭建 Spring Boot 项目、翻译数据模型、翻译 I/O 层（路由变控制器、中间件变过滤器、校验变带注解的 DTO）、分批转换业务逻辑、最后用验证工具证明一致性并切换。两条原则贯穿始终：PHP 代码即规格；修循环而非改代码，即修订规则手册后重新生成，而不是手工打补丁。 示例项目 laravel-eloquent-sample 是开源 Laravel 应用的只读切片，把 Book、Chapter、Page、User 四个模型迁移到 Spring Boot 3.4.1、Java 21、Maven 和内存 H2 数据库。映射是机械且可追溯的：PHP 命名空间变 Java 包，Eloquent 模型变 JPA @Entity，hasMany 和 belongsTo 变 @OneToMany 和 @ManyToOne，查询作用域变 Spring Data 仓库方法。序列化细节也来自清单：html、markdown、text 因记录在 Page 的 $hidden 列表中而带 @JsonIgnore，Book 的 description 则没有。文档坦承 37 个模型中只迁移了 4 个，且该切片从未构建一致性验证工具，称其为“最大的缺口”。 同一套技能文件有两条执行路径：Kiro 是交互式、开发者全程在环，逐阶段设置审批关卡；AWS Transform 是 AWS 的智能体 AI 服务，已与 Kiro 原生集成，可把相同技能文件用于自主运行，以并行作业处理多个应用。两条路径共享反馈循环，在 Kiro 中做的规则修正会改善下一次 AWS Transform 运行，反之亦然。使用方法为克隆仓库、以包含 .kiro/ 的根目录打开 Kiro 工作区，把 PHP 源码放入 …