Michael Johnson将 COBOL 程序迁移到现代语言时，即使保留了语法，也可能改变金额计算规则。OpenAI 在10 月 19 日发布的文章中讨论了这一问题：该公司介绍了模型在 COBOL、Fortran 等训练资料较少的语言上的编程测试结果，并开放了 MultiLangBench 数据集。
对于维护旧企业系统的团队来说，这则消息的价值不只在于公布的百分比，还在于它采用了两种不同的测试。一种评估模型从头开始用不同语言编写程序的能力；另一种则检查 COBOL 代码迁移后是否保留了可观察到的行为。这两类任务需要不同的测试，也与部署风险有着不同的关系。
两项测试，两类工程任务
在 MultiLangBench 中，模型需要创建一个兼容 SQLite 的引擎，能够接收查询并修改数据库文件。OpenAI 报告了 20 种语言的平均测试通过率：GPT‑6 Astra 在最高推理级别下达到 87.4%，GPT‑5.6 Sol 则为 26.8%。每项实现都会根据数据库的预期内容进行验证，同时也会评估运行时长和 API 成本。
该公司已在 GitHub 上发布MultiLangBench，其中包括测试基础设施。公开的代码库介绍了基于 SQLite TCL Tests 套件创建的测试，以及结果验证规则。这让开发者能够查看评测具体涵盖了哪些操作，并针对自己的模型配置复现评测。
COBOL 迁移测试考察的是另一种能力：将现有程序改写为 C++、Java、Kotlin、Python 或 Rust，并在隐藏测试中保留其行为。OpenAI 报告称，在低推理级别下，GPT‑6.1 Sol 的准确率为 86.6%，而同一模式下 GPT‑5.6 Sol 为 5.4%。在更高的推理级别下，GPT‑6.1 Sol 在这项评测中的指标达到 97.9%。
为什么迁移需要验证业务规则
OpenAI 在说明中强调，兼容性取决于源语言的语义。例如，如果没有明确指定舍入方式，COBOL 的定点运算会截去多余的小数位。若新实现采用不同的舍入方式，程序可能看似运行正常，却给出不同的财务结果。
因此，迁移测试的标准是在受测案例中输出一致；而团队在实践中的标准还应包括自身的计算规则、数据格式和系统依赖。一个有用的起点是选择一个输入输出明确的模块，针对真实的边界情况记录基准结果，并让原始版本与改写版本并行运行。
这些结果对团队有何帮助
OpenAI 公布的数据仅适用于其发布的数据集和推理设置。MultiLangBench 评估的是创建兼容 SQLite 的实现，COBOL 测试则评估迁移后能否保留行为；这些指标反映的是具体测试结果。对团队而言，它们可作为筛选模型的参考，也为自行进行可复现的比较提供基础，但不能直接视为与任何生产系统的兼容性评估。
实际结论很简单：应使用自己的代码和控制案例测试模型，并将成本与任务成功率一并考量。迁移 COBOL 时，尤其要检查舍入、记录遗漏，以及其他固化在旧程序行为中的规则。新的结果让此类验证更容易开展；确认等效性的责任仍属于工程流程的一部分。