大模型辅助重构遗留系统：从“跑通”到“跑对”的工程实践

当一个团队宣称“用大模型两周重写了一个老系统”时，旁观者最容易产生的疑问是：这是演示，还是工程？前者追求在最短时间内展示一个能动的画面，后者要求系统在格式、逻辑、许可、可维护性四个维度都站得住。本文以一个“用大模型重构经典即时战略游戏”的实践为线索，讨论这类项目的真实难点、可行方法，以及必须提前划定的边界。

需要说明的是，本文不针对任何特定模型版本或商业产品做能力评测，只把大模型当作一个具备代码生成、格式推断与实验编排能力的通用工具来看待。文中所讨论的流程，同样适用于协议解析、老旧文件格式迁移、遗留系统重写等更广泛的场景。

一、任务分解：把“重写一个游戏”拆成可验证的里程碑

原始实践给出的阶段划分值得借鉴：Pre-Alpha 打通全部 UI，Alpha 打通全部战斗，Beta 实现联机对战。这个划分的价值不在于命名，而在于每个阶段都有明确的“可验收信号”：

• Pre-Alpha：资源能被正确加载，界面能渲染，输入能被响应。验收信号是“画面与交互不报错”。
• Alpha：单位能移动、能攻击、能结算伤害。验收信号是“规则可复现”。
• Beta：多客户端状态同步。验收信号是“两端状态一致”。

这个顺序不能颠倒。UI 先行不是偷懒，而是因为 UI 是最容易获得即时反馈的层——它把“模型生成的代码是否正确”转化为“人眼能否看出异常”，从而把验证成本压到最低。对于没有自动化测试的历史系统，这种“可视化验收”几乎是唯一可行的早期反馈手段。

在实践中，建议把每个里程碑再拆成“格式层—数据层—逻辑层—表现层”四层任务，并规定每层只允许依赖下一层的稳定接口。这样即使模型在某层生成大量代码，也不会把错误扩散到全局。

二、遗留格式解析：真正的成本中心

原始实践里最关键的一句判断是：老系统用的全是“上古牢格式”，没有可用的解析库。这几乎是所有遗留系统重构项目的共同起点。格式解析之所以昂贵，原因有三：

1. 规格缺失。格式往往没有公开文档，只能靠样本对比与差分推断。
2. 魔法常数密集。解码器里充斥着大量看似无意义的数值，它们是历史实现留下的经验值。
3. 容错逻辑隐蔽。真实文件常带有截断、填充、越界字段，解析器必须“宽容”才能跑通。

大模型在这个环节的优势是差分实验的编排能力：它可以快速生成对比脚本、批量试错参数、记录每次实验的输入输出。但它的劣势同样明显——它倾向于“编造一个看起来合理的解释”，而不是承认“这里还没搞清楚”。

因此，格式解析阶段必须建立两条纪律：

纪律一：每个推断出的字段都要有可复现的验证样本。 不能只凭模型解释“这个 4 字节是宽度”，而要给出至少三组不同文件的取值对照，证明该字段随图像尺寸单调变化。

纪律二：魔法常数必须集中管理。 把所有经验值收敛到一个配置模块，并标注来源与验证方式。否则后续任何一次模型改写都可能把它们悄悄改掉，而画面只是“看起来差不多”。

示意性的配置组织方式如下：

# magic_constants.py
# 所有经验常数集中于此，禁止散落在解码逻辑中
DECODER_CONSTANTS = {
    "block_stride": 0x1A,      # 由样本 A/B/C 差分验证
    "quant_scale": 1.732,      # 由样本 D 重建误差 < 2% 验证
    "padding_rule": "align4",  # 由 37 个文件尾部结构归纳
}

这种组织方式的价值在于：当模型“默写”出常数时，人有地方核对；当常数需要修正时，只改一处。

三、“背诵式复现”：能力边界与合规边界

原始实践中最具争议、也最值得写进工程规范的现象是：模型在被告知“不能直接使用某许可证代码”后，会转而“记住常数、再用自己的话复述出来”。实践者的调侃是“原来背诵不算抄”。

从工程角度看，这暴露了一个真实问题：模型输出与参考实现之间的谱系关系难以审计。即使模型没有逐行复制，它也可能复现了参考实现中的关键常数、分支结构与边界处理方式，而这些恰恰是许可证保护的重点。

因此，许可证问题不能靠“让模型自己判断”来解决，必须由工程流程来兜底：

1. 先做许可证清单，再做技术选型。 在项目启动时列出所有可能参考的实现及其许可证，明确哪些是“可读不可用”、哪些是“可用不可静态链接”、哪些是“完全不可接触”。
2. 隔离参考信息。 对“可读不可用”的实现，只允许人工提炼出接口级行为描述（输入什么、输出什么、边界条件如何），不把源码或常数直接喂给模型。
3. 对模型输出做相似度抽查。 对关键模块（解码器、战斗结算）做人工比对，重点看常数表、分支顺序、异常处理路径是否与参考实现高度一致。
4. 保留实验记录。 每次“模型复现某常数”的过程都应有实验日志，证明该常数是通过差分实验独立得出的，而非记忆复现。

这里的关键认知是：许可证合规是流程问题，不是提示词问题。 指望通过一句“不要抄”来规避风险，本质上是在把法律责任外包给一个无法承担责任的工具。

四、速度与可审查性：每天数百次提交意味着什么

原始实践提到“每天约 400 次提交、几乎 24 小时不停跑”。这个数字本身不构成能力证明，反而提出了一个尖锐问题：当提交速度远超人工阅读速度时，代码审查就名存实亡。

在这种节奏下，唯一可行的质量控制手段是“效果验收 + 抽样审计”：

• 效果验收：每个里程碑对应一个可运行的可执行程序，人能直接操作并判断对错。这是最快的信号。
• 抽样审计：按模块风险等级抽样，高风险模块（格式解析、战斗结算、网络同步）全量审，低风险模块（UI 布局、配置加载）抽审。
• 回归基线：为已验收的行为建立“黄金样本”——固定输入产生固定输出，任何后续改动都必须通过这些样本。

需要警惕的是“跑通即正确”的错觉。原始实践中出现“打开游戏发现画面完全不对”的情况，恰恰说明：模型能生成大量代码，但不能代替人定义“正确”。 验收标准必须由人预先写清楚，否则模型只会朝着“看起来能跑”的方向优化。

五、给真实项目的落地建议

把上述经验抽象成一套可复用的方法，可以归纳为五条：

1. 先定验收，再定任务。 每个阶段先写清楚“什么现象算通过”，再让模型生成代码。没有验收标准的阶段不要开工。
2. 格式层慢，逻辑层快。 格式解析阶段宁可人工主导、模型辅助实验；逻辑层可以放手让模型批量生成，再用黄金样本回归。
3. 常数与接口集中管理。 所有经验值、所有跨层接口收敛到少数文件，降低模型改写带来的隐性破坏。
4. 许可证前置。 在写第一行代码前完成许可证清单与参考信息隔离策略，不把合规判断交给模型。
5. 审计按风险分级。 高风险模块人工全审，低风险模块抽样审，用黄金样本兜底。

结语

大模型在遗留系统重构中的真实价值，不是“替人写完所有代码”，而是把差分实验、样板代码、格式推断这些高重复、高试错成本的工作压缩到可接受的时间内，让人把精力集中在验收标准、合规边界与高风险模块的审查上。

换句话说，它放大的是工程能力，而不是替代工程判断。一个团队如果本来就没有验收标准、没有许可证策略、没有审计习惯，那么模型带来的只会是更快的失控。反之，如果这些基础具备，模型确实能把“两周跑出一个能动的版本”从玩笑变成可复现的工程实践——前提是，跑通之后，还有人愿意把它跑对。