当AI把一亿行老代码翻译成新语言：三代维护者的代价，和一个推论

某家银行的核心系统里有一个字段，长度是 17 位，多一位少一位都会让月末对账出错。没有人记得为什么是 17。注释在 1994 年的一次迁移里丢了，能解释的人去年退休了。

这样的字段在全国的金融、电力、铁路、社保系统里有几百万个。它们构成了一个很少被讨论的事实：现代社会的关键基础设施，跑在一批没人完全读得懂的代码上。

趋势：从「重写」变成「翻译」

过去二十年，替换老系统的标准做法是重写：把业务重新梳理一遍，用新语言重新实现。周期以年计，失败率极高，很多项目做到一半被叫停。重写的难点从来不是写新代码，是把二十年的隐性规则重新发现一遍。

2020 年 4 月，美国新泽西州的失业申报系统在几周内被几十万份申请压垮，州政府公开招募会 COBOL 的程序员来改。那一次让很多人第一次意识到，老语言不是历史遗迹，是在运行的基础设施。

此后几年，厂商开始推出「翻译」路线：不重新设计，直接做语句级迁移，让新代码在行为上等价于旧代码。这条路绕开了最难的环节——理解，它只要结果一致。

到 2026 年，这条路已经能跑通。一批模型可以在几个月内处理过去要几年的代码量，配套的等价性测试工具也成熟了。迁移的瓶颈从「人力」变成了「验证」。

顺便说一句存量规模。常被引用的数字是「全球仍有 2000 亿行以上的 COBOL 在运行」，这个数字来自不同机构的估算，口径差异很大，按未确认处理。但无论取哪个版本，量级都足以支撑一个行业。

他们大多五十五岁以上，在这套系统上待了二十到三十年。他们读代码的方式和别人不同——看到一段奇怪的判断，能想起 1987 年某次审计之后加的临时规则。

这些知识从来没有被完整写下来。它藏在变量名里、藏在没人敢删的死代码里、藏在「这里不能动」的口头传承里。它不被记录，是因为当年没人认为需要记录。

AI 迁移对这批人的影响是双面的。一方面，他们终于不用再手改一行行代码；另一方面，他们成了这套系统唯一的人形备份，而备份是不需要留到迁移完成的。项目结束那天，他们的价值会一次性归零。

更微妙的是，他们中的很多人并不反对。他们清楚这套系统迟早要换，也乐见它被换掉。代价不是被强迫，是被顺利地替代。

这一代是三四十岁的迁移工程师。他们的工作方式是：拿旧系统的输入输出做基准，让模型生成新实现，然后跑对比测试，差异清零就算完成。他们的 KPI 是等价率，不是理解度。

这套方法在工程上是对的。等价性测试能覆盖绝大多数行为，剩下的一小部分被标记为「已知差异」，写进文档，然后被忘掉。那 0.3% 的差异，通常在三年后的某次对账里才会现形。

他们确实解决了上一代人解决不了的问题，也顺手删掉了系统里唯一一份「理由」的载体。旧代码虽然难读，但它的每一处怪异都有痕迹；新代码干净、规范、一致，因此什么也看不出来。整洁本身就是一种信息损失。

这一代人的代价不在当下，在他们四十多岁的时候。他们既不像上一代那样懂业务的历史，也不像下一代那样从出生就与 AI 协作。他们是唯一亲手抹掉证据的一代，也是唯一知道自己抹掉了什么的一代。

2030 年之后入职的人，看到的是一套干净的 Java 或 Go 服务，注释齐全，测试覆盖率 85%。他们看到的不是历史，是历史的译文。

译文读起来合理。合理的代码有一个特点：它看起来每处都有理由，实际上很多处只是「模型当年这么写的」。当一个系统的每一行都有解释，它反而失去了可疑之处。

这一代人遇到的第一个真问题，会出现在需要判断「这段逻辑是不是错的」的时候。他们能验证「行为是否与旧系统一致」，但没法验证「旧系统的行为本身是否正确」。基准是上一代给的，而上一代已经不在了。