一篇论文的标题叫《AI migrated legacy COBOL programs to Java, bugs included》,听着像是在讲AI翻车。但点进arXiv原文才发现,这篇论文压根不是来报告bug清单的,它讲的是一套怎么验证AI迁移代码对不对的方法。
标题和内容之间的落差,本身就值得说一说。
论文到底做了什么
核心是一个叫"Locksmith Loop"的智能体测试合成方法,目标很朴素:COBOL翻译成Java之后,怎么知道翻译对了。
传统做法靠人工写测试用例,靠人工审查边界条件。但COBOL系统往往几十年没人管,测试数据早就丢了,人工根本盯不过来所有分支。这篇论文想干的事,是把"迁移对不对"从主观审查变成一道可以自动跑的确定性题目。
具体路径是这样的:COBOL源码和生成的Java代码各自搭一套带mock的运行环境,脱离大型机,在普通机器上跑。然后智能体循环做Witness Search,不断尝试输入,去撬开程序里那些没被走到的分支;找到能穿透的路径后,再做parity-preserving mutation——变异输入,但保证两边语义等价的比对逻辑不变。
遇到怎么都撬不开的分支,系统会把它标记为Locked Paragraph,相当于诚实地说:这里我也没验证到。
91.90%,离及格线还差多少
三个案例研究,两个开源程序、一个内部生产级COBOL程序,规模从430行到4114行不等。两个开源项目上,覆盖率接近完全;内部生产级程序上,分支覆盖率是91.90%。所有被接受的测试用例里,生成的Java代码在确定性parity检查下都和COBOL参照行为一致。
这组数字第一眼看是漂亮的。但拆开看,至少三处需要打个问号。
样本量小。三个案例,最大规模4114行。真实企业级COBOL系统动辄几十万行,几十年历史,一堆嵌套COPYBOOK和JCL依赖。这套方法在小样本上跑通,不等于能在真实规模上复现同样的覆盖率。
91.90%不是100%。剩下的将近一成分支,恰恰是最容易被本方法自己标记为"Locked Paragraph"的角落逻辑——罕见异常处理、历史遗留补丁,这些往往是生产事故最爱藏身的地方。
原COBOL自身的bug会怎样。这套方法验证的是"生成代码和原COBOL行为一致",如果原COBOL本身带着几十年积累的历史bug,迁移后的Java忠实复现了这个bug,parity检查一样会判定通过。它验证的是一致性,不是正确性。
- 提醒.这套方法目前只有论文作者自陈的数据,联网检索没有找到任何独立于原作者的第三方复现、社区讨论或行业工程师的实测反馈。
该怎么看这类论文
COBOL现代化是个老问题。金融、保险、政府核心系统里,COBOL还在跑,懂的人越来越少,"用AI迁移"几乎是必然选项。但业界早就见识过一个通病:AI翻译出来的代码能编译,却常在十进制精度、隐式类型转换、字符集处理这些细节上悄悄走样。传统单元测试覆盖率抓不住这种偏差,尤其在迁移前后都没有完整测试数据的情况下。
这篇论文想解决的正是这个,思路是对的:与其靠人工盯细节,不如把"迁移对不对"变成一道可编程、可复现的测试问题。这个方向值得肯定。
但一套"用AI验证AI"的工具,自己也需要被验证。目前这套工具还停留在自证阶段,三个样本,没有第三方审阅,离能替代人工把关的成熟度还有距离。
覆盖率91.90%,读作进步还是警示,取决于你信不信剩下那8%里没有雷。
下次再看到"AI+覆盖率百分比"这类论文报道,值得多问几句:样本量多大、覆盖率距离100%差多少、未覆盖的部分对应什么风险逻辑、有没有独立于作者的复现。数字好看不等于问题解决,尤其是在遗留系统这种"魔鬼在细节里"的领域。