老代码现代化要先做考古

旧代码最难处理的地方，从来不是语法旧，而是时代旧。一个项目里同时塞着 build.xml、老 JDK、老测试框架、老打包方式，表面上看是几堆文件，实际上是一层层历史假设叠在一起。代码本身只是最外层，真正卡住交付的，往往是这些假设还在不在、还能不能被复现、改动之后会不会把旧行为弄丢。

这就是“考古”先于“改造”的原因。先看 build 文件，再看依赖，再看运行环境，再看测试，顺序不能倒。build.xml 还在，pom.xml 不存在，这类信号已经足够说明项目活在 Ant 时代；代码能不能编过、测试能不能跑通、产物能不能重建，才是第一批证据。模型在这里最有用的地方，不是马上替旧代码写新代码，而是把这些证据从一堆碎片里先识别出来。

环境也必须先钉住。旧代码经常带着旧 JVM、旧容器、旧架构假设。把它直接丢到今天的机器上，尤其是跨架构环境里，出问题时很容易混进新的噪声：到底是代码本来就坏，还是 emulation、镜像、工具链在作怪。这个阶段如果连“同一份代码在同一份环境里能稳定复现”都做不到，后面所有现代化动作都只是猜。

AI 在这一步的价值很清楚：它能帮着做字符级和结构级的翻译。Ant 转 Gradle、老式构建脚本转成现在能维护的形式、把一堆重复的 XML 和样板搬到更清晰的位置，这些事很适合交给模型。它快，愿意反复试，而且不嫌琐碎。但它不适合当裁判。哪些 warning 可以先留着，哪些测试其实在撒谎，哪些模块该先切边界、哪些类只该做包一层适配，最终还是得由人来定。

测试最容易骗到人。老项目里的测试通过，并不意味着理解了系统，只可能意味着某些旧行为刚好被当前环境包住了。那种“全绿”的感觉很危险，因为它常常掩盖了更大的问题：测试验证的是某个年代的实现细节，不是现在要保住的业务语义。真要改造，先做的是把这些测试从“装饰性的安全感”里拎出来，重新判断它们是在护住什么。

所以这类项目最稳的方式，通常不是一口气重写，而是先造一个时间胶囊，把旧环境、旧行为、旧依赖固定住，再沿着最窄的缝往外拆。先把系统弄成可复现，再把重复劳动交给 AI 做翻译，再把边界一层层剥开。顺序一乱，模型会把旧项目加速推向更深的混乱；顺序对了，模型才像一个真正有用的考古助手，负责搬砖、清灰、对照证据，把人从脏活里解放出来，让判断留在人手里。