OpenAI发布两项面向“低资源编程语言”的新评测：MultiLangBench要求模型分别使用20种语言从零实现一个兼容SQLite的数据库引擎；另一项评测则要求模型将COBOL程序迁移至C++、Java、Kotlin、Python或Rust，同时保持原有行为。官方结果显示，GPT‑6 Astra在MultiLangBench上的平均测试通过率达到87.4%，GPT‑6.1 Sol在高推理强度下完成COBOL迁移的准确率达到97.9%。这表明AI编程能力正从Python、JavaScript等主流语言延伸至银行、政府及科研机构仍在使用的旧技术栈。不过，这些成绩来自OpenAI自行设计和运行的评测；87.4%代表测试用例通过比例，并不代表模型已经完成一个可投入生产的SQLite实现，97.9%也不能理解为银行可以不经人工审查直接迁移核心系统。
文章作者、来源：OpenAI
“低资源”不等于“已经没人使用”
在AI编程领域，低资源语言指的是可供模型学习的公开代码、文档和问答资料相对较少的语言，并不意味着这些语言缺乏现实价值。
Python和JavaScript拥有庞大的开源生态，模型在训练时可以看到大量代码、错误报告和修复记录。COBOL、Fortran、Visual Basic和OCaml的公开材料则少得多，其中不少代码还封存在企业内部系统中。
与此同时，这些语言仍承担着关键任务。OpenAI援引IBM的数据称，COBOL支撑着超过40%的网上银行系统、80%的线下信用卡交易和95%的ATM交易；Fortran则继续用于天气预报与核反应堆安全分析。
维护这些系统的难点不只是语法古老。原始开发者可能已经离职，文档并不完整，真正的业务规则只存在于代码中。一段程序为什么截断小数、怎样处理不存在的账户记录，可能没有任何说明，却直接影响金融计算结果。
因此，AI真正需要证明的并不是“能否把COBOL翻译成看起来更现代的Python”，而是迁移后是否仍然执行完全相同的业务规则。
第一个测试：用20种语言重新造一个SQLite
OpenAI为此发布了MultiLangBench。它要求模型在一次较长的编程过程中，使用指定语言构建一个兼容SQLite的数据库引擎。
候选程序会收到一个初始数据库文件和一条SQL查询，执行后产生修改过的数据库。评测系统再调用官方SQLite实现，检查数据库内容是否与标准结果一致。借助数据库文件这一共同接口，同一组功能可以跨语言比较。
测试覆盖C、C++、COBOL、Fortran、Java、JavaScript、Lean、OCaml、Python、Rust、Visual Basic和Zig等20种语言，考察模型组织代码库、管理状态、处理错误、加入新功能并避免破坏旧功能的能力。测试用例改编自SQLite现有测试套件。
在最高推理强度下，GPT‑6 Astra的平均测试通过率为87.4%，而GPT‑5.6 Sol为26.8%。OpenAI称，Astra在全部20种语言中均有提升：
COBOL由10.9%升至72.1%，OCaml由25.6%升至85.8%，Fortran由21.4%升至83.5%，Visual Basic由27.5%升至89.4%。20种语言中有19种超过83%，COBOL仍然是最困难的一种。
（原文此处有可切换的20种语言交互结果模块，可查看不同模型在每种语言上的成绩与成本。）
这些数字需要正确理解。87.4%是评测用例的平均通过比例，不代表模型有87.4%的概率生成一个完整、稳定且符合SQLite全部规范的数据库。剩余约12.6%的测试失败，仍可能对应事务、错误处理或数据一致性等足以阻止生产部署的问题。
它证明的是模型可以在陌生语言中持续构建较复杂的软件，而不是SQLite已经可以由AI一次性重写。
更便宜的Luna，能力仍与Astra相差明显
OpenAI还测试了成本更低的GPT‑6 Luna。它在20种语言中的平均通过率为40.3%，高于GPT‑5.6 Sol的26.8%。
Luna的平均API成本约为每个样本0.77美元，GPT‑5.6 Sol则约为3.48美元，降幅约78%。但其能力提升并没有达到Astra的水平：Luna在COBOL上只有17.1%，Fortran为31.4%，Visual Basic为41.6%。
这组结果呈现的是两条不同路线：Astra使用更多推理资源，尽可能提高复杂任务的完成度；Luna则以较低费用处理更多样本，适合批量尝试、初步分析和风险较低的辅助工作。
所谓成本也只是评测中的估算API费用，不包括工程师审查、测试环境、业务验收以及错误修复所需的人力。对于遗留系统，模型调用费往往不是迁移项目中最大的成本。
第二个测试：迁移代码时必须保留旧系统的“怪脾气”
第二项评测要求模型将COBOL程序迁移到C++、Java、Kotlin、Python或Rust。
测试重点不是译文代码是否整洁，而是新旧程序的可观察输出能否逐字节一致。每个迁移结果必须通过全部隐藏测试，才会被判定成功。
OpenAI特别举出了定点小数的例子：COBOL默认可能直接丢弃多余小数位，除非程序明确要求四舍五入。如果模型按照现代编程习惯擅自改成四舍五入，程序虽然能够正常运行，财务结果却已经改变。
在低推理强度下，GPT‑6.1 Sol的迁移准确率达到86.6%，而GPT‑5.6 Sol只有5.4%；前者估算API成本还低39%。提高推理强度后，GPT‑6.1 Sol达到97.9%，使这套评测接近饱和。
这里的97.9%是“在OpenAI这套测试中完整通过隐藏用例的程序比例”，而不是“任意COBOL系统都有97.9%的代码可以安全自动迁移”。
真实银行系统可能连接大型机、专有数据库、批处理调度器和内部通信协议，还存在测试用例未覆盖的异常流程。OpenAI也明确表示，生产迁移仍需要专家审查，并针对实际业务规则和依赖关系重新测试。
开放了MultiLangBench，但COBOL迁移评测仍不完全透明
OpenAI已经将MultiLangBench的评测环境、测试套件和分语言结果上传至GitHub，开发者可以检查测试内容，并用其他模型或Agent框架重新运行。
这比只展示一张成绩表更有价值：外界可以观察模型究竟在哪些SQL功能上失败，也可以比较成绩是否受到提示词、工具权限、推理预算和运行时长影响。
不过，官方文章只宣布公开MultiLangBench，没有说明COBOL迁移评测的完整程序样本与隐藏测试也已开放。后者的97.9%成绩目前无法像MultiLangBench一样由外界完整检查和复现。
两项评测也均由OpenAI设计，并主要用于比较OpenAI自己的模型。它们尚未覆盖大量真实企业代码库、长期维护成本、安全漏洞、性能退化，以及人工复核需要多少时间。因此，结果首先证明的是模型在受控任务上的进步，而不是已经完成企业软件现代化问题的最终验证。
更大的变化，是AI编程开始进入被遗忘的代码世界
过去两年，AI编程产品的演示大多集中在创建网页、移动应用和Python工具。这些场景直观，却不是大型企业最昂贵的软件问题。
银行、保险、政府和科研机构真正难以处理的，是运行了数十年、无人敢轻易改动的代码。它们可能不够新潮，却包含账户处理、税务计算、供应链和基础设施运行所依赖的规则。
MultiLangBench的意义正在于此：模型能力是否可以脱离最常见的训练语言，把软件工程方法迁移到资料稀缺、工具老旧、错误代价更高的技术栈。
如果这一能力继续提升，AI最先带来的变化可能不是“一键删除所有COBOL”，而是帮助工程师阅读陌生代码、补充测试、恢复缺失文档、定位业务规则，再逐个模块完成经过验证的迁移。人类专家仍然负责决定哪些行为必须保留，以及何时可以真正替换旧系统。