我们在 15,552 个真实世界的程序上验证了我们的 COBOL-to-Python 引擎。98.78% 生成有效的 Python。未使用任何 LLM。
发布: (2026年4月5日 GMT+8 12:39)
5 分钟阅读
原文: Dev.to
Source: Dev.to
请提供您希望翻译的正文内容，我将按照要求保留源链接并翻译其余部分。
语料库
15,552 个 COBOL 源文件——不是合成基准，而是从遍布五大洲的 131 个开源仓库中收集的真实程序：
- 挪威、法国、巴西、印度、日本、美国
- GitHub、HuggingFace、CBT Tape、GnuCOBOL、IBM 公共仓库
- 商业 COBOL、GnuCOBOL 扩展、TypeCOBOL、主机方言
没有选择偏差，没有策划的样本——收录了我们能找到的全部内容。
结果
| 版本 | 处理的文件数 | 有效的 Python | 失败数 | 净增益 |
|---|---|---|---|---|
| v5.6 (之前) | 14,508 | 14,020 (96.84 %) | – | – |
| v5.8e (之后) | 15,552 (+1,044) | 15,362 (98.78 %) | 456 | +1,342 文件 |
在原始的 v5.7 参考语料库中，成功率为 99.25 %；在一次会话中纠正了 289 次失败中的 180 次。
什么是“有效的 Python”
我们 不 使用 LLM、字符串比较或风格检查。验证是通过 ast.parse() 完成的：
- 如果生成的 Python 代码在解析时没有抛出
SyntaxError，则视为有效。 - 如果抛出
SyntaxError，则视为失败。
这种二进制、确定性的检查不留解释或幻觉的余地。
什么失败以及原因
190 个文件仍然失败。它们的分类如下：
| 类别 | 大约数量 | 典型问题 |
|---|---|---|
| TypeCOBOL | ~60 | 多层限定、REPLACE、带类型的表达式 |
| GnuCOBOL 扩展 | ~40 | GUI、位运算组合、面向对象、SCREEN SECTION |
| 非标准 COBOL | ~30 | WebSocket、brainfuck 解释器、.NET GUI |
| 深层 STRING/UNSTRING | ~25 | 异构大型机构造 |
| 异构大型机 | ~35 | 复杂嵌套、多分隔符 |
| CICS 内联 / EXEC SQL | – | 复杂的 EXEC SQL、嵌套 copybook |
这些不是解析错误，而是位于任何标准 COBOL 解析器能够处理的边界之外的构造。清理器无法修复解析器根本未能理解的内容。我们正在积极处理这些问题。
工作原理
AGUELLID CODE 不 直接将 COBOL 翻译为 Python。它：
- 将 COBOL 转换为语义中间表示。
- 生成在行为上可证明等价的 Python——逐行为等价，而非逐行对应。
整个过程不涉及神经网络、提示词或抽样。转换是确定性的：相同的输入始终产生相同的输出，且可以审计和追踪。没有黑箱。
为什么这很重要
- 估计有 220 billion 行 COBOL 仍在活跃生产中。
- 大多数运行在组织已无法维护的系统上；原始工程师已退休，文档不完整。
- 对这段代码进行现代化改造是许多行业的生存问题，而非风格选择。
当前方法
- 手动重写 – 成本高、速度慢、易出错。
- LLM 翻译 – 非确定性、不可审计、在旧语法上有高幻觉风险。
- 转译器 – 脆弱、浅层、在复杂结构上会失败。
AGUELLID CODE 提供一种确定性、可审计的解决方案，在 15,552 个真实文件上实现 98.78 % 的成功率，且 零 LLM。
接下来是什么
剩余的190个失败对应特定的解析器缺口。我们正按收益/风险比进行处理；仅凭某些TypeCOBOL模式就能通过一次微补丁恢复20–30个文件。
目标： 在完整扩展语料库上实现99.2 %–99.5 %的成功率。
锻造仍在进行中。
KIVUMIA — AGUELLID CODE v5.8e
验证时间：2026‑04‑05 03:27 UTC
语料库：131个来源，15,552个文件，覆盖5大洲
引擎：确定性，无大型语言模型
