几十年前写下的代码，今天还有多少人看得懂？
在银行、保险、制造业以及公共服务机构，一些核心业务系统已经运行了数十年。它们可能使用 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 已经能够在评测中完成复杂的跨语言代码迁移，企业就真的可以放心把那些运行几十年的遗留系统交给 AI 了吗？
OpenAI 开始挑战 AI 编程的薄弱环节
这次 OpenAI 研究的重点是所谓的“低资源编程语言”（Low-Resource Programming Languages）。这里的“低资源”并不意味着这些语言不重要，而是指相较于 Python、JavaScript 等流行语言，它们可供模型学习的公开代码、技术文档及其他训练材料相对有限。
COBOL 就是一个典型例子。这门诞生于 1959 年的编程语言，至今仍在全球金融交易和大型机系统中承担重要工作。OpenAI 在文章中援引 IBM 的资料指出，COBOL 支撑着大量在线银行、信用卡交易和 ATM 系统。除此之外，Fortran 仍被用于天气预报、科学计算及核反应堆安全分析；Visual Basic、OCaml 等语言，也拥有各自的存量系统和应用场景。
对于 AI 模型来说，这些语言带来了两类不同的挑战：一类是能不能使用它们编写复杂的新程序，另一类则是能不能准确理解已有程序，并将其迁移到另一种语言。
为了分别测量这两种能力，OpenAI 设计了两项评测。第一项名为 MultiLangBench，要求模型在指定编程语言中，从零构建一个与 SQLite 兼容的数据库引擎。这不是简单生成几段 SQL 查询代码。模型需要持续组织代码库、管理状态、处理异常、添加功能，并确保此前已经完成的功能不会在后续修改中失效。
评测通过数据库文件作为统一接口：待测程序接收初始数据库和 SQL 查询，生成修改后的数据库，再与 SQLite 参考实现进行比较。这样一来，不同语言生成的程序就可以接受同一组功能测试。
OpenAI 公布的结果显示，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 的评测代码与测试套件，开发者可以查看各语言的测试方式及结果。
相比常见的算法题和单文件编程测试，这项评测更接近真实软件开发过程中的持续实现、调试和回归测试。但它仍然处于受控环境，不能直接等同于大型企业系统的开发能力。
而第二项评测，才是这次研究中最值得关注的部分。
COBOL 迁移准确率达到 97.9%，难点究竟在哪里？
OpenAI 的第二项评测要求模型将现有 COBOL 程序迁移至 C++、Java、Kotlin、Python 或 Rust，同时保留原程序的行为。
表面上看，这是一个代码翻译任务。但对于真正做过遗留系统迁移的开发者来说，代码能够成功编译，距离迁移成功还有很长的距离。
以金融系统常见的金额计算为例。COBOL 具有特定的定点数运算语义。在某些情况下，如果程序没有明确指定四舍五入，超出精度的部分会直接被截断。假设原有程序按照这一规则计算金额，而迁移后的 Java 或 Python 程序使用了另一种默认舍入方式，那么新程序可能完全没有语法错误，也能够正常执行，却会得到不同的计算结果。
对于普通应用，这种差异也许只是一个不起眼的 Bug；但在金融结算、账务核对等场景中，细微的数值偏差可能产生严重后果。类似的问题还包括缺失记录如何处理、异常输入如何响应、字符串与数字如何转换，以及程序对既有数据格式的依赖。
很多时候，这些行为并没有被写进设计文档，而是隐藏在长期运行的代码中。更麻烦的是，有些看上去不够合理的实现，可能恰恰承载着企业必须保留的历史业务规则。
因此，OpenAI 没有简单地以“代码生成成功”作为评测标准，而是使用隐藏测试检查迁移前后程序的可观察输出是否逐字节一致。只有通过全部测试，一个迁移任务才被视为成功。
根据 OpenAI 公布的结果：
GPT-5.6 Sol 在低推理强度下，迁移准确率为 5.4%。
GPT-6.1 Sol 在相同推理强度下，准确率提升至 86.6%，估算 API 成本还降低了 39%。
GPT-6.1 Sol 在更高推理强度下，准确率进一步达到 97.9%。
这意味着，至少在 OpenAI 构建的评测任务中，模型不仅能够将旧代码转换成新语言，还能在很高比例的任务上保持原有程序的可观察行为。
不过，97.9% 的准确率并不代表“大型 COBOL 系统有 97.9% 的代码可以正确迁移”，更不意味着银行可以将核心业务系统直接交给 AI 自动重写。这个数字衡量的是特定任务在隐藏测试下的成功比例。真实企业系统的规模、复杂度、外部依赖、数据状态和运行环境，可能远远超出评测覆盖范围。即使通过现有测试，也不能证明迁移后的程序在所有未知输入和业务边界条件下都与原系统完全一致。
OpenAI 在研究中也明确指出，将这些能力应用于生产软件，仍然需要专家审查，并针对业务规则与系统依赖进行测试。
但准确率从 5.4% 到 97.9% 的显著提升，仍然是一个不可忽视的进步。过去，模型可能连一个相对完整的迁移任务都很难做对；如今，问题正在逐渐转向：模型生成的结果，究竟需要怎样的验证体系才能进入生产环境？
一年前，AI 还只能做到帮程序员读懂老代码
实际上，利用 AI 改造遗留系统，并不是一个刚刚出现的新方向。2025 年 6 月，InfoQ 曾报道摩根士丹利内部 AI 工具 DevGen.AI 的实践。当时，摩根士丹利披露，这套工具已经帮助开发团队审查了约 900 万行遗留代码，累计节省约 28 万小时的开发工作量。
DevGen.AI 基于 OpenAI 的 GPT 模型，由摩根士丹利内部开发团队构建。与普通 AI Coding 工具不同，它最重要的能力之一，是将 COBOL 等遗留语言编写的程序转换成自然语言形式的业务规范，帮助开发者理解系统功能，再由工程师根据这些规范进行改造。
这一方案背后，有一个非常现实的原因：当熟悉某种旧语言的开发者越来越少时，即使企业找到了擅长 Java 或 Python 的工程师，他们也不一定能够直接理解几十年前的 COBOL 代码。
借助 AI 生成业务规范，原本晦涩难懂的程序可以被转换成更容易审查和讨论的描述。开发者由此能够梳理系统功能、定位业务逻辑，并制定下一步迁移方案。
不过，摩根士丹利当时也承认，AI 在直接迁移完整代码方面还有明显不足。即使能够使用新语言重新实现原程序，也不一定能充分利用目标语言的特性，生成高效、易维护的代码。
这恰好说明了遗留系统现代化面临的两个不同层次的问题。第一个问题是理解：企业需要弄清楚既有系统究竟在做什么，以及其中哪些规则仍然需要保留；第二个问题是迁移：在完成理解之后，开发团队还需要使用现代技术重新实现这些功能，并验证新旧系统的行为是否一致。
摩根士丹利的实践证明 AI 已经能够帮助工程师跨越第一道障碍。而 OpenAI 此次公布的评测，则展示了大模型在第二个问题上的能力进展。
当然，两者并不能简单进行量化对比。DevGen.AI 是运行于企业内部的实际工程工具，面向具有复杂依赖的真实代码库；OpenAI 新研究展示的则是标准化评测任务上的模型能力。但这两种实践放在一起，我们可以明显看出 AI 参与遗留系统改造的技术路线正在拓宽：从代码解释、业务知识提取，到代码生成、迁移和行为一致性测试，AI 可以承担的环节越来越多。
对于企业来说，接下来需要考虑的，是如何把这些能力组织成可靠、可审计的工程流程。
没有 COBOL，企业照样有改不动的老系统
COBOL 是遗留系统现代化的一个典型案例，但企业面对的类似难题，远不止这一门编程语言。
一套运行了十几年的 Java 单体应用，可能积累了数百万行代码，涉及大量接口、数据库表和复杂的外部依赖。最初参与开发的工程师陆续离开，技术文档长期没有更新，部分业务逻辑经过多轮修改，已经很难说清楚为什么要这样实现。
这些系统未必采用过时的技术，也可能至今仍在稳定地支撑企业的核心业务。但每次进行架构升级、数据库替换或服务拆分，开发团队都需要面对同一个问题：修改一段代码之后，是否会破坏某项隐藏在历史实现中的业务规则？
有些改造甚至比跨语言迁移更加复杂。例如，从单体架构拆分成微服务时，原本依赖本地事务完成的业务操作，可能需要重新设计分布式事务、数据一致性和异常补偿机制。即使新系统的每个服务都能通过单元测试，也不能直接证明整个业务流程与旧系统保持一致。
这也是为什么，OpenAI 此次研究的价值不只局限于 COBOL 迁移准确率的提升。其展示的跨语言代码理解与生成能力，以及通过可执行测试验证程序行为的思路，都可能应用于更广泛的企业系统改造。比如，从旧代码中提取业务规则、分析模块依赖、生成回归测试，或辅助重写特定模块，并比较新旧实现的行为差异。
当然，OpenAI 此次公布的评测，还不足以证明模型已经具备独立完成大型企业系统改造的能力。跨服务依赖、复杂数据库状态、并发与故障处理等问题，远比单个程序的输入输出测试复杂。
但这项研究至少提供了一个值得关注的信号：当 AI 越来越擅长理解和迁移那些训练数据稀缺、语义规则复杂的代码，它能够参与的软件现代化工作，也有机会超越某一门特定语言，延伸到更广泛的企业系统改造场景。
AI 敢改几十年的老代码，但谁敢让它上线？
当 AI 开始有能力迁移那些过去难以处理的老代码，一个更现实的问题随之出现：谁来确认 AI 改写后的程序可以安全上线？
OpenAI 此次公布的两项评测，都将可执行测试作为衡量代码生成质量的重要依据。在 COBOL 迁移任务中，模型不仅需要生成另一门语言的代码，还必须确保新程序在隐藏测试中的输出与原程序逐字节一致。
但企业真实系统远比评测环境复杂。对于已经运行十几年甚至几十年的业务系统，难点往往不只是代码能否迁移成功，还在于是否存在一套足够完整的测试体系，能够证明迁移没有破坏原有业务。
大量遗留系统之所以难以改造，恰恰是因为原始设计文档缺失、测试覆盖不足，以及业务规则与代码实现高度耦合。
假如一个系统拥有数千万行代码，涉及不同地区、不同年代积累的业务规则，工程师很难提前枚举所有可能的输入与运行状态。即使 AI 成功完成代码迁移，团队仍需要回答：哪些行为已经得到验证，哪些边界情况尚未覆盖？如果新旧系统产生不同结果，究竟是迁移错误，还是原系统本身就存在历史缺陷？
代码层面的行为一致，也只是现代化改造的一部分。企业通常还需要重新考虑数据模型、接口兼容、事务处理、性能、部署环境与安全控制。即使新程序能够产生相同的业务结果，它在并发负载下的性能、故障恢复方式，以及与外围系统的交互，也可能和原程序不同。
因此，在真实项目中，更稳妥的方式仍然是分阶段推进：首先利用 AI 辅助理解原代码及依赖关系，建立业务规则和测试基线；随后选择边界相对清晰的模块进行迁移，在隔离环境下运行回归测试；最后通过新旧系统并行比对、人工审查和逐步切换，控制改造风险。
这一过程中，AI 不一定需要一次性完成整套系统的重写。它可以分别承担代码分析、测试生成、迁移实现和问题修复等任务，而关键的业务确认与上线决策仍然需要由工程团队负责。
对于国内正在推进系统升级、技术栈迁移和架构改造的企业，这类能力同样具有现实价值。它们不是非要拥有一套 COBOL 系统，才会遇到历史代码难以理解、业务规则难以验证、改造风险难以控制的问题。
从 5.4% 到 97.9%，OpenAI 展示了 AI 在特定代码迁移任务上取得的显著进展。随着模型对更多语言和复杂代码库的理解能力提升，企业有望降低遗留系统分析与改造的部分成本。不过，要把评测中的高准确率转化为生产环境中的可靠迁移，仍然需要完整的工程验证体系。
过去，遗留系统现代化的一大障碍是没有足够的人能够读懂和修改旧代码。随着 AI Coding 能力提升，另一个长期存在的问题将变得更加突出：企业如何证明，改造后的系统仍然正确执行着那些积累了几十年的业务规则？这可能是 AI 真正进入企业核心系统之后，软件工程需要解决的下一道难题。
参考资料：
https://openai.com/index/low-resource-programming-languages/
https://www.infoq.cn/news/fduhDwYGaDod8EuEUyEW