要点： AI驱动的遗留代码现代化让企业终于能够安全地解码并迁移数十年的技术债务。通过提取业务规则而不仅仅是翻译语法，IT领导者能以低得多的风险退役大型机基础设施。
现状背景
支撑全球经济运行的代码，大多是在当今大多数软件工程师出生之前编写的。核心银行系统、政府登记系统和航空网络依然严重依赖大型机架构以及诸如COBOL或RPG等遗留编程语言。多年来，迁移这些系统的高昂成本和运营风险让企业IT部门陷入瘫痪。企业被迫维护日益昂贵的遗留基础设施，而能够操作这些系统的技术人才却在逐渐流失。然而，OpenAI发布的Advancing coding in low‑resource programming languages从根本上改变了这一局面。
一直以来，大型语言模型在遗留环境中表现不佳，因为它们的训练数据主要被Python和JavaScript等现代Web原生语言所占据。通过引入针对低资源语言的定向能力，AI模型如今在那些以往过于小众或数据匮乏、难以实现可靠自动化的领域中，展现出了极高的熟练度。这标志着遗留代码现代化终于从一项棘手且耗时多年的纯人工苦力活，转变为一门可控的、AI辅助的工程学科。
这传递了什么信号 退役大型机系统的主要障碍，不再是缺乏愿意编写遗留语法的工程人才，而是海量缺乏文档记录的业务逻辑。如今，AI已经能够充当数十年技术债务与现代云架构之间的翻译和发现层。
遗留代码现代化的真正挑战
大多数企业团队在面对AI和遗留系统时，最常犯的错误是将迁移视为纯粹的语法翻译问题。他们天真地以为，工程团队只需将COBOL文件丢给大型语言模型，让它输出Java或C#代码，然后把结果部署到生产环境中即可。
这种做法注定会演变成一场灾难。一个有着四十年历史的大型机程序不仅仅是在处理交易；它是企业发展的“地质记录”。它包含了数十年来没有文档记录的合规补丁、早已被遗忘的临时变通方案，以及专门为了弥补20世纪80年代硬件限制而编写的定制逻辑。如果试图进行直接的逐行翻译，你并没有让系统现代化——你只是用现代语言复制了过去的结构性缺陷。最终得到的是“面向对象的COBOL”：这些代码在云环境中或许能勉强编译，但现代软件工程团队根本无法维护。
真正的挑战在于找回代码背后丢失的意图。在编写哪怕一行现代软件代码之前，必须先提取、映射业务规则，并根据当前的实际运营情况进行验证。过去，这个发现阶段会消耗现代化项目绝大部分的预算，需要庞大的业务分析师团队在数百万行未优化的代码中苦苦追踪数据流。低资源AI能力的突破，不仅在于编写新代码，更在于模型能够读取遗留代码库，并生成人类可读的文档、流程图和测试用例，从而解码系统真实的、未记录的行为。
企业实践指南
为了充分利用这些新的AI能力，企业必须放弃高风险的“大爆炸式”重写，转而采用AI辅助的迭代提取流程。我们建议采取分阶段的策略，利用生成式模型来系统性地理解、测试并最终重建遗留资产。
首先，部署AI以映射当前状态并恢复业务意图。将遗留代码库输入安全的、企业级的模型中，以生成全面的文档和架构图。此阶段的目标是将核心业务规则与遗留技术实现（例如旧大型机特有的内存管理权宜之计）分离开来。这能让企业架构师清晰、客观地看到哪些东西确实需要重建，哪些可以安全废弃。
其次，建立由AI生成的、基于意图的测试框架。遗留代码现代化最大的风险之一，是破坏了下游系统所依赖的未记录功能。工程团队必须利用AI读取遗留代码，并生成数百个单元测试和集成测试，以精准捕获当前的输入输出行为。这就构建了一张坚不可摧的安全网，确保现代化后的应用程序在相同条件下与遗留系统表现得完全一致。我们的Decision guide: Legacy rewrite vs AI-assisted modernisation: should you start again or decode what you have?提供了一个严格的框架，帮助企业判断何时该映射现有行为，何时该彻底重构逻辑。
最后，在受治理的流水线中编排翻译和部署工作。不要让开发者从网页界面复制粘贴翻译好的代码片段，而是将AI模型直接集成到CI/CD工作流中。这能确保所有AI生成的代码都会自动接受扫描，排查安全漏洞，验证是否符合现代架构标准以及《欧盟AI法案》（EU AI Act）的合规要求。为了结构化地实现这一集成，领导团队应落实我们白皮书AI–SDLC. From code to intent.中详述的各项原则。
| 场景 | 推荐策略 | 核心风险 |
|---|---|---|
| 无文档记录的核心逻辑 | 在编写任何新代码之前，利用AI生成功能规范和流程图。 | 将20世纪80年代的硬件限制误解为关键业务规则。 |
| 高风险交易数据 | 利用AI生成相同的测试框架，确保新模块完美通过遗留约束测试。 | 隐藏在历史补丁中的边缘用例导致生产环境中发生静默故障。 |
| 孤岛化遗留模块 | 采用迭代的绞杀者模式（strangler-fig pattern），利用AI一次替换一个经过验证的微服务。 | 维持并行基础设施和数据同步的时间过长。 |
角色指南：本季度的行动计划
| 角色 | 本季度优先级 |
|---|---|
| CIO | 叫停纯手工的迁移项目，并强制要求立即开展概念验证，利用AI分析并记录一个孤立的遗留模块。 |
| CTO | 建立受治理的AI-SDLC流水线，严格防止逐行语法翻译，强制要求在编写任何现代代码之前先提取业务逻辑并自动生成测试。 |
| CISO | 实施严格的数据脱敏和清理协议，确保深埋在遗留代码库中的敏感生产数据或硬编码凭证不会被输入到商业AI模型中。 |
检验你战略的压力测试问题
- 我们是否将遗留代码现代化视为一个语法翻译问题，而不是业务逻辑恢复演练？
- 我们的工程团队是否具备所需的自动化工具，能为缺乏文档记录的大型机行为生成测试框架？
- 我们是依赖外部供应商进行手动代码翻译，还是在构建内部的工程成熟度以有效治理AI辅助提取？
- 在AI现代化的代码进入生产环境之前，我们将如何衡量其结构完整性、准确性和安全性？
- 在分析阶段，我们是否在没有充分脱敏的情况下，将专有业务逻辑或受监管的客户数据暴露给了第三方模型？
Juan José López： “使用LLM将COBOL逐行翻译成现代语言，最终只会得到‘面向对象的COBOL’——这是一个无法维护的噩梦。真正的价值在于先用AI解码深埋的业务规则，这样你才能正确地重建架构。”
常见问题
问：我们如何确保AI准确翻译复杂且无文档记录的业务规则？
答： 准确性是通过严格的测试驱动方法实现的，而非盲目翻译。我们建议首先利用AI根据遗留系统精确的输入和输出，生成一套全面的自动化测试套件。AI生成的新现代代码必须完美通过这一相同的测试框架，然后才能由人类工程师进行审查和批准。
问：对于高度受监管的行业，AI辅助的遗留代码现代化安全吗？
答： 安全，前提是它在一个受治理的环境中执行。企业必须使用私有的企业级模型，这些模型不会使用公司数据进行持续训练。此外，工程团队必须实施强力的数据脱敏，确保在分析前剔除遗留数据库中的敏感客户记录或硬编码凭证。
问：与传统的重写相比，AI辅助的大型机迁移预计需要多长时间？
答： 虽然时间表因架构复杂度而异，但发现和文档化阶段（通常是人工重写中最耗费资源的部分）可以利用AI大幅加速。然而，严格的自动化测试和并行运行阶段对于运营稳定性依然至关重要，并最终决定了部署时间表。
问：在迁移过程中使用AI，是否就不再需要大型机专家了？
答： 不是。AI扮演着加速器和发现工具的角色，但人工监督在合规和运营层面仍然不可或缺。我们依然需要领域专家和遗留系统工程师来验证AI生成的功能规范，并确保提取的业务逻辑与实际的企业运营相吻合。
核心结论
被几十年的技术债务绑架的时代正在终结。AI在低资源编程语言领域能力的提升，终于为企业提供了一种可靠、可扩展的机制，能够安全地对核心基础设施进行现代化改造。然而，在这场架构转型的竞争中，赢家不会是那些仅仅把AI当作快速语法翻译器的企业。真正的竞争优势属于那些部署这些模型以系统性地恢复丢失的业务逻辑、构建强大的自动化测试安全网，并在云时代彻底重构其系统的组织。解码过去的技术已经就绪；如今的成功，将完全取决于工程纪律和严格的治理。