作者｜蔡芳芳
几十年前写下的代码，今天还有多少人看得懂？
在银行、保险、制造业以及公共服务机构，一些核心业务系统已经运行了数十年。它们可能使用 COBOL、Fortran 等如今并不流行的编程语言，原始开发者早已离职，技术文档不一定完整，许多业务规则甚至只存在于代码里。
这些系统并不一定经常出现故障，却往往很难修改。对企业来说，重写一套系统的难度，有时远远超过从零开发一套新系统。开发团队既要理解几十年前的代码，也必须保证系统迁移后，账目计算、数据处理和各种异常情况下的业务行为与原系统一致。
AI 编程工具的出现，曾让人们期待这类问题可以得到解决。但过去几年，大模型最擅长的仍然是 Python、JavaScript 等主流语言。遇到历史悠久、公开训练数据稀缺的编程语言，以及高度定制的企业代码库，它们的表现往往不够可靠。
10 月 19 日，OpenAI 发布了一项针对低资源编程语言的最新研究（https://openai.com/index/low-resource-programming-languages/），试图改变这一局面。
在一项 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 的评测代码与测试套件（https://github.com/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 万小时的开发工作量。
