一句话看懂：开发者尝试用 AI 把遗留 COBOL 程序迁移到 Java，结果发现 AI 连旧系统里的错误也一并“翻译”了过来。这个案例再次说明：AI 代码转换和真正意义上的系统现代化之间，还隔着巨大的差距。
事件核心：发生了什么
Hacker News 的一个讨论帖中，有开发者分享了用 AI 将遗留 COBOL 系统迁移到 Java 的经历。表面上代码顺利转换，但 AI 同时把原有业务逻辑中的 bug 也复制到了新系统。有评论者回忆，一个早已离职的老员工曾指出某处错误其实源于数据库厂商的旧缺陷，公司因财务困难取消了维护合同，这个问题一直遗留至今——而 AI 迁移不仅没有修复它，反而让它“延续”到了新代码里。
参与讨论的资深工程师还指出，COBOL 与 Java 的数值处理模型存在根本差异：COBOL 以固定小数点运算为特色，而 Java 中 0.1 + 0.2 会得到 0.30000000000000004。除非在迁移中全程使用 BigDecimal，否则涉及金融计算的逻辑可能从迁移第一天起就是错的。
为什么重要
这是 AI 编程工具进入核心业务系统改造时一次很典型的现实检验。银行、保险、政府机构中仍存在大量 COBOL 系统，COBOL 工程师逐年减少，这让管理层很容易把“AI 迁移”看作高效的替代方案。但本次讨论揭示了一个关键问题：AI 能在语法层面完成翻译，却无法理解系统背后的业务约束。
COBOL 的固定小数点运算、批处理模式与 Java 的对象模型、浮点机制本就有本质差异；更复杂的是，很多遗留系统的行为已经被几十年的补丁和“只有老员工知道”的隐含规则所定义。AI 复制的是代码，无法复制这些历史经验。一旦缺失这种“领域智慧”，AI 生成的新系统可能看起来运行正常，却会在对账、计费或合规报表等关键环节埋下隐患。
对用户/开发者/创作者的影响
对开发者而言，不要盲目相信 AI“一键迁移”遗留系统。AI 适合把 COBOL 代码快速转成较易读的 Java 初稿，但后续的架构设计、数据迁移、并行测试和对照验证仍需要经验丰富的工程师把关。尤其是金融、交易类场景，必须逐条核对业务规则，而非只做编译层面的验证。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对技术管理者来说，这个案例也是一个实用提醒：AI 并没有让“技术债”自动消失，而是可能把旧债变成更难追踪的新债。迁移项目的预算中，数据迁移、回归测试和双系统并行运行的成本，往往比 AI 工具本身的费用高得多。如果系统仍能稳定运行，更稳妥的路线或许是保留 COBOL 后端，通过 API 或数据仓库把核心能力暴露给新应用，而不是贸然推倒重写。
值得关注的后续
第一，看 AI 代码工具是否会针对 COBOL 等遗留语言推出专门的迁移模式，加入对十进制运算、文件处理和批处理语义的校验能力。第二，关注金融与保险行业是否会公开更多 AI 迁移的真实案例——无论是成功还是失败，这些信息都会直接影响企业采购决策。第三，观察大模型在数十万行级遗留代码上，能否从“逐行翻译”演进到“理解业务意图后做合理重构”，这将是 AI 能否真正接管核心系统改造的分水岭。
来源：</strong
