IBM押注3年的COBOL转译，98.78%通过率让2300亿行

15,552个真实程序，98.78%生成有效Python，零LLM参与。这组数字来自一家叫AGUELLID CODE的法国公司，他们上周刚用IBM的SAM1做了概念验证，这周就把测试规模拉到了全球级别。

这不是又一个AI编程工具的故事。恰恰相反，它刻意避开了AI。

从505行到1.5万：测试是怎么膨胀的

AGUELLID CODE的测试集覆盖131个开源仓库，分布在5个大洲。挪威、法国、巴西、印度、日本、美国——GitHub、HuggingFace、CBT Tape、GnuCOBOL、IBM公开仓库，全部纳入。商业COBOL、GnuCOBOL扩展、TypeCOBOL、大型机方言，不设筛选，能找到的全测。

这种"不挑样本"的做法在代码迁移领域很少见。多数厂商会精心选择演示案例，把转换成功率刷得漂亮。AGUELLID CODE的做法更像压力测试：如果系统能在随机抓取的代码堆里存活，才有资格谈生产环境。

版本迭代的数据对比很直观。v5.6处理14,508个文件，成功率96.84%。v5.8e新增1,044个文件，总量15,552，成功率提升到98.78%。失败案例从456个压缩到190个，净增有效文件1,342个。

更细颗粒度的数据：在v5.7的参考语料上，原本289个失败案例中，180个在一次调试会话中被修复，成功率达到99.25%。

"有效Python"的判定标准有多苛刻

AGUELLID CODE对"有效"的定义是ast.parse()零报错。这是Python标准库里的语法解析器，输入字符串，输出抽象语法树，过程中任何SyntaxError都意味着失败。

没有人工复核开绿灯，没有LLM打分放水，没有风格检查浑水摸鱼。二元判定，没有灰色地带。

「人类评审无法覆盖，模型无法幻觉过关。」这是他们的原话。在需要审计追踪的银行、保险、政府系统里，"模型觉得它对"不是有效辩护。

190个失败案例的构成也被完整公开：TypeCOBOL的多级限定和REPLACE语句约60个，GnuCOBOL的GUI、位运算、面向对象和SCREEN SECTION约40个，非标准COBOL如WebSocket和brainfuck解释器约30个，深层STRING/UNSTRING嵌套约25个， exotic大型机特性如CICS内联和复杂EXEC SQL约35个。

这些不是解析器的bug，是标准COBOL解析器预期边界之外的构造。清理器无法修复解析器从未理解的东西。

语义中间层：为什么不是"翻译"而是"转换"

AGUELLID CODE的技术路径和常规代码转换工具不同。他们不直接做COBOL到Python的逐行映射，而是先把COBOL转成语义中间表示，再生成行为等价的Python。

关键区别：等价的是行为，不是代码行数。同样的输入永远产生同样的输出，过程可审计，逻辑可追溯，没有黑箱。

这个设计选择指向一个被低估的行业痛点。全球约有2,200亿行COBOL在生产环境运行，大部分维护困难——写代码的人退休了，文档不全，行为逻辑成了嵌在语法里的机构记忆。

传统现代化方案有几种：重写（风险极高）、封装（技术债转移）、LLM辅助迁移（不可解释）。AGUELLID CODE试图提供第四种：确定性转换，保留行为的同时获得现代语言的可维护性。

IBM的参与值得关注。SAM1是IBM去年推出的COBOL代码模型，但AGUELLID CODE的测试刻意排除了LLM路径。这种"用IBM的工具验证非IBM的方法"的错位，某种程度上是对行业主流叙事的无声反驳。

金融基础设施的现代化正在进入微妙阶段。监管机构对AI生成的代码越来越警惕，欧盟AI法案和美国金融监管机构的指引都在强调可解释性。确定性转换工具可能因此获得政策窗口。

AGUELLID CODE的下一步是攻克那190个失败案例。TypeCOBOL和GnuCOBOL扩展的优先级显然更高——它们代表了开源生态的边缘地带，而边缘地带的覆盖度决定了工具能否从"演示可用"跨越到"生产可用"。

2,200亿行COBOL不会一夜之间消失。但98.78%这个数字意味着，对于相当一部分代码库，"冻结迁移"的决策可能需要重新评估——不是因为它简单，而是因为替代方案的风险收益比正在变化。

当一家法国初创公司用确定性方法逼近99%成功率时，押注LLM路径的巨头们，是否该重新计算自己的置信区间？