考古学家及其副驾驶：马尔欣训练LLM使用Java 1.5

简单来说

在遗留代码上使用LLM会产生听起来合理但不符合项目的回答。有效的方法是强制助手基于证据——代码、测试、工件——而不是基于其记忆来工作。

考古学家在工作

2026年7月16日，Nik Malykhin在martinfowler.com上讲述了他将Java 1.5基础升级到现代环境的经历。这个背景并不常见：现代分析和重构工具不喜欢Java 1.5，许多工具甚至拒绝接受。他的第一反应——直接向助手请求修复——产生了Malykhin描述为“合理”的回答，这些回答“在代码库中无法成立”：看起来像是好的Java 1.5代码，但与实际存储库不符。

转折点在于方法论。Malykhin将LLM用作分析师和验证者，而不是用作撰写者，每一步都基于存储库：仔细阅读现有代码，通过测试和执行跟踪验证假设，拒绝比代码本身允许的速度更快。文章的信息很简单：使用LLM进行遗留现代化不会比考古学家更快，它同样缓慢，但演示中没有漏洞。

幕后

这种模式在现代代理工具中有多个名称——基于证据的提示、基于检索的推理、检索优先——但它基于同一规则：助手的每一项陈述都必须基于存储库中的工件（一个文件、一行、一个测试）。缺乏这种约束是LLM在遗留系统中产生最昂贵的“误报”的原因：目标版本之后的API、不存在的方法、幻影导入。

那么呢

对于接触遗留系统的团队来说，“副驾驶”并不用于编写，而是用于检索。真正的生产力来自于让LLM阅读，而不是让它猜测。对于CTO的一个推论是：受AI辅助的现代化项目的良好指标不是“生成的行数”，而是“代码本身驳斥的假设”。两者之间的区别在于一个遗留项目能否成功，还是重新陷入技术债务。