# AI 翻新老代码，先别替人处理零头

> OpenAI 公布低资源编程语言评测，COBOL 迁移成绩显著提高。真正值得盯住的，却是新系统有没有保住旧系统那些不太体面的细节：翻译代码时，谁有权顺手改掉一分钱的规则？

- 作者：芝士AI吃鱼
- 发布日期：2026-10-20
- 栏目：[AI锐评](https://ai-knowledgepoints.cn/commentary)（观点与分析）
- 主题：AI锐评、代码迁移、COBOL、软件工程
- HTML 正文：[https://ai-knowledgepoints.cn/blog/commentary-2026-10-20-migration-behavior-contract](https://ai-knowledgepoints.cn/blog/commentary-2026-10-20-migration-behavior-contract)
- Markdown 永久链接：[https://ai-knowledgepoints.cn/blog/commentary-2026-10-20-migration-behavior-contract/index.html.md](https://ai-knowledgepoints.cn/blog/commentary-2026-10-20-migration-behavior-contract/index.html.md)
- 原始来源：[OpenAI 低资源语言评测、MultiLangBench 与 Fujitsu COBOL 文档](https://openai.com/index/low-resource-programming-languages/)

引用本文时，请注明作者与 HTML 正文链接。Markdown 版本用于机器阅读，与 HTML 正文共享同一内容来源。

## 正文

一家店换了收银台。新机器启动快，界面漂亮，连小票上的字体都精神了。

晚上对账，老会计发现零头对不上。负责翻新的助手很委屈：以前的小数处理太土了，我顺手改得更规范了。

这段情节是虚构的。可它很适合摆在 AI 代码迁移的演示屏旁边：程序换了一种写法，收钱的规矩也可以顺手换吗？

2026 年 10 月 19 日，[OpenAI 发布了低资源编程语言能力评测](https://openai.com/index/low-resource-programming-languages/)，覆盖从零构建与旧程序迁移两类任务。这里的“低资源”指可供模型学习的代码和文档相对少，不是说运行它们的机器内存小。

其中，厂商报告 GPT‑6.1 Sol 在较高推理强度下，COBOL 迁移评测准确率达到 97.9%。判定并不只是编译成功：迁移后的可观察输出要通过全部隐藏测试，并与预期逐字节一致。这是 OpenAI 自报结果，本文没有独立复现。

这条进展值得认真看。模型更能处理老语言，可能让原本没人敢碰、改一次要来回查很久的代码，终于有机会被梳理。

但比“终于能翻译了”更重要的，是翻译时哪些东西不能擅自变得更漂亮。

## 那一分，可能就藏在接收字段里

比如，把一个正数结果存进只能保留两位小数的字段，超过的部分怎么处理？

不能只回答“四舍五入呗”。[Fujitsu 的 COBOL2000 编译器文档](https://bs2manuals.ts.fujitsu.com/psCOBOL2000V16en/rounded-phrase-cobol-compiler-reference-manual-2022-11-196-22036902.html)说明：在相应定点运算的接收字段里，小数位放不下时，未指定舍入就截去多余位；指定舍入则按该规则处理。文档另列了浮点结果项的例外，不能把这句话概括成“COBOL 一律不舍入”。

用一个纯算术示意：正数 1.239，按截去多余小数位的规则存为 1.23；按这里讨论的舍入规则保留两位，则是 1.24。数字是本文自设的例子，不是真实交易，也不是模型跑出来的失败案例。

两个结果都能被顺利打印在小票上。编译器不会替你决定哪张小票符合这家店的约定。

如果旧程序原本依赖截断，新实现却换成舍入，那么改变的已经不只是语言。它把一项业务行为一起换了，只是改动小到躲在小数点后面。

这也是“看起来更现代”的代码最容易让人放松的地方。变量名清爽了，重复分支合并了，奇怪的处理被统一了。读代码的人终于能舒口气，接收结果的下游却可能开始挠头。

假想的收银台还会遇到别的麻烦：一条空记录以前会留下一个状态码，新实现为了整洁把它跳过；一个固定宽度的编号以前保留前导零，新实现把它当数字再转回来。它们都是需要核对的行为差异，不代表这次发布的模型实际犯过这些错误。

所以，迁移说明里只写“功能保持一致”，就像换收银台时只交代“一切照旧”。小票照样能打，钱照样能收，等晚上一笔笔对账，才发现双方对“一致”的理解不太一致。

![原创迁移边界图：同一输入分别进入旧实现与新实现，比较约定的可观察结果。有差异时先查明原因；若要改变规则，单列变更并由有权决定的人确认。编译通过不能替代行为核对。](https://ai-knowledgepoints.cn/images/commentary/commentary-2026-10-20-migration-behavior-contract/translation-and-change.svg)

AI 辅助制作的原创分析图，非 OpenAI 评测架构。图中流程是本文建议，不含模型实测或迁移成功率；可观察范围和允许变化应在比较前约定。

[查看竖版大图](https://ai-knowledgepoints.cn/images/commentary/commentary-2026-10-20-migration-behavior-contract/translation-and-change-mobile.svg)

## 两张成绩单，别装进同一个收银抽屉

这次公告同时介绍 MultiLangBench：让模型用指定语言实现兼容 SQLite 的数据库引擎。OpenAI 报告 GPT‑6 Astra 在最高推理强度下，20 种语言上的平均测试通过率为 87.4%。[公告里的两项评测](https://openai.com/index/low-resource-programming-languages/)考察不同能力，分数也不能互换。

前面的 97.9%，对应 COBOL 迁移任务，要求该迁移通过全部隐藏测试；这里的 87.4%，是跨语言实现的平均测试通过率。后者不能读成“87.4% 的企业数据库已经可以直接替换”，前者也不是“任何老系统都有 97.9% 的概率迁移成功”。

这不是为了给好消息泼冷水。把成绩读准确，才能知道好消息好在哪里。

[公开仓库在 `995755b` 版本的说明](https://github.com/openai/MultiLangBench/blob/995755bffdba3da60ca367448a1606ba0e50573a/README.md)还有一个很值得保留的细节：它从 SQLite 的约 5.1 万个 TCL 测试中转换出约 2.4 万个；考虑运行成本，默认建议使用其中按名称前缀选出的 272 个，若跑全套则应注明。待测程序修改数据库文件，再由参考 SQLite 执行验证查询、比较预期输出。

这段说明让别人有机会检查“测了什么”。它并不意味着本文已经确认公告中每一个分数具体用了哪个子集；复现成绩时，仍需对齐测试选择和运行条件。公开 MultiLangBench，也不等于公告中的另一套 COBOL 隐藏迁移测试已经全部公开。

收银台的比喻到这里就有边界了。一个固定评测可以统一输入、输出和判分办法，真实系统却可能还连着批处理、外部文件与多年形成的调用约定。某个边界没进入测试，成绩单就没有回答它。本文没有测试这些生产依赖，也不据此断言模型一定处理不好。

更强的模型值得试用；接管一套系统，需要那套系统自己的验收证据。

## 老规矩有错，也别夹在翻译里偷偷修

听到这里，另一种不满很合理：旧程序本来就有问题，难道还要让 AI 原封不动地继承？

当然可以改。只是“保留现有行为”和“批准改变行为”应该分开记账。

如果零头处理确实不符合已经确认的新要求，就把新的处理规则写清楚，让有权决定的人确认，再更新预期结果和测试。这样以后对账时，大家能找到变化发生的理由，而不是从一大团“自动现代化”提交里猜，到底谁动了抽屉。

反过来，如果规则还没弄明白，先让两套实现对同一批获准使用的输入给出结果，再把差异留下来，比直接让模型选择一种它认为更优雅的写法稳妥。正常路径值得比，缺记录、边界值和异常状态也值得比。这里是本文的工程建议，不是对任何真实系统已经完成的迁移方案。

比较范围同样需要事先约定。有的接口要求字节一致，有的允许无关的排版变化；允许变化的部分可以明确定义，不能等测试失败后，再把不一致的地方临时宣布成“无关细节”。

而且，旧实现只能帮助回答“以前怎样”。它不能单独证明“以前就对”。差异核对与业务规则审核解决的是两个问题，不能让其中一个替另一个盖章。

这恰好给 AI 留下了一项比机械翻译更有用的工作：帮助人把代码里藏着的行为找出来，提出可检查的解释，再把关键差异变成能反复执行的测试。做得好，下一位维护者接手时，就不用再靠猜测理解那几行看着很别扭的代码。

更强的迁移能力，不必把懂旧系统的人赶出房间。它可以让这个人少花时间逐行搬运，把精力放在那些只有上下文才能解释的地方：为什么这里不能进位，为什么那条空记录不能直接丢掉。

新收银台可以换，字体可以换，抽屉可以更好拉。零头怎么处理，得有人说清楚。

最好的迁移结果，是代码终于换新了，店里也终于留下了一份能核对的规矩。别等账对不上，才发现助手换收银台时兼任了会计。

资料核对：2026 年 10 月 20 日。新闻引子为 OpenAI 10 月 19 日公告，不是今日发布。成绩来自厂商自报，本文未调用模型、重跑基准或迁移真实业务代码；公开评测说明固定到 MultiLangBench `995755b`。COBOL 语义参照 Fujitsu COBOL2000 文档，具体项目仍须核对编译器、数据定义和运行条件。收银台、空记录与编号场景均为原创假设；图解与验收建议为本文分析。

关于测试分数怎样进入发布决定，可以接着看 [RAG 评测实战：平均分涨了，就能上线吗？](https://ai-knowledgepoints.cn/blog/rag-evaluation-04-release-gates)。讨论入口在[知识星球](https://ai-knowledgepoints.cn/planet)，公众号入口在[关于页](https://ai-knowledgepoints.cn/about#wechat)。

本文文字与图解由 AI 辅助制作，来源已在正文列明。