一个迁移参考项目，为什么要醒目写下“37个模型只迁了4个，而且没建行为对照验证”？AWS在10月30日介绍的PHP到Java迁移方法，把这个缺口直接摆了出来。它说明AI改写代码真正要交付的，不是一个能够启动的Java工程，而是旧系统的业务行为是否被保留，以及还没验证的部分有没有被诚实记录。

快速看点：这是参考方法的工程介绍，不是当天首次推出通用迁移产品；流程在正式转换前安排扫描、规则和行为裁判；Kiro与AWS Transform可复用同一套方法文件；配套试点的局部完成，不能冒充完整应用或生产切换成功。

先找出隐含规则，再决定怎么翻译

成熟PHP应用的规则不只藏在显眼的业务函数里。模型继承、字段可见性、查询方法和外部ORM映射，都可能改变接口返回。新代码即使结构相似、编译干净，也可能多返回一个不该展示的字段，或把原本允许为空的时间值变成另一种行为。

参考方案把可复用方法放在共享目录，每个应用另有代码和规格记录。发现扫描器读取源码token，分别寻找Eloquent继承链、Doctrine属性及XML映射，输出模型清单与待人工确认的标记。材料说明扫描不需要启动目标应用；这与运行旧应用、验证真实响应，是不同阶段的工作。

标记尤其重要：动态生成的字段列表、无法确定的关系目标或类型，应该进入人工审核队列，而不是由模型安静地猜一个答案。静态清单帮助缩小未知范围，却不等于证明运行时行为；扫描完成之后，还要检查权限、外部认证、文件处理和隐含共享状态等耦合。

先造裁判，再让Agent批量转换

方法以准备阶段0和后续1至8阶段组织。准备阶段清点应用；阶段1先建立能同时面对PHP与Java的请求、响应对照；随后建立规则手册和缺口清单，并用代表性文件压力测试规则。之后才进入脚手架、数据模型、输入输出层和业务逻辑转换。

对照验证本身也必须被测试：先能接受正常旧系统，再对故意破坏的行为报错。否则，一个永远显示通过的验证器，只会给错误迁移盖章。遇到差异时，团队要修正转换规则并重新生成；确实要改变的业务行为，则应明确记录并审批，不能悄悄当作“现代化优化”。

Kiro对应开发者参与、逐阶段确认的方式；AWS Transform则可读取同类方法文件，组织更多应用的迁移任务。但同一套文件可被复用，不代表每个框架的规则已经完整，也不代表规模扩大后可以取消每个项目自己的审批与对照验证。

四个模型的试点，明确写出了没有证明什么

配套BookStack记录把自己标为试点切片，而非完整迁移。它列出37个Eloquent模型，但Java侧只处理Book、Chapter、Page和User四个实体，以及四个只读入口；没有接入完整认证、写操作和其余模型。因此，“这部分能编译”不能被扩大为整个应用已经迁好。

更关键的是，该切片没有建立真正的行为对照验证。记录描述的是按字段人工比较及少量端点烟雾测试，并把缺少裁判列为最大缺口。仓库内还保留7月25日的反馈日期，所以10月30日文章应理解为对现有参考材料的介绍，不能把这些试验写成当天新完成的生产交付。

试点暴露的细节也有复用价值：页面隐藏字段需要在Java序列化时继续隐藏，可空时间戳不能随意变成非空默认值，软删除也未必对应单个deleted_at字段。权限继承、搜索、外部认证等仍在缺口清单中，不能由四个实体的映射推导成已经解决。

可复现基线同样要逐项看。README为Symfony示例列出了具体上游提交，但BookStack和Sylius写的是扫描时的最新版本；不能据此声称所有样例都有同等精确的提交锁定。真正迁移时，团队应另行固定源码、依赖、输入数据和验证语料，留下可以复查的对照环境。

本站本轮读取了公告、完整README和BookStack试点规格，核对了扫描入口及相关解析逻辑，没有执行上游扫描器、加载其技能、运行Java工程或复跑迁移测试。共享方法与可检查文件是参考交付物，不是本站验证的成功率、提速或投资回报。

小编判断

AI迁移工具最需要的，不是更快地宣布完成，而是把“完成”定义得更严格。这个参考方案值得关注的正是两点：在翻译前建立可反驳的裁判，并把局部试点未证明的内容写清。规则、基线、差异和人工批准能够被追溯，批量改写才有机会变成可验收的工程过程。