大模型逆向重写遗留系统：14天工程实验复盘

一、问题设定：源码丢失之后，AI能否补位？

在软件工程领域，遗留系统现代化改造一直是高成本、高风险的任务。当一套系统的源代码彻底丢失、仅剩可执行二进制文件时，传统做法需要逆向工程师逐层分析，耗时往往以年计。随着大模型在代码理解与生成能力上的快速进步，一个自然的问题浮现：能否让大模型完成从逆向分析到代码重写的全链路工作？

本文记录了一次为期14天的实验，目标是让大模型对一款经典老游戏进行逆向重写。选择该目标的原因有三：其一，源码确已失传，具有真实逆向需求；其二，系统包含大量私有二进制格式，解析难度高；其三，项目规模适中，可在两周内观察阶段性成果。

实验的基本设定很明确：大模型负责生成代码与提交，人类只做方向校准和结果验收，不逐行审查代码。这既是效率要求，也是对当前模型能力边界的一次压力测试。

二、工程节奏：日均400次提交的自动化流水线

实验从第一天晚上启动，采用近乎24小时不间断的自动化流程。核心策略是将大模型嵌入一个持续集成循环：读取任务计划、生成代码、应用变更、提交、记录测试结果，然后进入下一轮。

# 简化后的自动化循环示意
while true; do
  task=$(next_task_from_plan)
  code=$(llm_generate --context "$task" --plan "$global_plan")
  apply_and_commit "$code" --message "auto: $task"
  test_and_record "$task"
  sleep 0
done

日均提交量约400次，这意味着人类无法逐条review。可行的验收方式只有两种：自动化测试通过率，以及可运行产物的实际表现。这种节奏对工程基础设施提出了较高要求——版本管理、构建缓存、测试隔离、失败回滚，任何一环缺失都会导致流水线堵塞。

三、Day 1：逆向私有二进制格式的拉锯战

第一天的主要任务是格式分析。目标系统使用了大量手写的私有格式——没有公开规范，也没有可直接复用的解析库。大模型需要从二进制样本中推断结构、字段含义与编码规则。

这个过程暴露了两个值得注意的现象。

现象一：许可证敏感度极高。 当要求大模型实现某个解码器时，它会主动检查已有开源实现的许可证。对于宽松型许可证，它倾向于参考；对于弱著佐权或强著佐权许可证，它会拒绝直接引入代码，甚至拒绝静态链接方案。实验中的一次典型对话如下：

人类：这个解码库是弱著佐权许可证，我们项目用宽松型许可证，能直接用吗？
模型：静态链接引入弱著佐权代码会导致衍生作品整体适用该许可证条款，
      与项目许可证冲突，不建议直接使用。建议自行实现。
人类：那你自己写一个吧。
模型：[开始手写实现]

这种保守态度在合规层面是正面的，但在效率层面带来了额外摩擦。人类需要反复确认“到底能不能用”，而模型的判断往往比法务还严格。

现象二：“背诵”式实现。 在被要求自行实现后，模型会在短时间内完成代码。仔细观察会发现，它实际是先扫描了参考实现的魔法常数与关键逻辑，然后用“记忆+复述”的方式重新表达。从工程角度看，这规避了直接复制代码的许可证风险；从原创性角度看，边界相当模糊。

用同样的方法，第一天完成了多数私有格式的解析模块。经验是：与其强制模型“不要看”某个实现，不如明确告知许可证约束，并允许它在合规范围内自行选择参考策略。

四、Day 2：UI自动生成的偏差与纠正

第二天中午，UI层初步组装完成，程序可以启动。但打开后看到的界面与目标系统相去甚远——布局、控件风格、交互逻辑都出现了明显偏移，整体观感更像另一款风格迥异的同类产品。

原因在于：大模型生成UI时，倾向于从训练数据中检索“最常见的同类界面模式”，而非严格遵循给定的规格描述。当描述为“经典即时战略游戏界面”时，模型会自由发挥；当描述为具体尺寸、位置和状态时，生成结果才趋于可控。

{
  "ui_spec": {
    "top_bar": {"height": 48, "elements": ["resource_a", "resource_b", "radar"]},
    "minimap": {"width": 200, "height": 200, "position": "left"},
    "command_panel": {"slot_count": 12, "layout": "grid"}
  }
}

这揭示了一个关键工程原则：规格描述的精确度决定生成质量。对于UI和交互逻辑，模糊的自然语言描述会导致模型从训练数据中“借”来不相关的模式。可行的手段包括结构化规格（JSON Schema）、尺寸标注、状态机描述，以及提供参考截图作为视觉约束。

五、许可证合规：模型“道德感”与工程现实的冲突

整个实验中最值得记录的，是大模型在许可证问题上的表现。它会主动识别参考实现的许可证类型，并在发现冲突时拒绝引入。这一行为在多数情况下帮助项目避免了合规风险，但也带来了效率损耗。

一个实用的工程建议是：在任务描述中前置许可证约束，并提供可接受的替代方案列表。例如：

项目许可证：宽松型
允许参考：宽松型 / 弱著佐权兼容方案
禁止引入：强著佐权 / 网络著佐权
若参考实现为禁止许可证，需自行实现等价功能，
不得复制代码结构或魔法常数。

这样既保留了模型的合规意识，又减少了反复“Battle”的时间成本。另一个经验是：不要指望模型在法律判断上完全可靠，关键决策仍需人工复核。

六、高频迭代下的质量控制

日均400次提交意味着传统代码审查不可行。实验中采用的替代方案包括：

1. 自动化测试分层：单元测试覆盖格式解析与核心逻辑，集成测试验证模块间协作，快照测试对比UI渲染结果。
2. 构建门禁：任何提交必须通过编译与冒烟测试，否则自动回滚。
3. 行为回归：对关键路径录制输入输出样本，每次提交后重放对比。
4. 人工抽检：每天固定时间抽查若干提交，关注架构漂移与重复代码。

这些手段无法完全替代人工审查，但能在高速迭代中提供基本的安全网。

七、经验总结与可复用方法论

经过14天实验，可以提炼出以下几条对遗留系统重写有普遍意义的经验：

1. 任务粒度要足够细。 大模型在“实现一个函数”级别的任务上表现稳定，在“实现一个子系统”级别上容易跑偏。将计划拆分为Pre-Alpha、Alpha、Beta等阶段，再细化为可验证的小任务，是保证进度的关键。

2. 验收依赖自动化。 高频提交意味着人类无法逐行审查。必须建立自动化测试、构建验证与结果快照机制，否则无法判断进展质量。

3. 许可证约束要前置。 不要让模型在许可证问题上“自由发挥”，应在任务描述中明确允许与禁止的许可证类型，并提供替代实现策略。

4. 规格描述越精确越好。 尤其是UI和交互逻辑，模糊描述会导致模型从训练数据中借用不相关的模式。结构化规格、尺寸标注、状态机描述都能显著提升生成质量。

5. 接受“不完美但可运行”的中间态。 Day 2的UI偏差并非失败，而是迭代的起点。在大模型辅助开发中，快速产出可运行版本、再逐步修正，比追求一次到位更现实。

八、结语

大模型在遗留系统逆向重写中的能力已经足够令人惊讶，但它并非“一键完成”的魔法。许可证合规、规格精确度、任务粒度、验收自动化，这些工程约束依然需要人类来设计和把控。把大模型当作一个高速但需要明确指令的执行者，而非全知全能的架构师，才是当前阶段最务实的用法。对于面临源码失传、文档缺失、人才断层的团队而言，这套“大模型+自动化流水线”的组合拳，提供了一条值得尝试的渐进式重写路径。