一家店换了收银台。新机器启动快，界面漂亮，连小票上的字体都精神了。
晚上对账，老会计发现零头对不上。负责翻新的助手很委屈：以前的小数处理太土了，我顺手改得更规范了。
这段情节是虚构的。可它很适合摆在 AI 代码迁移的演示屏旁边：程序换了一种写法，收钱的规矩也可以顺手换吗？
2026 年 10 月 19 日，OpenAI 发布了低资源编程语言能力评测，覆盖从零构建与旧程序迁移两类任务。这里的“低资源”指可供模型学习的代码和文档相对少，不是说运行它们的机器内存小。
其中，厂商报告 GPT‑6.1 Sol 在较高推理强度下，COBOL 迁移评测准确率达到 97.9%。判定并不只是编译成功：迁移后的可观察输出要通过全部隐藏测试，并与预期逐字节一致。这是 OpenAI 自报结果，本文没有独立复现。
这条进展值得认真看。模型更能处理老语言，可能让原本没人敢碰、改一次要来回查很久的代码，终于有机会被梳理。
但比“终于能翻译了”更重要的，是翻译时哪些东西不能擅自变得更漂亮。
那一分，可能就藏在接收字段里#
比如，把一个正数结果存进只能保留两位小数的字段，超过的部分怎么处理？
不能只回答“四舍五入呗”。Fujitsu 的 COBOL2000 编译器文档说明：在相应定点运算的接收字段里，小数位放不下时，未指定舍入就截去多余位；指定舍入则按该规则处理。文档另列了浮点结果项的例外，不能把这句话概括成“COBOL 一律不舍入”。
用一个纯算术示意：正数 1.239，按截去多余小数位的规则存为 1.23；按这里讨论的舍入规则保留两位，则是 1.24。数字是本文自设的例子，不是真实交易，也不是模型跑出来的失败案例。
两个结果都能被顺利打印在小票上。编译器不会替你决定哪张小票符合这家店的约定。
如果旧程序原本依赖截断，新实现却换成舍入，那么改变的已经不只是语言。它把一项业务行为一起换了，只是改动小到躲在小数点后面。
这也是“看起来更现代”的代码最容易让人放松的地方。变量名清爽了，重复分支合并了，奇怪的处理被统一了。读代码的人终于能舒口气，接收结果的下游却可能开始挠头。
假想的收银台还会遇到别的麻烦：一条空记录以前会留下一个状态码，新实现为了整洁把它跳过；一个固定宽度的编号以前保留前导零，新实现把它当数字再转回来。它们都是需要核对的行为差异，不代表这次发布的模型实际犯过这些错误。
所以，迁移说明里只写“功能保持一致”，就像换收银台时只交代“一切照旧”。小票照样能打，钱照样能收，等晚上一笔笔对账，才发现双方对“一致”的理解不太一致。
两张成绩单，别装进同一个收银抽屉#
这次公告同时介绍 MultiLangBench：让模型用指定语言实现兼容 SQLite 的数据库引擎。OpenAI 报告 GPT‑6 Astra 在最高推理强度下，20 种语言上的平均测试通过率为 87.4%。公告里的两项评测考察不同能力，分数也不能互换。
前面的 97.9%，对应 COBOL 迁移任务，要求该迁移通过全部隐藏测试；这里的 87.4%，是跨语言实现的平均测试通过率。后者不能读成“87.4% 的企业数据库已经可以直接替换”，前者也不是“任何老系统都有 97.9% 的概率迁移成功”。
这不是为了给好消息泼冷水。把成绩读准确，才能知道好消息好在哪里。
公开仓库在 995755b 版本的说明还有一个很值得保留的细节：它从 SQLite 的约 5.1 万个 TCL 测试中转换出约 2.4 万个；考虑运行成本，默认建议使用其中按名称前缀选出的 272 个，若跑全套则应注明。待测程序修改数据库文件，再由参考 SQLite 执行验证查询、比较预期输出。
这段说明让别人有机会检查“测了什么”。它并不意味着本文已经确认公告中每一个分数具体用了哪个子集；复现成绩时，仍需对齐测试选择和运行条件。公开 MultiLangBench，也不等于公告中的另一套 COBOL 隐藏迁移测试已经全部公开。
收银台的比喻到这里就有边界了。一个固定评测可以统一输入、输出和判分办法，真实系统却可能还连着批处理、外部文件与多年形成的调用约定。某个边界没进入测试，成绩单就没有回答它。本文没有测试这些生产依赖，也不据此断言模型一定处理不好。
更强的模型值得试用；接管一套系统，需要那套系统自己的验收证据。
老规矩有错，也别夹在翻译里偷偷修#
听到这里，另一种不满很合理：旧程序本来就有问题，难道还要让 AI 原封不动地继承？
当然可以改。只是“保留现有行为”和“批准改变行为”应该分开记账。
如果零头处理确实不符合已经确认的新要求，就把新的处理规则写清楚，让有权决定的人确认，再更新预期结果和测试。这样以后对账时，大家能找到变化发生的理由，而不是从一大团“自动现代化”提交里猜，到底谁动了抽屉。
反过来，如果规则还没弄明白，先让两套实现对同一批获准使用的输入给出结果，再把差异留下来，比直接让模型选择一种它认为更优雅的写法稳妥。正常路径值得比，缺记录、边界值和异常状态也值得比。这里是本文的工程建议，不是对任何真实系统已经完成的迁移方案。
比较范围同样需要事先约定。有的接口要求字节一致，有的允许无关的排版变化；允许变化的部分可以明确定义，不能等测试失败后，再把不一致的地方临时宣布成“无关细节”。
而且，旧实现只能帮助回答“以前怎样”。它不能单独证明“以前就对”。差异核对与业务规则审核解决的是两个问题，不能让其中一个替另一个盖章。
这恰好给 AI 留下了一项比机械翻译更有用的工作：帮助人把代码里藏着的行为找出来，提出可检查的解释，再把关键差异变成能反复执行的测试。做得好，下一位维护者接手时，就不用再靠猜测理解那几行看着很别扭的代码。
更强的迁移能力，不必把懂旧系统的人赶出房间。它可以让这个人少花时间逐行搬运，把精力放在那些只有上下文才能解释的地方：为什么这里不能进位，为什么那条空记录不能直接丢掉。
新收银台可以换，字体可以换，抽屉可以更好拉。零头怎么处理，得有人说清楚。
最好的迁移结果，是代码终于换新了，店里也终于留下了一份能核对的规矩。别等账对不上，才发现助手换收银台时兼任了会计。
资料核对：2026 年 10 月 20 日。新闻引子为 OpenAI 10 月 19 日公告，不是今日发布。成绩来自厂商自报，本文未调用模型、重跑基准或迁移真实业务代码；公开评测说明固定到 MultiLangBench 995755b。COBOL 语义参照 Fujitsu COBOL2000 文档，具体项目仍须核对编译器、数据定义和运行条件。收银台、空记录与编号场景均为原创假设；图解与验收建议为本文分析。
关于测试分数怎样进入发布决定，可以接着看 RAG 评测实战：平均分涨了，就能上线吗？。讨论入口在知识星球，公众号入口在关于页。
本文文字与图解由 AI 辅助制作，来源已在正文列明。
