ChatGPT补上冷门语言短板

OpenAI 近日宣布改进 ChatGPT 对低资源编程语言的支持，同时引入面向软件工程、SQLite 和 COBOL 迁移的新评测。截至 2026 年 10 月 20 日，官方尚未公布新的模型名称、定价调整或完整跑分，但这次更新释放出的信号很明确：ChatGPT 的编程能力开始从“会写热门语言代码”，转向“能否处理企业里那些旧、偏、难维护，却又不能停机重写的系统”。

ChatGPT 是 OpenAI 面向个人与组织提供的通用 AI 助手，其编程能力覆盖代码生成、调试、解释、测试和仓库级修改等任务。 过去几年，AI 编程工具的竞争主要围绕 Python、JavaScript、TypeScript、Java 和 C++ 展开，因为这些语言在公开代码、技术文档、问答社区和训练样本中的占比更高。相比之下，COBOL 等语言并不一定缺少实际部署，而是缺少规模足够大、质量足够高、许可证边界清晰的数据和评测。

这也是 OpenAI 此次更新最值得关注的地方：它没有再拿一个热门语言补全跑分来证明模型“更会写代码”，而是把评测推向了更接近生产环境的区域。

低资源不等于低价值

低资源编程语言是指可用于模型训练、对齐和评测的高质量公开资源相对稀缺的编程语言。 这里的“资源”不只是 GitHub 上能搜索到多少代码，还包括编译环境、依赖管理、测试用例、错误修复记录、技术文档、专家反馈，以及可以合法用于训练和评测的数据。

这一区分很重要，因为代码数量并不能直接等价为训练价值。

一套运行了 30 年的 COBOL 核心系统，可能包含数百万行代码，处理银行账户、保险保单或政府记录，但它通常位于企业内部，既不会公开，也很少拥有现代开源项目那样完整的 Issue、Pull Request 和持续集成记录。模型即使见过 COBOL 语法，也未必理解特定方言、文件布局、批处理流程以及隐藏在代码里的业务规则。

低资源语言还面临三个典型问题：

1. 有效样本少。 大量公开代码可能只是教学示例、语法演示或重复镜像，无法覆盖真实维护任务。
2. 反馈信号弱。 Python 项目通常可以快速安装依赖并运行测试，老旧语言的工具链和运行环境却可能难以复现。
3. 错误代价高。 遗留系统里的代码往往直接关联账务、库存和关键业务流程，结果“看起来合理”远远不够。

因此，这次更新并不是给 ChatGPT 增加几组冷门语法模板，而是在补齐数据、环境、验证和反馈链条。对模型来说，记住一条语法规则并不难；困难的是修改一个陌生仓库后，仍能保证原有行为没有被悄悄破坏。

新增三类评测，重点从代码片段转向真实工程

代码评测是用可重复执行的任务和验证规则，衡量模型生成、修改或迁移代码能力的方法。 OpenAI 此次提到的评测覆盖一般软件工程、SQLite 和 COBOL 迁移三个方向，它们分别对应日常维护、成熟基础软件修改和遗留系统现代化。

这三类任务的难度明显高于传统的函数生成题。

| 评测方向 | 主要任务对象 | 核心能力 | 常见失败方式 | 实际价值 | |---|---|---|---|---| | 传统代码片段评测 | 单个函数或短程序 | 语法、算法、局部推理 | 边界条件遗漏、输出格式错误 | 适合衡量基础代码生成能力 | | 软件工程评测 | 完整代码仓库与问题描述 | 定位文件、理解依赖、跨文件修改、运行测试 | 修错文件、引入回归、只修表面症状 | 更接近日常开发和维护流程 | | SQLite 评测 | 成熟数据库代码库 | 系统级代码理解、兼容性、性能与正确性约束 | 修改破坏边界行为、测试通过但产生回归 | 检验模型处理高密度基础软件的能力 | | COBOL 迁移评测 | 遗留程序及目标语言实现 | 跨语言转换、业务语义保留、数据布局映射 | 编译成功但业务结果变化 | 对银行、保险和政务系统现代化有直接意义 |

仓库级软件工程评测是要求模型在既有代码库中定位问题、修改文件并通过测试的评估方式。 它与 HumanEval 一类短代码题的区别，类似于“现场修一台正在运行的机器”和“在纸上画一个零件”：后者可以测基础能力，前者才会暴露模型是否理解依赖关系、构建流程和历史约束。

OpenAI 将一般软件工程单独列出，意味着低资源语言支持不能只看语法补全。一个真正可用的编程助手，需要读懂项目目录、构建脚本、错误日志和测试代码，还要判断用户提交的是编译错误、逻辑缺陷，还是环境配置问题。

SQLite 为什么被单独拿出来

SQLite 是一种嵌入式关系型数据库引擎，数据库能力直接集成在应用程序内部，而不依赖独立服务器进程。 它被广泛用于移动应用、浏览器、桌面软件和嵌入式设备，其核心代码主要使用 C 编写。

SQLite 并不是低资源编程语言，但它是很有代表性的高难度代码库。其代码成熟、兼容要求高、边界情况密集，任何看似简单的修改都可能影响查询执行、事务、文件格式或不同平台上的行为。

把 SQLite 纳入独立评测，至少说明 OpenAI 不再满足于检查代码能否编译。数据库引擎的修改必须同时考虑：

• 原有测试是否继续通过；
• 新增行为是否覆盖异常输入；
• 文件格式与历史版本是否兼容；
• 内存安全和资源释放是否正确；
• 修改是否影响性能关键路径；
• 不同操作系统和编译选项下是否保持一致。

这种评测对 ChatGPT 的价值在于，它能迫使模型面对“局部修改、全局约束”的真实问题。模型可能只改动十几行代码，但必须理解数千行上下文中的不变量。对开发者来说，这比生成一个新的 CRUD 页面更能区分模型能力。

不过，OpenAI 目前没有在公告中给出 SQLite 评测的任务数量、测试覆盖率、成功率或与其他模型的横向对比。因此，现在还不能据此判断 ChatGPT 已经具备独立维护数据库内核的能力。新增评测首先代表的是测量方法进步，而不是能力已经被完全证明。

COBOL 迁移才是这次更新最有商业价值的部分

COBOL 是一种长期用于金融、保险、政府和大型机业务系统的编程语言，其代码通常承载批处理、账务和记录管理等关键流程。 COBOL 经常被外界称为“古老语言”，但许多系统仍在持续运行，企业也很难用一次性重写的方式替换它们。

代码迁移评测是衡量模型能否在更换编程语言或运行平台时保持原程序行为的测试。 它测试的不是逐行翻译，而是能否保住输入输出、数据精度、异常处理、文件结构和业务规则。

COBOL 迁移尤其容易出现一种危险结果：新代码能够编译，示例输入也能运行，但金额舍入、定长字段、日期处理或批处理顺序已经发生变化。对于普通应用，这可能只是一个 Bug；对于账务系统，它可能变成持续数月才被发现的数据偏差。

真正可信的 COBOL 迁移至少要验证以下层次：

1. 语法等价。 原程序的分支、循环和过程调用被正确转换。
2. 数据等价。 定长记录、十进制定点数和字符编码没有发生隐式变化。
3. 行为等价。 相同输入在旧系统和新系统上产生相同结果。
4. 异常等价。 文件缺失、字段溢出和非法记录的处理方式保持一致。
5. 批处理等价。 作业顺序、重试机制和中间文件没有被忽略。
6. 可维护性。 迁移结果不是机械翻译出的“新语言版 COBOL”，而是能被目标技术栈的工程师继续维护。

这也是为什么 COBOL 迁移评测比“把这段 COBOL 改写成 Java”难得多。企业真正购买的不是翻译速度，而是迁移风险下降。如果缺少差分测试、历史数据回放和人工审计，再流畅的生成结果也不能直接进入生产系统。

这不是新模型发布，也没有足够数据证明全面领先

此次变化更接近 ChatGPT 编程能力与评测体系的定向升级，而不是一次新的基础模型发布。 截至目前，OpenAI 没有随公告披露新的模型 ID、上下文长度、调用价格或独立产品套餐，也没有发布足以进行跨厂商比较的完整成绩表。

因此，开发者不应把它理解成“ChatGPT 已经攻克所有冷门语言”。更准确的说法是：OpenAI 开始系统化处理过去容易被平均跑分掩盖的长尾问题，并为这些问题建立更接近生产环境的验收方式。

与 GitHub Copilot、Claude Code、Gemini Code Assist 等产品相比，ChatGPT 此次更新的差异点不在编辑器交互，而在评测对象。当前主流 AI 编程产品都能解释或生成多种语言代码，但厂商很少公开展示低资源语言上的分语言成功率，更少公开遗留系统迁移的行为一致性数据。在统一测试集、相同工具权限和相同计算预算下的结果出现之前，任何“全面领先”的结论都缺乏依据。

这次更新值得肯定，但 OpenAI 仍欠开发者几项关键数据：

• 每种低资源语言分别覆盖了多少任务；
• 改进前后的成功率变化是多少；
• 评测是否包含私有或未进入训练的数据；
• 迁移任务采用什么目标语言和运行环境；
• 成功标准是编译通过、测试通过，还是完整行为等价；
• 人类专家在同一评测中的基线是多少。

如果没有这些信息，“支持更多语言”仍然容易成为一句产品口号。OpenAI 这次做对的是先补评测，但下一步应当是公开足够细的结果，让开发团队能判断模型适合辅助编写、代码审查，还是可以进入半自动迁移流程。

对开发者来说，最实际的变化是什么

低资源语言能力提升最先受益的并不是新项目，而是缺少维护人员的现有项目。 对仍在维护老旧系统的团队，ChatGPT 可以更适合承担代码解释、依赖梳理、测试生成、迁移方案拆分和文档补全等工作。

比较稳妥的使用顺序是：

• 先让模型解释模块边界和数据流，不要直接要求重写整个系统；
• 要求模型列出无法确定的方言、运行时和外部依赖；
• 使用真实编译器、测试框架和历史数据验证结果；
• 对迁移前后的输出进行差分比较；
• 将金额、权限、日期和编码逻辑列为强制人工审查项；
• 把大规模迁移拆成可回滚的小批次，而不是一次性交付。

对于 SQLite 这类基础软件，模型更适合充当“能快速阅读上下文的结对开发者”，而不是无人监督的提交者。它可以帮助定位可能相关的模块、补充测试和解释失败路径，但最终合并仍应依赖维护者审核、静态分析、模糊测试和多平台持续集成。

对于 COBOL 迁移，编译通过只能算起点。更可靠的验收指标应该是旧系统与新系统在成批历史输入上的一致率，并对不一致结果逐条分类。模型如果无法解释差异来自字段精度、编码转换还是业务规则，就不应自动推进后续迁移。

OpenAI 正在把 AI 编程带进更难啃的存量市场

这次更新的核心意义，是 AI 编程开始从增量开发市场进入存量软件市场。 新项目通常有现代工具链、完整文档和充足开发者，而存量系统恰恰相反：语言老、人员少、文档缺失，业务又无法停摆。

从商业角度看，后者可能比生成新代码更有价值。企业愿意为迁移和维护支付高成本，不是因为代码难写，而是因为没人敢保证改完不会出事故。谁能建立可靠的评测、验证和审计流程，谁才可能把模型从辅助工具推进到企业工程体系的核心环节。

OpenAI 此次新增软件工程、SQLite 和 COBOL 迁移评测，是一个方向正确但仍需数据验证的更新。它说明 ChatGPT 的编程目标不再只是回答“这段代码怎么写”，而是开始尝试回答更棘手的问题：这套几十年前的系统究竟在做什么，怎样修改它，以及如何证明修改后没有改变不该改变的东西。

现阶段最合理的判断是：这不是一次足以改变模型选型的参数升级，却可能是 ChatGPT 进入遗留系统现代化市场的重要铺垫。 如果 OpenAI 后续公布分语言结果、迁移一致率和可复现测试集，这套评测体系的价值会明显高于再刷高几个已经接近饱和的代码题榜单。

参考来源

• SWE-bench GitHub 仓库：仓库级软件工程评测项目，可用于理解真实 Issue 修复与传统代码片段测试的区别。
• SQLite GitHub 镜像仓库：SQLite 源代码镜像，可用于了解其代码规模、测试结构与跨平台构建方式。
• GnuCOBOL GitHub 仓库：开源 COBOL 编译器项目，可用于了解 COBOL 工具链、方言支持和现代环境下的编译方式。