AWS发布基于Kiro的PHP转Java迁移引擎：八阶段流程，以对等测试判定完成
AWS机器学习博客介绍一套可复用的迁移方法：先用扫描器清点PHP模型，再在写Java前搭建对等测试基准，把原PHP应用当作规格说明，八阶段中后五个阶段由AI代理循环执行
AI解读：这套方法要解决的具体问题是：PHP应用里分散在Eloquent trait、XML映射文件中的业务规则不易被发现，结构相似的Java移植版可能编译通过却行为不同。AWS把“对等测试未通过就不算完成”设为判定条件，读者需要弄清的是：所谓“完成”由谁定义——由迁移前就搭好的对等测试基准定义，而非代码能编译或人工抽查。
适用对象是已有成熟PHP应用、计划迁到Java Spring Boot的团队。方法要求PHP 8.0以上运行扫描器、Java 21加Maven构建生成项目，Kiro工作区需能访问Skills与Steering文件。作者称引擎会生成惯用Java，使用者不必自己重写应用，但需要能审阅生成结果。
使用条件上有明确限制。前三阶段集中人工判断：扫描、搭对等测试、写规则手册并压力测试；后五阶段才较多自动循环。扫描器只读取源码文本、不执行目标代码，因此依赖未安装也能运行，但遇到运行时表达式构造的$fillable等会标记为待人工裁决，不自行猜测。
结果边界值得注意：文中走查的laravel-eloquent-sample只移植了37个模型中的4个，且作者明言这一切片从未搭建对等测试基准，称其为“最大的缺口”。因此该示例只能证明映射可追溯，不能证明迁移后行为等价。
两种执行方式共用同一套skill文件：Kiro交互式一次处理一个应用，AWS Transform以并行任务处理多个应用。作者称在Kiro中修改的规则会同步改善后续AWS Transform运行，这属于AWS对自身产品的说法，来源未给出迁移耗时或缺陷率数据。
AWS机器学习博客于8月发布文章，介绍如何用AI集成开发环境Kiro搭建一套可重复的PHP转Java迁移引擎。作者Sarat Guttikonda称，该引擎把原PHP应用当作规格说明，在生成Java代码前先建立对等测试基准，八阶段流程中未通过对等验证就不宣布移植正确。
方法打包为skill文件（版本化的Markdown能力包），包含迁移方法php-to-java-migration和扫描流程php-model-discovery，另有一个Steering文件core-workflow.md，存放于工作区全局的.kiro/目录，各项目文件夹分别保存自己的PHP源码、Java输出和.kiro/specs/下的规格。同一套文件可由Kiro或AWS Transform运行。
作者列出的前置条件包括：熟悉PHP（Laravel/Eloquent或Symfony/Doctrine）、具备Java与Spring Boot、JPA知识以便审阅生成结果；可访问Skills和Steering文件的Kiro工作区；运行扫描器的机器需PHP 8.0以上，生成项目需Java 21与Maven。
扫描器先于翻译，歧义交人工
引擎的第一条规则是：在扫描器运行前，不阅读、不猜测、不手工翻译任何模型或实体文件。扫描器discover-models.php是单文件、无依赖的PHP命令行工具，不执行目标代码，只把源码当token读取，因此目标应用的依赖未安装也能运行。
它一次扫描运行三种策略：沿类继承链查找Illuminate\Database\Eloquent\Model的Eloquent模型发现、检测#[ORM\Entity]属性的Doctrine注解识别、以及外部*.orm.xml文件的ORM XML映射。输出单个JSON清单，models[]记录每个字段、类型转换、关系和可见性规则，flags[]列出歧义项，例如由运行时表达式构造的$fillable会转为一条自然语言标记，进入人工审查队列。
- 三种发现策略：Eloquent继承链、Doctrine属性、ORM XML映射
- 扫描器只读源码文本，不执行目标代码
- 输出单一JSON清单，含models[]与flags[]
- 歧义不猜测，进入人工审查队列
八阶段流程：前四阶段压入人工判断
第0阶段为准备，运行扫描器并汇总清单；第1阶段在写Java之前搭建对等测试基准，用请求/响应配对分别回放给原PHP应用和Java移植版。作者要求该基准必须对正常PHP通过，且在故意破坏时失败，因为漏掉注入故障的基准不可信。
第2阶段产出RULEBOOK.md与GAP_INVENTORY.md，即规则手册与缺口清单；第3阶段用代表性文件对规则手册做压力测试，通过后才在全应用推行。第4至第8阶段偏自动循环：搭建可编译的Spring Boot项目、依据清单翻译数据模型为JPA实体与库表基线、翻译I/O层（路由转控制器、中间件转过滤器、校验转带注解的数据传输对象）、分批转换业务逻辑、最后用对等测试基准验证并切换。
两条原则约束后半程：PHP代码即规格，移植完成以测试基准同意为准，否则每条不一致都记录为已批准的变更；出问题改规则手册并重新生成，而非手工打补丁。
- 第0阶段：扫描器 + 模型清单 + 切换决策
- 第1阶段：对等测试基准，对PHP和Java均可运行
- 第2阶段：RULEBOOK.md、GAP_INVENTORY.md
- 第3阶段：规则手册经代表性文件验证后固化
- 第4–8阶段：脚手架、数据模型、I/O层、业务逻辑、对等验证与切换
示例范围与自述缺口
文章以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仓库方法。序列化也依据清单：Page的$hidden列表中记录的html、markdown、text字段带@JsonIgnore，而Book的description没有。
作者在文中明言，该切片只移植了37个模型中的4个，且从未为其搭建对等测试基准，称这是“唯一的、也是最大的缺口”。README锁定了对等验证所用的上游提交，以便复现基线。
方法自称可自动识别Laravel、Symfony、CodeIgniter与普通PHP，扩展方式是新增一行检测配置和一份面向Spring的references指南。文中未给出迁移耗时、缺陷率或成本数据。
- 示例：4个模型，Spring Boot 3.4.1 / Java 21 / Maven /内存H2
- 37个模型中仅移植4个
- 示例未搭建对等测试基准，作者称其为最大缺口
- 来源未提供迁移效率或质量数据
两种运行方式与清理
Kiro方式为交互式，一次一个应用，适合首次接触的框架，每个阶段设审批关口，由使用者审阅发现清单、批准规则手册后再进入下一阶段。AWS Transform方式为代理式，可并行处理多个应用；作者称两者读取同一套skill文件，任一路径对规则手册的修正都会改善另一次运行——此为AWS对自身产品能力的描述。
清理方面：停止运行中的Spring Boot应用即可，H2内存库无需单独清理；可删除不再需要的生成Java项目文件夹与扫描器输出的JSON清单。文章称迁移引擎本身不创建AWS资源，因此无需释放云端资源。
- Kiro：交互、单应用、阶段审批
- AWS Transform：代理式、多应用并行任务
- 两者共用skill文件，修改互相继承（AWS说法）
- 引擎不创建AWS资源，无云端清理项