AI 把旧系统改写好了，原来的业务规则还在吗？

没报错，也可能算错了#

设想一个旧系统处理金额时，只保留规定的小数位，直接舍去后面的数字。AI 把代码改写成另一种语言，顺手换成了更常见的四舍五入。新程序能启动，页面正常，也没有异常日志，账上的结果却变了。

这个例子来自 OpenAI 10 月 19 日发布的低资源编程语言研究。所谓低资源，是模型能接触到的代码和文档相对较少，并不是系统不重要。

对接手旧系统的团队，难点往往在这里：需求没有写全，有些业务约定只留在代码里。迁移时既要换掉实现方式，又不能顺手丢掉用户依赖的行为。

我认为，开始让 AI 改写之前，产品团队首先要回答的不是“改用哪门语言”，而是“什么结果必须保持一致”。

同样是通过率，验收对象并不一样#

OpenAI 这次用了两类任务。

一类是 MultiLangBench：让模型用 20 种语言从头实现兼容 SQLite 的数据库，统计测试通过比例。另一类是把 COBOL 程序迁移到其他语言，要求所有隐藏测试通过，可观察输出逐字节一致，才把该程序计为成功。

在后者的低推理强度设置下，GPT-6.1 Sol 的准确率是 86.6%，GPT-5.6 Sol 是 5.4%，前者 API 成本为后者的 61%；GPT-6.1 Sol 在更高推理强度下达到 97.9%。这些是厂商特定评测结果，不是生产迁移成功率，也不是总项目成本。

对产品判断更有用的是这两种口径的差别：通过大部分测试，可以说明开发取得进展；一个关键金额规则不一致，却仍可能阻止某个模块替换旧系统。不能用大量普通用例通过，抵消一项关键业务错误。

先分清：要保留的规则，还是要修掉的问题#

下面是我对迁移项目的建议，不是该研究已经验证的实施方案。

第一步，让业务负责人把行为分成三类。

• 必须保留：金额精度、状态变化、缺失记录怎么处理、对外输出格式等已有约定。
• 明确要改：确认过的旧缺陷或新需求，为它们写下新的预期结果和批准人。
• 暂时不清楚：没人能解释的特殊分支，先找历史记录或维护者核对，不让模型自行猜一个“更合理”的规则。

这一步很容易被代码翻译掩盖。旧系统也可能有错，逐字复制并不总是目标；但把旧错修掉，是一次业务变化，应该与“原样迁移”分别验收。

例如，客户一直按某种舍入方式核对账单。即使新方式更符合团队习惯，也不能在换语言时悄悄切换。否则出问题后，很难判断究竟是迁移错误，还是需求本身发生了变化。

用同一批输入，检查差异在哪里#

可以先选一个边界清楚、能独立回退的模块。准备脱敏且获准用于测试的案例，让旧程序和新程序分别处理，比较输出与最终状态。

正常流程要测，边界也要单独列出：缺失字段、空记录、重复请求、金额临界值、执行到一半失败。这里的案例是建议检查项，不是 OpenAI 已披露的测试清单。

发现差异后，不要只统计“失败一项”。先判断它属于哪一类：新程序漏了规则、旧程序存在已确认缺陷、测试预期有误，还是需求尚未澄清。高影响且未解释的差异应挡住替换，而不是被平均分稀释。

如果系统还有外部依赖，输出一致也不够。例如返回结果相同，却多写了一次记录，仍然可能伤害业务。测试要检查任务结束后的实际状态，而不只检查回复文字。

测试样本，也要说明范围#

MultiLangBench 的公开说明还有一个值得借鉴的细节：约 2.4 万项可转换测试中，默认运行 272 项，也允许注明后运行全量；不匹配、崩溃或单项超过 60 秒都算失败。环境提供文档，但不允许联网或直接调用现成 SQLite。

这些条件让读者知道分数是怎么来的。它们属于数据库评测，不能套到前面的 COBOL 迁移任务。主文也没有明确各项公布成绩使用了哪种测试规模。

同样，自己的验收报告需要写清测了哪些业务、没覆盖哪些依赖、是否用过这些样本反复调试。通过已有测试，只能支持已覆盖范围内的判断。

来源与边界#

• 原始研究：OpenAI 于 2026 年 10 月 19 日发布的低资源语言评测，包含数据库构建与 COBOL 迁移两类任务。本文没有运行或独立复现这些评测。
• 配套材料：官方 MultiLangBench README，固定到上述提交版本。其测试选择和环境规则仅用于解释该数据库评测。
• 未披露之处：所读主文未给出 COBOL 迁移样本数、完整执行预算、误差范围和生产错误率。API 成本不含完整迁移项目的人力、验证与切换成本。
• 本文判断：行为分类、差异复核、分模块替换与回退，是面向产品工作的建议，不能当作研究已经证明的收益。

旧系统迁移完成的标志，不只是新代码可以运行。团队还要能说明：哪些业务行为留下了，哪些变化经过确认，剩余哪些风险暂时不能放行。