把旧程序翻译成新语言，最危险的结果不是编译失败，而是运行正常、业务数字却悄悄变了。OpenAI在10月19日发布MultiLangBench评测，并披露另一组COBOL迁移实验，把“写出代码”和“保留原行为”放进不同考场。前者横跨20种编程语言，最高平均测试通过率为87.4%；这个成绩不等于企业旧系统已经可以无人值守地迁移。

快速看点：公开基准要求模型重建兼容SQLite的数据库引擎；测试比较数据库实际结果，不只看代码外观；COBOL迁移则要求可观察输出逐字节一致。两组实验互补，却不能把一组的开放代码当作另一组隐含测试也已全部公开。

少见语言的难题，往往藏在业务行为里

编程模型的训练与使用环境常围绕Python、JavaScript等常见语言展开，但企业仍有由COBOL、Fortran或Visual Basic维护的系统。困难不只是语法旧：文档可能不齐，开发者可能离开，边界处理与业务规则却仍藏在多年累积的代码里。

迁移团队若只把“能启动、能跑通示例”视为成功，就可能遗漏舍入、空记录、异常分支和文件格式等细节。一个看起来更现代、更易读的实现，未必保留了原系统的所有约定。这也是为什么评测对象需要从生成文本转向实际执行结果，而不是只请模型给另一段代码打分。

这次研究将两类能力拆开：从零搭建复杂软件，考验长期组织功能、维护状态和修复问题；把已有程序迁到另一种语言，则考验对旧行为的理解。企业选型时应先确认自己面对哪一类工作，不能因为模型擅长新建应用，就直接推导它擅长接管历史核心系统。

用SQLite结果作尺子，不只看生成文件

MultiLangBench要求模型在指定语言中实现SQLite 3.40.1兼容引擎。公开仓库把每道测试拆成初始数据库、待执行查询和验证查询：候选程序修改数据库后，再由真正的SQLite检查结果。这给不同语言实现提供了共同的验收界面，减少仅靠代码风格判断质量的问题。

仓库说明，约5.1万项原始TCL测试中，有约2.4万项能转成这一形式；考虑执行成本，建议评测采用其中272项指定子集，若运行全量应说明。要求还包括隔离现成SQLite实现、禁止联网，以及不按目标语言完成时判失败。这类环境隔离应在专用测试容器中完成，不应直接套用于业务生产环境。

这些设计让分数更容易被理解，也暴露出复现时必须控制的变量。测试子集、依赖是否泄漏、执行超时和目标语言判定，都可能改变结果。团队不能只拿一串通过率比较模型，而不检查两次测试是否在同一环境、同一规则下进行。

OpenAI报告GPT-6 Astra在20种语言上的平均测试通过率为87.4%。这是其自报的指定任务成绩，公开材料支持检查方法，不构成独立复测结论；而且平均值也不能代表每种语言都达到同一水平。企业应优先看自己实际使用的语言与失败样本，而不是只看跨语言总分。

迁移成功，要比“没有报错”严格得多

另一组COBOL实验把程序迁往C++、Java、Kotlin、Python或Rust，以隐藏测试检查可观察输出逐字节一致，全部通过才算成功。这项标准抓住了迁移的关键：新系统应保留被依赖的行为，而不是输出一个大致合理的答案。它与MultiLangBench的功能通过率不是同一个指标。

例如定点数的截断和舍入可能导致细微差异，单笔记录看似不明显，累积后却会影响对账。业务方和工程团队需要一起明确哪些差异是允许的改进，哪些必须保持；否则即使代码层面的测试通过，也可能没有覆盖客户、财务或下游接口真正依赖的约定。

公开研究没有消除生产迁移的其他难题。数据库驱动、批处理时序、文件编码、访问权限与外部系统依赖，都会超出一个受控代码任务的边界。通过评测只说明特定任务上的能力进展，不能直接换算成迁移周期、运维费用或企业ROI。

比较成本时也应把审查、补测试、双轨运行和回滚准备计入。模型调用便宜，不代表整体项目便宜；若一次错误需要人工逐条对账，账单之外的代价可能更大。更稳妥的路径通常是先选边界清楚、能重放历史输入的小模块，验证之后再扩大范围。

小编判断：先补验收，再让AI大规模重写

MultiLangBench的价值不只在排行榜，而在于把跨语言编程推进到可执行、可检查的交付物上。对于想维护旧系统的企业，这比一段流畅的代码解释更有用：只有明确结果如何被验证，模型能力提升才有机会进入工程流程，而不是停留在演示里。

真正值得借鉴的顺序，是先固定业务输入与预期输出，再引入迁移工具，最后检查差异及恢复方案。人类专家仍负责定义约束和批准变化，AI负责加速实现与排错。旧系统现代化不是把旧语言清空，而是让重要行为在更可维护的系统中继续可靠运行。