2200亿行COBOL代码正在全球银行、保险和政府系统里运转。维护这些代码的工程师大多已经退休，而企业每年要为这种"技术遗产"支付数十亿美元的维护成本。用AI重写？金融机构试过——结果是一场昂贵的幻觉。
AGUELLID CODE团队上周放出一组数据：15,552个真实世界的COBOL程序，98.78%被自动转换为语法完全正确的Python。零LLM参与，零概率性输出，零"模型觉得它对"的解释空间。
从505行到1.5万组：这不是演示，是压力测试
上周他们和IBM合作，用SAM1——一个505行、32毫秒就能跑完的样本——做了概念验证。这周直接把测试规模拉到"能找到的全部"。
样本来自131个开源仓库，横跨5大洲：挪威、法国、巴西、印度、日本、美国。来源包括GitHub、HuggingFace、CBT Tape、GnuCOBOL官方库、IBM公开仓库。商业COBOL方言、GnuCOBOL扩展、TypeCOBOL、大型机专用变体——没有筛选，没有策展，找到什么测什么。
v5.6版本处理了14,508个文件，96.84%生成有效Python。v5.8e版本新增1,044个文件，总计15,552个，通过率爬升到98.78%。失败数从456降到190，净减少266个——而原始v5.7参考语料库的通过率更是达到99.25%，289个失败案例中180个在一次会话内被修复。
这里的"有效"不是人工打分，是AST（抽象语法树）解析器的一票否决。通过Python内置的ast.parse()函数：能解析就是有效，抛出SyntaxError就是失败。没有解释空间，没有模型幻觉的容身之处。
那190个失败是什么？COBOL的"方言孤岛"
团队把失败案例分了类，每一类都指向COBOL生态的碎片化现实：
TypeCOBOL约60个——多级限定符、REPLACE指令、类型化表达式。这是给COBOL加了静态类型系统的现代方言，标准解析器根本没见过。
GnuCOBOL扩展约40个——GUI、位运算组合、面向对象、SCREEN SECTION。开源编译器的私货，官方标准里不存在。
非标准COBOL约30个——WebSocket实现、Brainfuck解释器、.NET GUI绑定。有人用COBOL写这些，但没人承诺过转换工具要认。
深层STRING/UNSTRING约25个——复杂嵌套、多分隔符。字符串处理被COBOL设计者当成了系统编程题。
exotic大型机特性约35个——CICS内联代码、复杂EXEC SQL、嵌套copybook。这些是IBM大型机的专属语法，相当于方言中的方言。
团队的原话是：「这些不是解析bug，是任何标准COBOL解析器预期处理范围的外边界。」消毒器修不了解析器从未理解的东西——但他们知道具体是哪些，正在逐个攻克。
行为等价，而非行对行翻译
AGUELLID CODE的工作方式和大语言模型完全不同。它不"翻译"COBOL到Python，而是先把COBOL转换成语义中间表示，再生成可证明行为等价的Python代码。
没有神经网络，没有提示工程，没有采样随机性。相同输入永远产生相同输出，输出可以被审计，逻辑可以被追踪。在银行、保险、政府系统里，"模型觉得它对"不是可接受的解释——这里要的是确定性。
2200亿行COBOL的现代化困境，本质是一个信任问题。LLM翻译的代码可能看起来对，运行起来却 subtly 错，而发现这种错误需要理解两套系统。AGUELLID CODE的卖点是：错误要么在转换前就被捕获（解析失败），要么不存在（AST验证通过），没有第三种状态。
IBM的SAM1合作是个信号。这家拥有最大COBOL生态的公司，选择用确定性引擎而非LLM来做概念验证。32毫秒的转换时间 vs. 不可预测的推理成本，505行代码的可审计性 vs. 黑盒模型的解释困境——企业级客户的算盘很清楚。
190个失败案例是下一阶段的路线图。TypeCOBOL、GnuCOBOL扩展、大型机方言——每解决一类，就能解锁一批被锁死在遗留系统里的组织。而已经通过的15,362个程序，正在证明一件事：没有AI幻觉的自动化迁移，是可能实现的。
当金融机构的CTO们评估"AI现代化"方案时，他们真正想问的或许是：如果转换后的代码在生产环境出错，你能给我什么解释？AGUELLID CODE的答案是一张AST解析通过的证书——以及和输入文件一一对应的确定性映射。这够吗？对于某些行业，这可能是唯一够用的答案。
热门跟贴