为什么 AI 翻译的 COBOL 会让您的数据库崩溃

问题所在

一家大型银行让 AI 把三十年的 COBOL 代码重写为 Java。AI 完美地翻译了语法。代码编译通过。单元测试全部通过。然后，第一笔交易就让数据库崩溃了。

这次失败与糟糕的代码毫无关系。那段 Java 在语法上无懈可击。问题出在一个隐藏的依赖上——一个名为 TRN-LIMIT 的变量，它定义在一个共享头文件中，距离 AI 实际翻译的代码有数千行之远。该头文件包含一个 REDEFINES 子句，这是 COBOL 的一项特性，允许同一个内存地址根据在另一个完全不同的模块中设置的标志来持有两种不同的数据类型。AI 从未看到这一切。它把 TRN-LIMIT 当成了简单的数字。实际上，它是一个压缩十进制数（packed decimal）。这种不匹配导致该 Java 应用程序向数据库写入了损坏的二进制数据，进而引发引用完整性故障。

这并非边缘案例。研究表明，70% 到 80% 的遗留系统现代化项目未能达成目标。您的组织当前赖以运转的关键系统，其代码年限很可能超过大多数员工的年龄。如果您正在规划一次迁移——或者已经身处其中——这种失败模式应当令您深感警惕。AI 并没有打错一个字，它遗漏的是一种它根本看不见的关系。这是一种本质上截然不同的风险，而目前大多数工具对此束手无策。

为什么这对您的业务至关重要

这里涉及的财务风险敞口是巨大的，而且触及您资产负债表上的每一行。

仅在美国，技术债务就已达到约 1.52 万亿美元。如果您的组织运行着遗留系统，那么您此刻就承担着其中一份负担。大约 80% 的联邦 IT 预算用于运营和维护——留给任何新事务的只有 20%。银行业的风险敞口尤为突出：43% 的银行系统仍在 COBOL 上运行，而这些系统处理着 全部 ATM 交易的 95%。

以下是这些事实对您风险状况的具体影响：

• 安全风险敞口增至三倍。 与现代应用相比，年限超过十年的系统在统计上遭遇数据泄露的可能性是前三倍。您的现代化每拖延一个季度，攻击面就会扩大一分。
• 合规要求不断收紧。 GDPR 和 DORA 等法规要求实时报告和数据隐私控制。遗留系统的设计初衷并不包含这些要求。您无力适应，正在变成监管机构终将注意到的合规风险。
• 您的专家正在离开。 编写这些系统的开发人员正在退休。58% 的开发人员表示，因为遗留技术栈他们曾考虑离职。当机构知识随人走出门时，您的维护成本会进一步攀升。
• 失败的迁移浪费数百万。 面对 70% 至 80% 的失败率，胜算并不站在您这边。一场搞砸的迁移不只是赔上项目预算——它会损害人们对贵方技术领导力的信心，并延误您的团队翘首以待的业务能力落地。

您的董事会想要数字化转型。您的监管机构想要现代化的控制措施。您的预算为维持系统运转已经捉襟见肘。您承受不了一次悄无声息地走向失败的迁移。

底层究竟发生了什么

要理解标准 AI 为什么会在这件事上失败，不妨把您的代码库想象成一座城市。每个函数、每个变量、每张数据库表都是一栋建筑。它们之间的连接——哪个函数调用哪个函数、哪个变量供给哪个计算——就是道路。

现在想象一下，您递给某人一本记录城中每栋建筑的名册，请他重新设计公共交通系统。他手上有名称和地址，却没有地图。他看不到哪条道路连接哪几栋建筑。这正是标准 AI 编码工具对待您代码的方式：它读取文本，却看不见结构。

这种具体的技术失败被称为“迷失在中间”（Lost in the Middle）效应。大型语言模型——编码助手等工具背后的 AI 引擎——通过注意力机制处理文本。研究已经证明，这类模型对长输入开头和结尾的信息具有很强召回能力，但对埋在中间部分的信息，性能会急剧下降。在一个绵延数千行、还引用外部文件的 COBOL 程序中，关键的变量定义往往恰好落在这个盲区里。

当 AI 遗漏了某个定义时，它不会停下来询问，而是径直猜测——用统计上看似合理、事实上却错误的内容填补空缺。用 AI 术语来说，这叫幻觉。在您的银行系统里，这意味着 AI 可能把一个变量当成整数，而它实际上是压缩十进制数。仅仅这一个错误假设，就可能损坏财务数据、破坏数据库完整性，并让交易系统停摆。您的代码编译通过。您的测试通过。您的生产环境却失败了。

什么行得通（什么行不通）

我们先从您的团队可能已经尝试过或考虑过的做法讲起——以及为什么每一种方法都有不足。

整体搬迁（Rehosting，重新托管）： 您把编译好的应用程序搬到云端模拟器上。这改变了您的托管账单，却原封不动地保留了每一行盘根错节的遗留代码。您把全部技术债务带进新环境，却没有换来云的丝毫灵活性。

手动重写： 您聘人手工把一切重写为 Java。这慢得痛苦、贵得离谱，而且依赖于既懂 COBOL 又懂现代架构的人才。随着您的 COBOL 专家陆续退休，这条路一年比一年难走。

AI 包装工具： 您把一个商业 AI 编码助手指向您的代码库。它能快速翻译语法。但正如那家银行的失败所表明的，它会遗漏跨文件依赖、幻觉出不存在的变量定义，产出看起来正确、行为却错误的代码。

真正有效的方法是这样的——一种基于图谱的路线，它把您的代码视为一个相互连接的系统，而不是一堆文本文件：

1. 解析结构，而不只是解析文本。 不把代码切成任意的文本块，而是把每个文件解析成一棵代表其逻辑结构的树——每个变量、每个函数、每个控制流分支都在其中。这确保 AI 尊重代码自身的边界。一个函数被当作完整的逻辑单元，而不是随机的一段文字切片。

2. 绘制每一条关系的地图。 您提取代码库中的每一个连接——哪些模块调用哪些子程序、哪些文件定义哪些变量、哪些函数更新哪些数据库表——并把它们存入知识图谱。当 AI 需要翻译一个支付函数时，它不会只抓取提到“支付”二字附近的文本，而是沿着真实的依赖链，把每一个变量定义、每一个共享头文件和每一处下游影响都拉进来。这就是 Veriprajna 所称的 仓库感知知识图谱（Repository-Aware Knowledge Graph），它直接解决了“迷失在中间”问题。

3. 对照地图验证每一个输出。 AI 生成 Java 代码后，会在沙箱中编译它。如果编译器抛出错误——比如说缺少某个变量——系统就查询图谱、定位依赖并重新生成代码。这个编译-修复循环自动运行。您的开发人员审核的是经过验证的输出，而不是 AI 的原始猜测。

对您的合规与审计团队而言，最关键的优势在于：AI 做出的每一个决策都可追溯。知识图谱准确记录了 AI 为什么导入某个特定的库、为什么以某种方式定义某个变量。您得到的不是黑箱，而是一条引用链。您的审计人员可以看到每一行生成代码背后的完整逻辑轨迹。

这种方法还能在迁移开始之前消除浪费。知识图谱能识别死代码——即系统中实际上没有任何东西调用的函数。清除死代码通常能让代码库缩减 20% 到 30%，这意味着更低的迁移成本和一个更干净的最终系统。

对于 金融服务 等面临监管审查行业中的组织来说，这种透明度绝非可有可无。此外，如果您的现代化改造需要跨系统追踪数据血缘，Veriprajna 的 数据溯源与可追溯性 能力可以把同样的基于图谱的方法延伸到您的整个数据管道。

您可以 阅读完整的技术分析 了解其中的工程细节，或者 探索交互式版本 ，直观了解知识图谱在实践中是如何运作的。