研究团队提出把 AI 锁进笼子一批研究 COBOL 代码迁移的工程师发表论文提出把 AI 锁进笼子论文标题为《Agentic Method for Deterministic Validation of Legacy Code Migration》。他们设计了一个叫 Locksmith Loop 的系统旨在把 AI 限制在一个确定性的框架里让它只做擅长的事。三个模块AI 只碰一个Locksmith Loop 的架构分三层。第一层是 MigratorCOBOL 源码进来Java 目标代码出去这一步不用 LLM用的是确定性 AST 转换器每次跑结果一样。第二层是 Witness Search这是 AI 唯一出场的地方LLM 不断构造输入用例企图穿透程序的所有分支直到覆盖率推不动为止。第三层是 OracleCOBOL 原版和 Java 迁移版同时跑同一个输入输出必须逐位一致任何偏差都视为迁移失败回退修正。这样设计是因为每一步都有明确的失败模式Migrator 和 Oracle 是确定性的Witness Search 是唯一非确定性的环节但它的失败模式可控Locksmith 的设计哲学是把 AI 放在它失败后果最轻的地方。当 AI 推不动了Witness Search 不是万能的跑到某个分支边界时可能会卡住论文里管这种情况叫 Locked Paragraph。系统不指望 AI 能打开所有锁当 AI 推不动时分析器会标记这个 Locked Paragraph然后系统继续推进其他分支最终覆盖率取决于 AI 能找到多少“钥匙”。论文报告了三个测试案例的结果两个开源 COBOL 程序达到了“几乎完全覆盖”生产级程序达到了 91.90%的分支覆盖率剩下的 8.1%对应着最复杂的业务逻辑、最深的嵌套条件、最古老的 corner case。连 bug 一起搬是设计目标架构还有一个反直觉的设计迁移后的 Java 必须和原 COBOL 行为完全一致包括 bug。aldente0630 在 Hacker News 上澄清保留 bug 是明确的设计目标这叫 bug - for - bug compatibility因为那些 bug 已经在生产环境跑了二十年下游系统依赖它们的行为。但 bug - for - bug 有一个前提Oracle 对比的是行为不是代码Java 程序员看到保留 bug 行为的代码时没有任何上下文。4KLOC 和 230KLOCHacker News 上的评论质疑了论文的规模。pacaro 给出真实世界的尺度IRS 一家就有大约 160 个 COBOL 程序平均每个 23 万行代码。fock 试过他们用的代码里内嵌汇编跨十几个文件、5 万行测试的所有 LLM 完全不知道预处理器是什么。这指向了 Locksmith Loop 的真正边界AST 转换器不认识源码里的预处理器宏、内嵌汇编等会直接失败。Zenst 补充了精度问题金融系统的 COBOL 程序通常使用 packed - decimal其精度和舍入行为与 BigDecimal 并不完全等价修复差异意味着在 Migrator 里写越来越复杂的规则。Locksmith Loop 的确定性架构方向是对的但工程复杂度会随系统规模非线性增长。COBOL - in - Javadragonwriter 在 HN 上点出架构最深层的矛盾唯一现实的低错误率方案是确定性转译但得到的是 COBOL - in - Java跑起来正确但维护起来是噩梦。确定性转换的产物语法是 Java灵魂是 COBOL人类程序员做迁移时会重新理解系统意图用新语言的惯用方式重新表达这引入了风险但能产出可维护代码Migrator 选择了零风险路径但付出了可维护性的代价把没人懂的老系统变成了没人懂的新系统。论文没说的东西Locksmith Loop 的架构设计是对的把 AI 限制在测试生成把翻译和验证留给确定性代码可能是 AI 在严肃软件工程中唯一可靠的使用方式。但它回避了一个更大的问题迁移 COBOL 系统的真正瓶颈是理解这个系统在做什么。论文假设 Oracle 是给定的但在真实场景里COBOL 系统可能跑不起来Oracle 本身就是一个需要重建的东西。这不是 Locksmith Loop 的错这是一个验证方法论文不是迁移工程论文。