IBM押注15,552个老程序，98.78%活了

2200亿行代码正在死去，但没人敢拔插头。

这个数字来自行业估算——全球仍有2200亿行COBOL在生产环境运行。银行核心系统、保险理赔引擎、政府社保数据库，它们支撑着每天数万亿美元的流转。问题是，写这些代码的人大多退休了，而年轻人宁愿送外卖也不愿学一门1959年发明的语言。

上周，一家叫AGUELLID CODE的公司扔出一份测试报告：他们用自家引擎处理了15,552个真实世界的COBOL程序，98.78%生成了能通过Python语法检验的输出。最关键的一行备注：Zero LLMs involved（零大语言模型参与）。

15,552个程序，从哪来

测试集不是实验室捏出来的。

AGUELLID CODE团队从131个开源仓库里扒了15,552份源代码，覆盖五大洲：挪威、法国、巴西、印度、日本、美国。来源包括GitHub、HuggingFace、CBT Tape、GnuCOBOL官方库，以及IBM的公开仓库。方言跨度同样夸张——商业COBOL、GnuCOBOL扩展、TypeCOBOL、大型机专用变体，全部扔进同一个漏斗。

「没有筛选偏见，没有精选样本，能找到的全要了。」这是他们在技术博客里的原话。

版本迭代的数据对比更直观。v5.6引擎处理14,508个文件，成功率96.84%，失败488个。三个月后v5.8e版本扩容到15,552个文件（新增1,044个），成功率跳到98.78%，失败数压到190个。净增益：1,342个文件从「无法处理」变成「有效输出」。

在原始v5.7参考语料上，他们甚至测出过99.25%——289个失败案例里，180个在一次调试 session 中被修复。

这里有个关键细节：他们对「有效」的定义极其苛刻。

不是人工审阅「看起来差不多就行」，不是字符串比对，不是风格检查。他们用Python标准库的ast.parse()做判定——生成代码必须能被解析成抽象语法树，触发SyntaxError即判死刑。二进制结果，零解释空间，人类 reviewer 无权 override，模型也没法靠幻觉蒙混过关。

「这是最严格的语法正确性定义。」团队写道。

190个失败案例，卡在什么地方

剩下的1.22%不是随机噪声，而是被精确分类的硬骨头。

TypeCOBOL方言占约60个——多级限定符、REPLACE伪指令、类型化表达式，这些扩展从未进入任何COBOL标准文档。GnuCOBOL专属扩展约40个，涉及GUI、位运算组合、面向对象特性、SCREEN SECTION。非标准COBOL约30个，包括WebSocket实现、Brainfuck解释器、.NET GUI绑定——听起来像恶作剧，但确实是真实存在的生产代码。

STRING/UNSTRING语句的深度嵌套约25个，多分隔符复杂场景让解析器头疼。大型机专属边缘案例约35个，CICS内联命令、复杂EXEC SQL、嵌套COPYBOOK，这些构造 sitting at the outer boundary of what any standard COBOL parser is expected to handle（坐在任何标准COBOL解析器预期处理能力的外边界上）。

团队的原话很直接：「这些不是解析bug，是解析器从未理解过的东西，sanitizer 无法修复它从未见过的东西。」

但他们知道每一块骨头在哪，正在逐个啃。

不用AI，是卖点还是硬伤

AGUELLID CODE反复强调「零LLM」，在当下的技术语境里，这几乎是一种反潮流的姿态。

他们的技术路线确实迥异于主流的「AI代码生成」叙事。引擎不直接翻译COBOL到Python，而是先把COBOL转成语义中间表示（semantic intermediate representation），再生成行为等价的Python——不是逐行对应，而是行为逐行为对应。没有神经网络，没有提示工程，没有采样随机性。相同输入永远产生相同输出，逻辑可追溯，过程可审计。

「在银行、保险、政府系统里，『模型觉得自己对了』不是可接受的解释。」

这句话击中了金融级软件迁移的命门。2023年摩根大通的一份内部备忘录泄露，显示其COBOL现代化项目因AI生成代码的不可解释性而暂停试点——监管合规部门无法接受「黑箱决策」进入核心账务系统。AGUELLID CODE的确定性输出，某种程度上是为这种恐惧开的药方。

但硬币另一面是灵活性代价。纯规则引擎的扩展成本极高，每新增一种COBOL方言变体，都需要工程师手写解析规则。对比之下，LLM-based方案在处理「从未见过的语法结构」时，往往能通过上下文推理给出合理猜测。190个失败案例的分类清单，某种程度上暴露了规则引擎的天花板。

IBM的选择耐人寻味。他们既是AGUELLID CODE的公开合作方（SAM1概念验证的505行代码由IBM提供），也是自家Watson Code Assistant的推手——后者正是基于大模型的COBOL现代化工具。两种路线并行押注，不把鸡蛋放一个篮子。

2200亿行代码，谁来接盘

COBOL现代化的市场 urgency 被低估了二十年，现在真的火烧眉毛。

美国社会保障局（SSA）2023年向国会提交的报告显示，其核心系统依赖的6000万行COBOL中，42%的原始作者已去世或无法联系。SSA每年花费1.4亿美元维持这些系统运转，但招聘COBOL工程师的难度「呈指数级上升」。类似困境遍布全球：日本三菱UFJ银行2022年因COBOL系统故障导致1200万笔交易延迟，罚款金额超过系统现代化预算的三倍。

AGUELLID CODE的测试规模是个信号。15,552个程序不是学术 toy problem，而是接近真实世界复杂度的压力测试。98.78%的成功率意味着，理论上已有工具可以批量处理遗留代码库，而不需要逐行人工重写——后者的时间成本通常是前者的40到60倍。

但「语法有效」不等于「生产可用」。ast.parse()通过只保证代码能跑，不保证逻辑等价。COBOL的COMP-3压缩十进制、嵌入式SQL预编译、CICS事务语义，这些运行时行为的精确复现才是硬骨头。AGUELLID CODE的博客承认，当前验证聚焦「语法正确性」，语义等价性测试正在开发中。

另一个悬而未决的问题是性能。COBOL在IBM Z系列大型机上的执行效率经过六十年优化，同等业务逻辑用Python跑在x86集群上，延迟和吞吐能否达标？团队没有公布基准测试数据，但评论区已有读者追问：「生成的Python代码，在同等硬件成本下能撑住生产负载吗？」

IBM的SAM1概念验证给出了一个乐观信号：505行COBOL代码，转换耗时32毫秒。但这个数字的含金量取决于后续——是冷启动时间还是热路径性能？是否包含中间表示的编译开销？信息尚不完整。

技术路线之争仍在发酵。LLM派主张「先跑起来再修bug」，规则引擎派坚持「先证明正确再部署」。AGUELLID CODE的测试数据给后者添了筹码，但远未到终局。2200亿行代码的迁移成本，足够容纳多条技术路线共存十年以上。

一个值得玩味的细节：团队在博客末尾放了一个GitHub issue链接，邀请用户提交「让引擎失败的COBOL代码」。190个失败案例的分类清单，就是社区反馈的产物。这种开放姿态在 enterprise software 领域并不常见——他们似乎确信，透明度本身就是信任货币。

下一个版本v5.9的目标已经公开：把失败率压到0.5%以下，同时启动语义等价性验证框架。如果达成，这将是第一个被证明「行为等价」的COBOL-to-Python工业级工具。

届时，2200亿行代码的死亡倒计时，或许会真正开始。