AWS展示了一套由Kiro驱动的PHP到Spring Boot迁移方法：先机械扫描业务结构，再按八阶段转换，并用一致性测试把原系统当作规格，而不是让Agent凭局部代码猜测。
为什么直接翻译容易失败
成熟PHP项目的业务规则分散在Eloquent traits、Doctrine属性、XML映射、事件和中间件中。Java代码即使能够编译，也可能遗漏字段转换、软删除、关联加载或权限行为。大模型逐文件翻译会把局部结构复制过去，却无法证明外部行为一致。
这套方法要求先发现、再建规则、然后转换。原应用的输入输出和数据库行为是基准，生成代码必须通过一致性工具验证。与站内AI迁移COBOL与Fortran实践相同，迁移成功的核心是可验证，而不是生成速度。
扫描阶段具体做什么
无依赖PHP扫描器只读取源码token，不执行目标项目。它识别Eloquent继承链、Doctrine实体属性和ORM XML映射，输出JSON清单，包含字段、类型转换、关联、可见性和疑点标记。运行时表达式等无法确定的内容进入人工队列，禁止猜测。
团队先审查清单和规则书，确认命名、类型、主键、时间、软删除及关联策略。扫描结果应保存源码提交号，后续源项目变化时重新生成差异。
Kiro与AWS Transform怎么选
Kiro适合第一个应用，开发者在IDE中逐阶段批准并阅读生成代码；AWS Transform适合方法稳定后的批量迁移。两者使用相同Skills与Steering文件，因此在Kiro中修正的规则可复用于后续自动任务。
不要第一天就并行迁移几十个系统。先选业务边界清楚、测试相对完整的应用跑通，统计每类错误并改进规则。只有一致性测试覆盖关键接口后，才扩大规模。
八阶段中的验收原则
每一阶段都有输入、输出和审批点：发现、规格、骨架、模型、服务、接口、测试与切换。数据库迁移先在副本验证；接口同时比较状态码、字段、排序、分页和错误行为；异步任务比较重试和幂等。
双写或影子流量期间记录PHP与Java输出差异，分类修复规则，而不是只改某个生成文件。切换前准备数据备份、流量回退和旧系统保留期限。若无法快速回退，就不应一次性替换。
落地结论
真正可用的AI系统必须同时满足任务有效、数据可控、成本可解释和失败可回退。建议先用真实且脱敏的小样本建立基线，再逐步开放工具与自动化权限；任何涉及生产修改、外部发送、医疗科研结论或资金的动作，都应保留人工审批和完整审计。
资料来源：AWS：Build a repeatable PHP-to-Java migration engine with Kiro。本文依据公开资料重新整理，并结合工程实践给出操作建议；厂商公布的性能和案例数据不等同于独立第三方验证。
