现代化改造为何破坏可用代码？LLM 处理遗留 PHP 的实证研究

在技术社区 Hacker News 上，一项题为《When Modernization Breaks Working Code: A Study of LLMs on Legacy PHP》的讨论引发了关注。该研究聚焦于一个被忽视却普遍存在的现实问题：当开发者试图用大语言模型（LLM）去“现代化”那些仍在生产环境中运行的遗留 PHP 代码时，模型给出的修改建议是否真的安全可靠？

为什么遗留 PHP 是一个特殊的试验场

遗留 PHP 代码库通常具有两个特征：一是语法和设计模式停留在较早的版本，二是经过多年打补丁后形成了大量“能跑但不好看”的隐式依赖。这类代码往往没有完整的测试覆盖，文档也严重缺失。LLM 擅长根据常见模式补全代码，但当它面对的是充满历史包袱的非标准实现时，其“合理化”倾向反而可能引入风险。

研究的出发点正在于此：现代开发工具默认追求简洁和现代语法，而遗留系统最需要的却是行为一致性。两者之间的张力，构成了 LLM 辅助重构的核心挑战。

隐式依赖与行为契约：遗留系统中常见的“隐式依赖”指的是代码的正确性依赖于未在接口或文档中显式声明的外部条件，例如全局变量的初始化顺序、函数调用的时序、数据库连接的共享状态，或特定 PHP 版本下 include 路径的解析方式。这些依赖往往是在多年修补中无意形成的，从未被正式记录。行为契约则是指系统对外表现出的可观察行为集合，包括返回值、异常类型、副作用和性能边界。对遗留系统而言，重构的真正目标不是让代码变“干净”，而是保持行为契约不变。LLM 在生成代码时无法感知这些隐式约束，因此其输出即使语法正确，也可能在边界条件或错误路径上悄然改变契约。

研究观察到的核心现象

据该研究的标题与讨论内容，LLM 在改造遗留 PHP 时出现了一个反复出现的模式：模型会主动替换掉那些看起来过时、但实际上承载着关键业务逻辑的写法。例如，将依赖特定执行顺序的代码重写为更“优雅”的结构，或将旧式数据库访问层替换为现代框架的调用方式。这些改动在语法层面往往正确，却可能改变边界条件、错误处理路径或全局状态的影响范围。

这并非模型能力不足，而是其目标函数与遗留系统维护目标之间的错位。LLM 被训练为生成“典型”的好代码，而遗留系统需要的恰恰是“保持原样”的保守修改。

目标函数错位：在机器学习中，目标函数定义了模型训练时优化的方向。对于代码生成 LLM，训练数据大量来自开源项目中风格统一、结构清晰的“好代码”，模型因而学会了偏向常见、简洁、现代的写法。但遗留系统的维护目标恰恰相反：优先保证行为等价和最小改动，而非代码美观。这种错位意味着模型会系统性地“纠正”那些看似过时却承载关键逻辑的写法，例如将依赖执行顺序的语句重排为更函数式的结构，或将旧式 mysql_* 调用替换为 PDO 抽象层。这些改动在语义上可能不等价，因为旧式写法可能依赖特定的错误抑制、资源释放时机或全局状态。理解这一错位有助于开发者预判模型输出的风险点，而不是简单归咎于模型能力不足。

对开发者的实际启示

这项研究传递出的信号很明确：在遗留代码库中使用 LLM 进行现代化改造，不能把模型输出直接当作补丁应用。更稳妥的做法是将 LLM 定位为理解代码的辅助工具，而非自动重构的执行者。在应用任何由模型生成的改动之前，必须依赖针对性的回归测试来验证行为等价性。

对于缺少测试的遗留项目，这意味着需要先补测试，再谈重构。LLM 可以加速测试用例的生成，但人工确认这些用例是否覆盖了关键路径，仍然是不可省略的一步。

回归测试与行为等价性：回归测试是一组在修改前后重复运行的测试用例，用于确认已有功能未被破坏。在 LLM 辅助重构的语境下，回归测试的核心作用是验证“行为等价性”，即修改后的代码在所有已覆盖的输入和状态下产生与修改前完全一致的输出和副作用。对于遗留 PHP 项目，这通常意味着需要先为关键路径补充特征测试（characterization test），即记录当前系统实际行为的测试，而非基于规格说明的测试。LLM 可以辅助生成这些测试的骨架，但开发者必须人工审查用例是否覆盖了异常分支、全局状态变化和数据库交互时序。没有这层验证，任何模型生成的“现代化”补丁都只是语法正确的猜测。

结语

Hacker News 上的这项讨论虽然简短，却触及了 AI 辅助编程中一个容易被热度掩盖的问题：代码的“现代”与“正确”并不总是同一回事。在遗留系统场景下，衡量 LLM 输出质量的标准不应是代码有多新，而应是它是否尊重了系统既有的行为契约。