![87.4%：OpenAI 低资源语言编码评测封面](https://developer.qcloudimg.com/http-save/yehe-12798805/a46a536f521239f6c81dc99aa23d7a10.png)
*封面：大数字海报 + 深海蓝。「87.4%」是 GPT-6 Astra 在 MultiLangBench 上 20 种语言的平均测试通过率（官方，最大推理力度）；柱条与右侧 COBOL 迁移数字据官方数据绘制，非 OpenAI 官方图。*

## 银行还在跑 COBOL：OpenAI 为什么现在才专门写这篇

全球不少网上银行系统，后台仍是 COBOL。OpenAI 2026-10-19 这篇博客一开篇就甩出一组行业数字：COBOL 支撑超过 40% 的网上银行系统、80% 的面对面信用卡交易、95% 的 ATM 交易；Fortran 还用在天气预报和核反应堆安全分析里。

这组「40% / 80% / 95%」不是 OpenAI 自己测出来的，博客是引用行业背景；IBM Think 的《What Is COBOL》一文用的是同一口径，可作交叉核对。

博客要讲的不是「老语言该不该死」，而是另一件事：这些语言公开代码和文档远少于 Python、JavaScript，模型学得少，企业客户却反复反馈——修 bug、迁语言时，模型经常在这儿翻车。文档不全、原作者离职、业务规则只活在代码里，这是维护现场的常态。

OpenAI 为此做了两套互补评测：

1. **MultiLangBench**：能不能在指定语言里，从零写出一套 SQLite 兼容的数据库引擎。
2. **COBOL 迁移评测**：能不能把既有 COBOL 程序迁到另一种语言，并且行为不变。

![OpenAI 博客 SEO 配图：COBOL / OCaml / Fortran / Visual Basic](https://developer.qcloudimg.com/http-save/yehe-12798805/a3a59556463e33419ee6ebe48ad04f6f.png)
*[官方图] 博客页 SEO 配图，标题旁标出 COBOL、OCaml、Fortran、Visual Basic。图源：OpenAI 官方博客 Advancing coding in low-resource programming languages*

> 原文：[Advancing coding in low-resource programming languages](https://openai.com/index/low-resource-programming-languages/)，作者 OpenAI，2026-10-19。本文是要点解读加编者注，观点归原作者；文中评测数字以官方博客原文为准，本号未重跑评测。

下面先摆两张对比表，再讲成本，最后看官方自己划的边界。

## 一张表：20 种语言从零写 SQLite，平均通过率从 26.8% 到 87.4%

MultiLangBench 的任务很硬：给定一种编程语言，模型要组织代码库、管状态、处理错误、在保住已有功能的前提下加新功能，最终交出一个 SQLite 兼容引擎。

为了让 20 种语言能比，评测用**数据库文件**当公共接口：候选程序拿到初始库和一条 SQL，吐出改过的库；再用参考版 SQLite 检查内容对不对。测试改编自 SQLite 既有测试套件。报告的是**测试通过率**和 API 成本。

最大推理力度下，官方数字是：

| 指标 | GPT-5.6 Sol | GPT-6 Astra | GPT-6 Luna |
|---|---:|---:|---:|
| 20 语平均通过率 | 26.8% | **87.4%** | 40.3% |
| COBOL | 10.9% | 72.1% | 17.1% |
| OCaml | 25.6% | 85.8% | 34.1% |
| Fortran | 21.4% | 83.5% | 31.4% |
| Visual Basic | 27.5% | 89.4% | 41.6% |

Astra 在 20 种语言里有 19 种高于 83%；**COBOL 仍是最难的那一个，约 72%**。博客写明：每种被测语言都有提升。

![MultiLangBench 关键语言前后对比](https://developer.qcloudimg.com/http-save/yehe-12798805/b7f5ec53bc69db93c8a9b1da8f1c9230.png)
*[框架示意] 据 OpenAI 博客 §1 整理；口径为最大推理力度下的测试通过率。本图由本号用 HTML 排版绘制。*

**口径别混：**

- **87.4%** = GPT-6 Astra、MultiLangBench、20 种语言**平均**测试通过率、最大推理力度。
- **不是**「随便写点 COBOL 就有八成把握上线」，也**不是** COBOL 单语分数（COBOL 是 72.1%）。
- 对照基线是 **GPT-5.6 Sol 的 26.8%**，不是别家报道里偶见的其它模型名。

评测设置和测试套件已开源到 GitHub 仓库 openai/MultiLangBench（Apache-2.0）。README 写明目标是实现 SQLite **3.40.1**；完整转换测试约 2.4 万条，常规评测建议只用以 `00`/`01`/`02` 开头的 **272** 条。

## 另一张表：把 COBOL 迁走，低推理档就从 5.4% 到 86.6%

第二套评测更贴银行、保险里的真实活：把 COBOL 程序迁到 **C++、Java、Kotlin、Python 或 Rust**，且**保住原程序做什么**。

博客举了定点运算的例子：COBOL 默认丢掉多余小数位，除非你显式要求舍入。改写如果擅自四舍五入，程序可能「跑得通」，账却对不上。

所以他们用隐藏测试卡**可观察输出的逐字节一致**；全部通过才算迁成功。

官方数字：

| 档位 | 模型 | 准确率 | 成本口径 |
|---|---|---:|---|
| 低推理力度 | GPT-5.6 Sol | 5.4% | 对照基线 |
| 低推理力度 | GPT-6.1 Sol | **86.6%** | 约为旧模型 API 成本的 **61%**（摘要写作便宜约 **39%**） |
| 更高推理力度 | GPT-6.1 Sol | **97.9%** | 官方称接近评测饱和 |

「39% less」和「61% of the API cost」是同一件事的两种写法，都来自官方博客。

![COBOL 迁移评测：低档与高档](https://developer.qcloudimg.com/http-save/yehe-12798805/38c651c95f36e4bc39cb8a9a4c7ec5bc.png)
*[框架示意] 据 OpenAI 博客 §2；准确率 = 全部隐藏测试通过。本图由本号用 HTML 排版绘制。*

**97.9% 的口径：** GPT-6.1 Sol、**更高推理力度**、该 COBOL 迁移评测上的准确率。它几乎顶到评测天花板，不等于「迁完就能切生产流量」。

博客接着写了一句硬边界：这类行为保持能力对维护和现代化有用，**但应用到生产软件，仍需专家审查，并对照该系统的业务规则与依赖做测试**。

## 花钱更少也能涨：GPT-6 Luna 大约便宜 78%，适合谁先试

不是每家都要一上来就打满推理、打满 Astra。博客给了低成本档 GPT-6 Luna 的数：

- MultiLangBench 平均通过率 **40.3%**（仍高于 Sol 的 26.8%，且每种语言都有提升）
- 估计平均 API 成本约 **$0.77 / sample**，对照 Sol 约 **$3.48**，大约低 **78%**
- 低资源语种上 Luna 的涨幅更「温和」：COBOL 10.9%→17.1%，Fortran 21.4%→31.4%，Visual Basic 27.5%→41.6%

![GPT-6 Luna 成本与部分语言涨幅](https://developer.qcloudimg.com/http-save/yehe-12798805/4f96c92421514513d3ce98d28078843f.png)
*[框架示意] 据 OpenAI 博客 §1 的估计 API 成本与通过率。本图由本号用 HTML 排版绘制。*

读法可以很朴素：先用 Luna 在非核心路径上试「读懂仓库、改小补丁、出迁移草稿」；关键账务路径再加推理力度，或换更强档，并留下人工复核闸门。

## 评测不等于上生产：官方自己强调要专家复核业务规则

两张表看完，更重要的是分寸。我们把博客**说了什么**和**没说什么**摊开：

![说了什么 / 没说什么](https://developer.qcloudimg.com/http-save/yehe-12798805/f2434ab813d98f87c62c7dbb9104ee57.png)
*[框架示意] 对照 OpenAI 博客全文与 openai/MultiLangBench README；「没说」一项亦对照 AiLookout 跟进报道。本图由本号整理。*

**说了：**

- 两套评测的任务定义、主要数字、成本对比
- MultiLangBench 开源，方便外人核对测什么、每种语言差在哪
- 上生产要专家审查 + 对照业务规则与依赖测试

**没说（至少这篇里没有）：**

- COBOL 迁移集有多少程序、多长、从哪来
- 有没有开源该迁移评测集（目前只见 MultiLangBench 开源）
- 任何银行核心 / ATM 上线案例
- 「一键替换」核心账务系统这类承诺
- 评测分能不能直接当验收标准

所以这篇更适合当成「能力曲线往上走了」的证据，而不是「下周切掉主机」的施工图。

## 编者注

**1. 数字要带尺子。** 对外转述时建议写成：「MultiLangBench 上，GPT-6 Astra 在最大推理力度下，20 种语言平均测试通过率 87.4%（对照 GPT-5.6 Sol 26.8%）」；COBOL 单语写 72.1%；迁移写清「低推理 86.6% / 高推理 97.9%，模型是 GPT-6.1 Sol」。少一个限定词，意思就飘。

**2. 评测任务 ≠ 银行核心改造任务。** MultiLangBench 考的是从零实现 SQLite 兼容引擎；迁移评测考的是隐藏测试上的输出对齐。真实核心系统还有联机事务、批处理窗口、监管报表、周边组装语言与中间件。分数高，只说明「在这些尺子上变强了」。

**3. 定点运算那条提醒，值得贴在迁移检查单上。** 博客用 COBOL 舍入规则举例：表面跑通、财务结果不同。企业侧至少要单列：金额舍入、缺省记录、编码页、日期与假期日历、对账差额处理。

**4. 开源的是尺子，不是迁移题库。** openai/MultiLangBench 可复现「从零写库」这条线；COBOL 迁移集的规模与样本未公布。跟进报道 AiLookout 也指出这一点。拿第三方复现分数对比时，先确认是不是同一套测试。

**5. 国内团队怎么落地，这篇没写，但边界清楚。** 能立刻做的是：用开源 MultiLangBench 看自家模型/代理在遗留语言上的短板；把「AI 出草稿 → 资深 COBOL/Fortran 工程师审 → 对照业务用例与对账」写成流程。不能做的是：把 97.9% 写进立项材料当成「可免人工验收」。

**6. 行业 40%/80%/95% 是背景，不是 OpenAI 的实验结果。** 引用时写「行业常用口径 / IBM 等来源复述」，别写成「OpenAI 测出来银行有 40% 跑 COBOL」。

## 维护老系统的团队可以看什么、创业团队可以先跳过（适合谁 / 不适合谁）

**适合读、适合拿去内部对齐的人：**

- 银行、保险、清算、政务里还在养 COBOL / 主机应用的架构与工程负责人：用两张表对齐「模型进步了多少」，用「专家复核」原话对齐风险话术。
- 做遗留现代化、代码迁移工具的团队：关注逐字节对齐与定点运算这类易踩坑点。
- 科学计算 / 气象 / 能源里还在写 Fortran 的小组：看 MultiLangBench 里 Fortran 从 21.4% 到 83.5% 的相对进步，再决定要不要开内部试点。

**不适合 / 先别用这篇当行动令的场合：**

- **不适合**把 87.4% 或 97.9% 理解成「可以一键替换核心银行系统」。
- **不建议**创业团队若当前栈全是 Python/TypeScript、也没有遗留包袱，就为这篇专门立项——优先级更低，扫一眼数字即可。
- **先别用**公开评测分替代你们自己的业务验收集；官方也没把评测当成生产验收。

## 使用建议

1. **对内汇报先写口径表**：平均分 / 单语分 / 迁移低档 / 迁移高档 / 成本，五列分开，避免标题党式合并。
2. **试点选非核心路径**：只读分析、文档回填、测试生成、迁移草稿，比直接改联机账务更合适。
3. **保留人工闸门**：金额、舍入、对账、监管字段，必须有懂业务规则的人签字。
4. **想核对尺子**：去看 openai/MultiLangBench 的测试说明与推荐的 272 条子集；迁移题库未开源就不要假装能复现 97.9%。

封面：大数字海报 + 深海蓝。「87.4%」是 GPT-6 Astra 在 MultiLangBench 上 20 种语言的平均测试通过率（官方，最大推理力度）；柱条与右侧 COBOL 迁移数字据官方数据绘制，非 OpenAI 官方图。

87.4%：OpenAI 让模型写出 20 种语言 SQLite

「87.4%」是 GPT-6 Astra 在 MultiLangBench 上 20 种语言的平均测试通过率（官方，最大推理力度）；柱条与右侧 COBOL 迁移数字据官方数据绘制，非 OpenAI 官方图。

人工智能

编程语言

数据库

OpenAI发布GPT-6Astra，在MultiLangBench评测中20种语言平均通过率达87.4%，COBOL迁移准确率最高97.9%。评测聚焦低资源编程语言，成本较旧模型降低61%。模型在COBOL、Fortran等遗留语言上显著进步，但官方强调仍需专家审查业务规则，并非一键替换方案。

安全分析

JavaScript

TypeScript 

中间件

Python

SQLite

Kotlin

GitHub

Java

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

87.4%：OpenAI 让模型写出 20 种语言 SQLite-腾讯云开发者社区-腾讯云

87.4%：OpenAI 让模型写出 20 种语言 SQLite

87.4%：OpenAI 让模型写出 20 种语言 SQLite

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐