OpenAI 测了 AI 迁移 COBOL：准确率 97.9%，但离接管遗留系统还差几步

InfoQ 中文 2026-10-21T23:00:29+08:00

OpenAI 发布针对低资源编程语言的最新评测：COBOL 代码迁移准确率从上一代的 5.4% 提升到 97.9%，在 20 种语言上从零实现 SQLite 兼容引擎的平均通过率达到 87.4%。数据很亮眼，但评测环境仍是受控的，和真正把银行、保险的核心系统交给 AI 并不是一回事。

几十年没人敢动的代码，AI 以前也看不懂

银行、保险、制造业和公共服务机构里，有不少核心系统已经运行了几十年。它们可能用 COBOL、Fortran 这类今天并不流行的语言写成，最初的开发者早已离职，技术文档未必齐全，很多业务规则只存在于代码本身。

这些系统不一定经常出故障，但极难修改。对企业来说，重写一套旧系统的难度有时超过从零开发一套新系统——开发团队不仅要读懂几十年前的代码，还得保证迁移之后，账目计算、数据处理以及各种异常情况下的业务行为与原系统完全一致。

AI 编程工具的出现曾让人期待这类问题能被解决。但过去几年，大模型最擅长的仍是 Python、JavaScript 等主流语言。碰到历史悠久、公开训练数据稀缺的语言，以及高度定制的企业代码库，它们的表现往往不够可靠。

10 月 19 日，OpenAI 发布了一项针对低资源编程语言的研究，试图改变这一局面。

在 COBOL 代码迁移评测中，上一代 GPT-5.6 Sol 在低推理强度下的准确率只有 5.4%；最新 GPT-6.1 Sol 在相同推理强度下达到 86.6%，提高推理强度后进一步升至 97.9%。OpenAI 同时公布的另一项测试覆盖 20 种编程语言，要求 AI 从零实现一个兼容 SQLite 的数据库引擎：GPT-6 Astra 平均测试通过率为 87.4%，上一代 GPT-5.6 Sol 仅为 26.8%。

这些数字说明，AI Coding 的能力正在向过去相对薄弱的语言扩展。但即便 AI 能在评测中完成复杂的跨语言代码迁移，企业是否就能放心把运行几十年的遗留系统交给它？这个问题还没有答案。

OpenAI 开始补 AI 编程的短板

这项研究的重点是“低资源编程语言”（Low-Resource Programming Languages）。“低资源”不是说这些语言不重要，而是指相比 Python、JavaScript 等流行语言，模型能学到的公开代码、技术文档和其他训练材料相对有限。

COBOL 是典型例子。这门诞生于 1959 年的语言，至今仍在全球金融交易和大型机系统中承担重要工作。OpenAI 援引 IBM 的资料指出，COBOL 支撑着大量在线银行、信用卡交易和 ATM 系统。此外，Fortran 仍用于天气预报、科学计算和核反应堆安全分析；Visual Basic、OCaml 等语言也各有自己的存量系统和应用场景。

对 AI 模型来说，这些语言带来两类不同挑战：一是能不能用它们编写复杂的新程序，二是能不能准确理解已有程序，并把它迁移到另一种语言。

为了分别衡量这两种能力，OpenAI 设计了两项评测。

MultiLangBench：20 种语言从零写一个 SQLite

第一项评测名为 MultiLangBench，要求模型用指定语言从零构建一个与 SQLite 兼容的数据库引擎。这不是生成几段 SQL 查询那么简单：模型需要持续组织代码库、管理状态、处理异常、添加功能，还要保证此前已经完成的功能不会在后续修改中被破坏。

评测以数据库文件作为统一接口：待测程序接收初始数据库和 SQL 查询，输出修改后的数据库，再与 SQLite 参考实现逐项比较。这样，不同语言写出的程序就能接受同一组功能测试。

结果显示，GPT-6 Astra 在 20 种语言上的平均测试通过率为 87.4%。其中 OCaml 从上一代的 25.6% 提升至 85.8%，Fortran 从 21.4% 提升至 83.5%，Visual Basic 从 27.5% 提升至 89.4%。

COBOL 仍是其中最难的一门。GPT-6 Astra 在 COBOL 上的通过率为 72.1%，虽然远高于上一代的 10.9%，但与其他语言仍有差距。

值得一提的是，OpenAI 这次公开了 MultiLangBench 的评测代码和测试套件，开发者可以查看各语言的测试方式与结果。对关注 AI 编程工具实际能力边界的团队来说，这比只看一个总分更有参考价值。

相比常见的算法题和单文件编程测试，MultiLangBench 更接近真实开发中的持续实现、调试和回归测试。但它终究是受控环境，不能直接等同于大型企业系统的开发能力。

COBOL 迁移 97.9%：难的不是翻译代码

第二项评测才是这次研究最值得关注的部分。

OpenAI 要求模型把现有 COBOL 程序迁移到 C++、Java、Kotlin、Python 或 Rust，同时保留原程序的行为。

表面看，这是一个代码翻译任务。但对真正做过遗留系统迁移的开发者来说，代码能编译成功，距离迁移成功还差得很远。

金额算错一分钱，也可能让迁移失败

以金融系统常见的金额计算为例。COBOL 对定点数运算有自己的一套规则：在某些情况下，如果程序没有明确指定四舍五入，超出精度的部分会被直接截断。假设旧程序一直按这个规则算钱，而迁移后的 Java 或 Python 程序采用了另一种默认舍入方式，那么新程序可能没有语法错误，也能正常跑完，但算出来的结果就是不一样。

对普通应用来说，这种差异也许只是一个小 Bug；但在金融结算、账务核对等场景里，细微的数值偏差可能带来严重后果。类似的问题还包括：缺失记录怎么处理、异常输入怎么响应、字符串和数字怎么转换，以及程序对既有数据格式的依赖。

很多时候，这些行为并没有写进设计文档，而是藏在长期运行的代码里。更麻烦的是，有些看上去不太合理的实现，可能恰恰承载着企业必须保留的历史业务规则。

所以，OpenAI 没有简单地把“代码生成成功”当作评测标准，而是用隐藏测试检查迁移前后程序的可观察输出是否逐字节一致。只有全部测试通过，一个迁移任务才算成功。

根据 OpenAI 公布的结果：

这意味着，至少在 OpenAI 构建的评测任务中，模型不仅能把手里的旧代码转换成新语言，还能在很高比例的任务上保持原有程序的可观察行为。

97.9% 到底说明了什么

97.9% 的准确率，并不代表“大型 COBOL 系统有 97.9% 的代码可以正确迁移”，更不意味着银行可以把核心业务系统直接交给 AI 自动重写。这个数字衡量的是特定任务在隐藏测试下的成功比例。真实企业系统的规模、复杂度、外部依赖、数据状态和运行环境，可能远远超出评测覆盖范围。即使通过了现有测试，也不能证明迁移后的程序在所有未知输入和业务边界条件下都跟原系统完全一致。

OpenAI 在研究中也明确指出，要把这些能力用到生产软件上，仍然需要专家审查，并针对业务规则与系统依赖做测试。

但准确率从 5.4% 到 97.9% 的提升仍然值得注意。过去，模型可能连一个相对完整的迁移任务都很难做对；现在，问题正在逐渐变成：模型生成的结果，需要怎样的验证体系才能进入生产环境？对正在使用 AI 编程工具的开发者来说，这也是一个很现实的提醒——生成代码只是第一步，真正难的是证明新代码在旧业务规则下仍然算得对。

一年前，AI 主要还在帮程序员读懂老代码

利用 AI 改造遗留系统，并不是刚刚出现的新方向。2025 年 6 月，InfoQ 曾报道摩根士丹利内部 AI 工具 DevGen.AI 的实践。当时，摩根士丹利披露，这套工具已经帮助开发团队审查了约 900 万行遗留代码，累计节省约 28 万小时的开发工作量。

延伸阅读：《手撕 900 万行屎山代码、少干 28 万小时！AI 编程大刀挥向“古老”编程语言》

DevGen.AI 基于 OpenAI 的 GPT 模型，由摩根士丹利内部开发团队构建。与普通 AI Coding 工具不同，它最重要的能力之一，是把 COBOL 等遗留语言编写的程序转换成自然语言形式的业务规范，帮助开发者理解系统功能，再由工程师根据这些规范进行改造。

这一方案背后有一个很现实的原因：熟悉某种旧语言的开发者越来越少时，即使企业找到了擅长 Java 或 Python 的工程师，他们也不一定能直接理解几十年前的 COBOL 代码。

借助 AI 生成业务规范，原本晦涩难懂的程序可以被转换成更容易审查和讨论的描述。开发者由此能够梳理系统功能、定位业务逻辑，并制定下一步迁移方案。

不过，摩根士丹利当时也承认，AI 在直接迁移完整代码方面还有明显不足。即使能够用新语言重新实现原程序，也不一定能充分利用目标语言的特性，生成高效、易维护的代码。

这恰好说明，遗留系统现代化面临两个不同层次的问题。第一个问题是理解：企业需要弄清楚既有系统究竟在做什么，以及其中哪些规则仍然需要保留；第二个问题是迁移：在完成理解之后，开发团队还需要用现代技术重新实现这些功能，并验证新旧系统的行为是否一致。

摩根士丹利的实践证明，AI 已经能够帮助工程师跨越第一道障碍。而 OpenAI 此次公布的评测，则展示了大模型在第二个问题上的能力进展。

当然，两者不能简单做量化对比。DevGen.AI 是运行在企业内部的实际工程工具，面向具有复杂依赖的真实代码库；OpenAI 新研究展示的则是标准化评测任务上的模型能力。但把这两种实践放在一起，可以明显看出，AI 参与遗留系统改造的技术路线正在拓宽：从代码解释、业务知识提取，到代码生成、迁移和行为一致性测试，AI 可以承担的环节越来越多。

对企业来说，接下来需要考虑的，是如何把这些能力组织成可靠、可审计的工程流程。

没有 COBOL，也照样有改不动的老系统

COBOL 是遗留系统现代化的一个典型案例，但企业面对的类似难题，远不止这一门编程语言。

一套运行了十几年的 Java 单体应用，往往积累了数百万行代码，牵扯大量接口、数据库表和复杂的外部依赖。最初参与开发的工程师早已陆续离开，技术文档长期没有更新，部分业务逻辑经过多轮修改，已经很难说清楚当初为什么这样实现。

这些系统未必用了过时技术，很多至今仍在稳定支撑企业核心业务。但每次做架构升级、数据库替换或服务拆分，开发团队都要面对同一个问题：改动一段代码之后，会不会破坏某条隐藏在历史实现里的业务规则？

有些改造甚至比跨语言迁移更复杂。比如把单体拆成微服务时，原本靠本地事务完成的业务操作，可能需要重新设计分布式事务、数据一致性和异常补偿机制。即便新系统的每个服务都通过了单元测试，也无法直接证明整个业务流程与旧系统保持一致。

这也是 OpenAI 这项研究价值不止于 COBOL 迁移准确率的原因。它展示的跨语言代码理解与生成能力，以及用可执行测试验证程序行为的思路，都可能用于更广泛的企业系统改造：从旧代码中提取业务规则、分析模块依赖、生成回归测试，或辅助重写特定模块，并对比新旧实现的行为差异。

当然，这次公布的评测还不足以证明模型能独立完成大型企业系统改造。跨服务依赖、复杂数据库状态、并发与故障处理，远比单个程序的输入输出测试复杂。

但这项研究至少给出了一个值得关注的信号：当 AI 越来越擅长理解和迁移那些训练数据稀缺、语义规则复杂的代码，它能参与的软件现代化工作，也有机会超越某一门特定语言，延伸到更广泛的企业系统改造场景。

AI 能改老代码，但谁来为上线负责？

当 AI 开始有能力迁移那些过去难以处理的老代码，一个更现实的问题随之出现：谁来确认 AI 改写的程序可以安全上线？

OpenAI 公布的两项评测，都把可执行测试作为衡量代码生成质量的重要依据。在 COBOL 迁移任务中，模型不仅要生成另一门语言的代码，还必须确保新程序在隐藏测试中的输出与原程序逐字节一致，也就是输出结果完全相同。

但企业真实系统远比评测环境复杂。对于已经运行十几年甚至几十年的业务系统，难点往往不只是代码能不能迁移成功，还在于有没有一套足够完整的测试体系，能证明迁移没有破坏原有业务。

大量遗留系统之所以难以改造，恰恰是因为原始设计文档缺失、测试覆盖不足，业务规则与代码实现高度耦合。

假如一个系统有数千万行代码，涉及不同地区、不同年代积累的业务规则，工程师很难提前枚举所有可能的输入与运行状态。即使 AI 成功完成了代码迁移，团队仍要回答：哪些行为已经验证，哪些边界情况还没覆盖？如果新旧系统给出不同结果，究竟是迁移出错，还是原系统本身就存在历史缺陷？

代码层面的行为一致，也只是现代化改造的一部分。企业通常还要重新考虑数据模型、接口兼容、事务处理、性能、部署环境与安全控制。即使新程序能产生相同的业务结果，它在并发负载下的性能、故障恢复方式，以及与外围系统的交互，也可能和原程序不同。

因此，真实项目里更稳妥的方式仍然是分阶段推进：先用 AI 辅助理解原代码及依赖关系，建立业务规则和测试基线；再选择边界相对清晰的模块进行迁移，在隔离环境中运行回归测试；最后通过新旧系统并行比对、人工审查和逐步切换，控制改造风险。

在这个过程中，AI 不一定需要一次性重写整套系统。它可以分别承担代码分析、测试生成、迁移实现和问题修复等任务，而关键的业务确认与上线决策，仍然要由工程团队负责。

对正在使用 AI 编程工具的团队来说，这也划出了一条清晰边界：生成代码只是第一步，能不能把 AI 产出安全地带进生产环境，取决于验证和回归测试做得多扎实。

对于国内正在推进系统升级、技术栈迁移和架构改造的企业，这类能力同样有现实价值。它们不是非得有一套 COBOL 系统，才会遇到历史代码难理解、业务规则难验证、改造风险难控制的问题。

从 5.4% 到 97.9%，OpenAI 展示了 AI 在特定代码迁移任务上的显著进展。随着模型对更多语言和复杂代码库的理解能力提升，企业有望降低遗留系统分析与改造的部分成本。不过，要把评测中的高准确率转化为生产环境中的可靠迁移，仍然需要完整的工程验证体系。

过去，遗留系统现代化的一大障碍，是没有足够的人能读懂和修改旧代码。随着 AI 编程能力提升，另一个长期存在的问题会变得更加突出：企业如何证明，改造后的系统仍然正确执行着那些积累了几十年的业务规则？这可能是 AI 真正进入企业核心系统之后，软件工程需要解决的下一道难题。

参考资料：

查看原文