OpenAI 把 COBOL 迁移准确率从 5.4% 拉到 97.9%：老系统有救了，但别急着交钥匙

一家银行的核心账务系统里，可能还跑着 1987 年写下的 COBOL 代码。最初的开发者早已退休，设计文档缺了几页，真正决定利息怎么算、尾差怎么处理的规则，只藏在某几行代码的舍入方式里。过去要把这样的系统迁到 Java 或 Python，通常需要一支团队啃上几年；现在，OpenAI 想证明大模型可以接手这件事。

一分钟速览

• OpenAI 发布 GPT-6.1 Sol 与 GPT-6 Astra，重点提升 COBOL、Fortran 等低资源编程语言能力。
• 在 COBOL 迁移评测中，上一代 GPT-5.6 Sol 低推理强度准确率为 5.4%，GPT-6.1 Sol 达到 86.6%，提高推理强度后升至 97.9%。
• 在覆盖 20 种语言、从零实现 SQLite 兼容数据库引擎的测试中，GPT-6 Astra 平均通过率 87.4%，上一代为 26.8%。
• 评测不看代码是否能编译，而是用隐藏测试逐字节比对迁移前后的可观察输出。
• 但 97.9% 只代表特定任务的成功率，不等于大型机系统可以整体自动重写。

难的不是语法，是那些没写进文档的规则

COBOL 诞生于 1959 年，至今仍支撑着大量在线银行、信用卡交易和 ATM 系统。它的问题从来不是”没人会写”，而是”没人敢改”。一套运行几十年的系统，往往同时叠加了历史业务规则、临时补丁和特定版本的编译器行为。开发者即便看懂了语法，也很难确认某一行看似多余的判断，究竟是不是监管要求留下的痕迹。

最典型的是数值语义。COBOL 的定点数运算在未显式指定四舍五入时，超出精度的部分会被直接截断。如果迁移后的 Java 或 Python 程序默认采用四舍五入，代码可能没有语法错误，也能正常跑完，但账目结果会悄悄变化。在普通应用里，这只是一个难查的 Bug；在金融结算和账务核对场景里，细微偏差足以演变成事故。

类似的问题还有：缺失记录怎么处理、异常输入怎么响应、字符串与数字如何转换、程序对既有数据格式的隐含依赖。这些行为通常没有写进设计文档，却构成了系统的真实契约。

两项评测，考的是”行为不变”

第一项叫 MultiLangBench，要求模型用指定语言从零构建一个与 SQLite 兼容的数据库引擎。模型需要持续组织代码库、管理状态、处理异常、增加功能，并保证后续修改不会破坏已经通过的功能。所有实现统一以数据库文件作为接口，接收初始数据库和 SQL 查询，输出修改后的数据库，再与参考实现比对。

结果里，OCaml 从 25.6% 提升到 85.8%，Fortran 从 21.4% 提升到 83.5%，Visual Basic 从 27.5% 提升到 89.4%。COBOL 仍是最难的一门，通过率 72.1%，但已经是上一代 10.9% 的六倍多。

第二项评测更接近企业真正关心的事：把现有 COBOL 程序迁移到 C++、Java、Kotlin、Python 或 Rust，同时保持原程序行为。OpenAI 没有用”代码生成成功”作为标准，而是用隐藏测试检查迁移前后程序的可观察输出是否逐字节一致，只有全部通过才算成功。GPT-6.1 Sol 在高推理强度下拿到 97.9%，靠的正是这套更严格的口径。

对企业来说，正确的用法可能不是”一键重写”

97.9% 衡量的是特定任务在隐藏测试下的成功比例，不是”大型 COBOL 系统有 97.9% 的代码可以正确迁移”。真实系统的规模、外部依赖、批处理窗口和监管约束，都远超评测环境。更现实的做法，是先把 AI 用在三件低风险但高耗时的事上：梳理代码中的业务规则、生成行为清单、搭建可重复的回归测试。等测试足够厚，再按模块迁移，保留随时回滚的能力。

这背后是一个更大的转向。AI 编程正在从”从零写新项目”走进”维护别人二十年前写的系统”，而后者的瓶颈从来不是生成速度，而是验证成本与责任归属。当模型能把迁移准确率从 5.4% 推到 97.9%，企业真正的竞争力，会变成谁能把剩下的 2.1% 找出来、测清楚、签上字。