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

把运行多年的 PHP 应用迁到 Java，通常是为了获得更强的类型安全、更广的库支持和更可预测的扩展能力。但用 Laravel、Symfony 或 Doctrine 长期积累的代码库，业务规则往往散落在 Eloquent trait、XML 映射文件等不显眼的位置，结构相似的 Java 移植版本可能编译通过却行为不同。AWS 博客给出的思路是把这类迁移从一次性冒险变成可度量、可重复的流程，工具是 AI IDE Kiro。

引擎由三部分组成

文章把方案概括为一个可复用的引擎：共享的方法论、机械化的发现扫描器，以及八阶段工作流。核心原则是把原 PHP 应用当作规格说明，在一致性校验工具验证通过之前，不宣布 Java 移植版本正确。

所有知识都放在技能文件里——带版本号的 Markdown 能力包，分别编码迁移方法论（php-to-java-migration）和发现扫描器工作流（php-model-discovery）。工作区在 .kiro/ 下分两层：全局层放两个技能和 core-workflow.md 指导文件，各项目文件夹放自己的 PHP 源码、Java 输出和 .kiro/specs/ 下的规格子目录。方法论改一次，所有项目都能继承。

两种运行方式

因为知识存在文件而非某个工具里，同一套方法论有两种跑法。

方法一是在 Kiro 中交互执行：把仓库根目录作为 Kiro 工作区打开，要求迁移某个 PHP 应用时技能自动激活，Kiro 按八阶段推进并设置明确的审批关卡，开发者需要审阅发现清单、批准规则手册、逐阶段签字确认。文章中的所有示例都用这种方式。

方法二是 AWS Transform：这是 AWS 面向大规模迁移和现代化的智能体 AI 服务，现已与 Kiro 原生集成。把同一批技能文件交给 AWS Transform，就能以自主运行方式套用同样的规则——先发现后翻译、以一致性校验为裁判、修流程而非改代码。Kiro 一次处理一个应用，适合首次接触的框架；AWS Transform 以并行任务处理多个应用。两条路径读同一批技能文件，因此在 Kiro 中做的规则修正会改善下一次 AWS Transform 运行，反之亦然。

先发现，再翻译

文章强调最重要的一条规则：在扫描器运行之前，不要阅读、猜测或手工翻译任何模型或实体文件。扫描器单遍运行、无依赖，对源码 token 应用三种发现策略，输出一份 JSON 清单，歧义项进入复核标记队列交由人工处理。

前置条件

需要熟悉 PHP（Laravel/Eloquent 或 Symfony/Doctrine），了解 Java（Spring Boot、JPA）有助于审阅生成结果，但引擎会产出符合 Java 习惯的代码，不需要自己重写应用。还需要一个能访问 Skills 和 Steering 文件的 Kiro 工作区、运行扫描器的机器上安装 PHP 8.0 或更新版本，以及 Java 21 和 Maven 用于生成的 Spring Boot 项目。

编辑部观察

这套方案值得注意的地方不在“AI 写代码”，而在把迁移方法论固化成可版本管理的技能文件，让交互式与批量式两条执行路径共享同一套规则和反馈。对计划迁移遗留 PHP 系统的团队，可以先按文章建议在单个应用上跑通八阶段流程、审阅生成的 Java 并运行测试，再评估是否扩大到组合级并行迁移。文章未给出迁移耗时、成本或一致性校验通过率等量化数据，实际效果需在自有代码库上验证。