ARTICLE · 1258678
AI能不能拯救那些已经没人敢修改的老软件?
AI能不能拯救那些已经没人敢修改的老软件?
从航空调度系统的灾难，到医院HIS的技术债务：让AI重新理解并重建几十年的代码 举个例，一家大型企业，使用了一套二十多年的软件系统。 最初只有十几个工程师开发，后来需求不断增加，开发人员换了一批又一批，数据库越来越复杂，代码从几万行增加到几百万行。 很多功能连现在的开发人员都说不清楚，当初为什么要这样设计。 有些代码没人敢删除，有些数据库字段已经不知道代表什么，甚至只要增加一个新功能，就可能引起其他功能出现莫名其妙的错误。 这就是软件行业经常提到的：屎山代码。 而更尴尬的是，即使所有人都知道这套软件已经严重落后，却仍然没有人敢把它推倒重来，因为它承载着整个企业的日常运行。 银行靠它处理交易，航空公司靠它调度飞机和机组，医院靠它记录患者病历、执行医嘱和管理医疗流程，系统再老，也不能轻易停机。 这在欧美和日本这种老牌国家很常见，他们数字化更早，使用老程序老系统更多。 在日本，很多企业还在使用老式的软盘，老式的传真机，老旧的操作系统和业务系统，用旧的编程语言开发，运行在旧数据库上。 这些古早的系统还在运行，维护人员越来越少，要想升级新功能越来越难。 但是现在，AI的发展让我产生了一个新的想法。 既然AI已经能够分析别人的程序，做到逆向工程，那么对于一家拥有完整源代码、历史数据库和实际业务资料的企业，AI能不能帮助它重新理解整套老系统，然后重新开发一套现代化的软件？ 我认为，这可能是AI在软件工程领域一个非常值得期待的发展方向。 而且，它的价值可能远远超过最近流行的软件逆向工程。 
一个老软件系统，差一点让美国航空业陷入混乱 2022年圣诞节，美国西南航空遭遇了一场严重的运营灾难。 一场冬季风暴打乱了大量航班，原本这属于航空公司需要处理的异常情况，飞机延误，航班取消，飞行员需要重新安排，乘务人员需要调整。 但随着异常越来越多，西南航空的机组调度体系开始难以应对，大量机组人员的位置和后续任务无法及时更新。 调度人员不得不依靠电话、人工操作等方式处理积压的任务。 最后出现了令人难以想象的结果：约16900架次航班被取消，超过200万名旅客受到影响。 美国交通部后来对西南航空处以1.4亿美元的民事处罚。 虽然，这场事故不能完全归咎于一个老软件，极端天气、公司的运营模式、人员配置和应急机制，都有影响，西南航空自己的年报也指出，调度软件在正常条件下能够工作，但突发变化的数量太大，超出了它有效处理的能力。 这件事真正值得反思的是，一个长期运行、平时看起来没有问题的信息系统，在遇到超出原有设计能力的异常情况时，可能让整个企业的业务陷入瘫痪。 2023年，英国空中交通管理机构NATS也发生过类似的系统性运行中断。 一份包含特殊航路点组合的飞行计划，触发了软件的罕见异常，主系统和备份系统都进入安全保护状态，最终影响超过70万名旅客。 值得注意的是，NATS的相关故障子系统并不是几十年前的古老程序，这说明问题不只是软件年龄，更重要的是复杂系统中的隐藏依赖、异常处理和故障恢复能力，可能比正常运行时的功能更加关键。 这也是为什么航空、金融和医疗等行业，对软件升级总是格外谨慎。 
为什么老软件会逐渐变成没人敢碰的屎山？ 很多人以为，是因为程序员水平不好，其实远没有那么简单。 一套软件刚刚开发时，结构可能非常清楚，但是软件并不是开发完成以后就不再变化。 客户会不断提出新需求，法律法规会改变，业务流程会调整，再加上硬件设备更新，数据库升级，原来的开发人员离职。 新来的工程师为了尽快解决问题，可能没有时间研究整个系统，于是最容易采用的方法就是：哪里有问题，就在哪里增加一点代码。 几年以后，这些修改互相依赖，十几年以后，整个软件已经像一栋不断加盖、改建的老房子。 一楼原来是厨房，后来改成仓库，二楼增加了走廊，三楼重新接了水管，地下室甚至保留着二十年前已经不用的线路。 但没有人拥有这栋房子的完整图纸，更可怕的是：房子里一直有人居住，所以你不能简单把它拆掉重建。 这种问题在软件工程中有一个专门的概念：技术债务，Technical Debt，为了快速实现眼前的功能，我们不断借用未来的维护成本。 最初看起来只是节省了一点时间，但几十年以后，利息可能越来越高。 最后，一套软件最昂贵的部分，甚至不再是开发新功能，而是确保增加一个新功能以后，原来的功能不会出错。 
过去为什么不能简单地把老软件全部重写？ 既然旧系统这么难维护，为什么不重新开发一套？ 这听起来很合理，但实际操作非常困难，因为真正复杂的，不只是源代码还有几十年来积累在代码中的业务规则。 举个医院HIS的例子。 某段代码规定：患者出院以后，某些条件下仍然允许补录费用。 这个规则为什么存在？可能是符合医院制度的正常流程，也可能是十几年前为了处理特殊情况加入的补丁。 甚至可能是当年某个工程师临时修改以后，再也没有人清理。 如果重新开发软件，到底应该保留这段逻辑，还是删除？ 原来的开发人员可能已经退休，需求文档也找不到了，现在的使用人员只知道“以前一直是这样操作的” 这其实是传统软件重写最困难的部分，我们不仅需要重新写代码，还要重新理解整个企业的业务历史。 而且，新系统如果遗漏了某个平时很少使用、但非常重要的特殊流程，可能直到上线几个月以后才暴露问题。 对于普通软件，这也许只是一个Bug，但对于医院、银行和航空系统，可能造成严重后果。 所以很多企业明知道老系统问题很多，仍然选择继续修修补补。 不是因为不知道新技术更好，而是更换系统的风险，可能比继续使用老系统还难以承受。 
AI来了，这件事情第一次出现了新的可能 最近爆红的REA项目，让很多人看到了AI逆向工程的能力。 它可以调用反编译工具，分析没有源代码的软件，并尝试重新实现相应功能。 但这种逆向分析存在不少限制，AI需要根据程序运行行为和编译后的信息，推测软件原来的设计，其中不可避免地存在猜测、模拟和不确定性，即使能够复制主要功能，也很难保证完全理解原程序。 但是现在，我们换一个场景：假设一家软件公司需要改造的是自己的老系统。 而这一家公司本来就拥有完整的源代码，清晰数据库结构，海量的历史业务数据，接口文档，服务器日志和多年的软件修改记录以及实际使用系统的工作人员。 那么情况就完全不同了，AI不必只根据软件的外部表现猜测内部实现，而可以直接研究原始代码和真实业务资料。 虽然几百万行代码不能简单地一次性全部塞进大模型，但AI可以配合专业代码分析工具，把系统拆成不同模块。 分析每一个模块负责什么？哪些函数互相调用？哪些程序读取或者修改数据库？一个业务操作会经过哪些流程？哪些代码已经不再使用？哪些异常规则隐藏在历史程序里？ 然后逐步形成一套完整的软件系统知识地图。 我认为，这可能是AI进入遗留系统改造最重要的第一步。 不是急着生成新代码，而是先让一个已经没人能够完整理解的系统，重新变得可以理解。 
这不是前景展望，IBM和Amazon已经开始做了 实际上，国际大型科技公司已经开始进入这个领域。 例如IBM，它是大型机时代最重要的计算机公司之一，很多银行、保险和政府机构，至今仍然运行着使用COBOL语言开发的老系统。 COBOL是一种诞生于1959年的编程语言，虽然已经六十多年，但大量金融业务仍然依赖它。 问题是，熟悉这些系统的老工程师不断退休，年轻工程师对这种语言的兴趣相对有限。 所以IBM推出了：watsonx Code Assistant for Z，希望利用AI帮助企业理解老代码、分析业务逻辑、生成测试，并逐步改造这些系统。 Amazon也推出了AWS Transform，它能够对COBOL、PL/I等大型机应用进行分析，提取业务逻辑，生成文档，并辅助把部分程序转换成Java等现代技术架构。 注意，这些工具真正有价值的地方，并不只是把COBOL翻译成Java，因为简单转换编程语言，可能只是把几十年的复杂代码换一种语言重新写一遍。 真正重要的是恢复旧系统中的业务知识，重新整理软件结构，让这些系统能够继续发展。 目前这些工具已经进入商业应用，但仍然需要工程师审核、补充业务资料和充分测试。 不能理解成输入几百万行代码，AI就能自动交付一个可以直接替换原系统的完美产品。 
我认为，未来应该让AI重建软件，而不只是翻译代码 假设一套二十年前开发的HIS，采用传统C/S架构，数据库中有大量历史字段，不同医院拥有不同版本，界面和业务逻辑高度耦合。 如果只是让AI把Delphi代码翻译成C#或者Java，能够解决多少问题？ 可能解决部分语言和技术维护问题，但原来的架构缺陷仍然存在，历史冗余仍然存在，各家医院版本不同的问题也没有消失。 所以我更倾向于一种新的思路：不要只是把旧代码翻译成新代码，而是通过AI恢复业务知识，再按照现代软件工程重新设计系统。 例如旧系统有五十个不同的业务模块，AI先分析它们的关系，然后由业务人员和工程师共同决定：哪些模块必须保留？哪些功能已经过时？哪些流程可以合并？哪些历史设计不合理？哪些新需求过去因为修改困难而一直无法实现？最后再设计新的软件架构。 这样一来，AI不是一个简单的代码转换器，而更像一个持续参与工作的：软件考古学家、系统分析师和编程助手。 这里有一个特别重要的原则：旧软件的所有代码，不等于正确的业务需求。 有些旧功能应该保留，有些旧逻辑应该修正，有些历史补丁应该废弃。 而判断这些事情，仍然需要真正理解业务的人。 AI能够帮助我们找出问题，但不能自动决定一家医院今后应该怎样管理患者。 
那么，应该怎样安全地替换老系统？ 这里我特别不赞成一种做法：让AI把所有代码重写一遍，然后选择某一天，把整个旧系统关闭，换成新系统，这太危险了。 软件工程领域其实早就有一种非常成熟的思想叫：Strangler Fig Pattern，中文有时翻译成“绞杀者无花果模式”。 这是软件架构专家Martin Fowler提出的一种渐进式系统替代方法。 它的思想很简单，不一次性拆掉旧房子，而是在旧房子旁边，逐渐建设新房子。 先搬走一部分业务，验证没有问题以后，再搬走另一部分，直到最后，旧系统不再承担任何核心功能然后才真正退出。 AI时代，这种方法仍然非常适用，我认为，可以把整个改造过程分成五个阶段。 第一阶段：读懂旧系统。 利用AI分析源代码、数据库、接口、日志和历史文档，建立可追溯的业务知识库。 第二阶段：重新设计。 由业务专家和工程师共同审核旧规则，制定新的流程、数据标准和系统架构。 第三阶段：逐模块开发。 利用AI辅助生成代码、自动化测试、接口适配和技术文档。 第四阶段：新旧系统并行验证。 让新系统使用隔离的历史数据或经过授权的测试数据，模拟相同业务，比较新旧系统结果。 对于旧系统本身存在的错误，则按照新的业务规则判断，而不是机械复制错误。 第五阶段：逐步切换。 先切换低风险模块，再切换普通业务模块，最后处理高风险核心功能。 每一步都保留数据核对、故障恢复和必要的回退机制。 更重要的是，切换期间必须明确核心业务数据由哪个系统负责写入，不能让新旧系统随意同时修改同一份数据。 这样即使新系统出现问题，也不会把整个企业拖进灾难。 
医院信息系统，可能特别适合走这条道路 我认为，国内医院信息化已经进入一个值得认真考虑遗留系统现代化的阶段。 很多大型医院的HIS、电子病历、手麻系统，已经运行十几年甚至二十多年，经历过无数次升级和定制。 其中一些系统确实存在界面陈旧，数据库结构复杂，不同医院版本不一致，接口不统一，历史代码维护困难以及升级成本越来越高的问题。 但医院又不能轻易停用这些软件，所以，如果能够引入AI辅助系统重建，就很有现实意义。 例如手术麻醉系统，一家软件公司可以先选择术后麻醉质量统计模块。 这个模块通常不直接影响正在进行的麻醉操作，风险相对可控。 首先让AI分析旧系统的源代码和数据库结构，整理出麻醉记录、术后访视、复苏信息及质量指标之间的关系。 然后请麻醉医生重新提出业务需求，比如：按手术专科分析麻醉质量，统计围术期不良事件，分析术后恢复情况，增加AI风险评价，生成临床质量报告。 接着由AI辅助开发一套新的统计分析模块，新模块先不替换旧系统，通过经过授权的数据接口读取历史资料，进行对照测试和试运行。 确认结果可靠后，再逐步投入正式使用。 通过这种方式，不仅能够替换旧功能，还能增加以前因为开发成本太高而迟迟没有实现的新功能。 等经验成熟以后，再继续改造术前评估、术后访视、手术排程等模块。 至于术中麻醉记录、监护数据采集、用药和输血等高风险环节，则应该放在更后面，经过更加严格的验证。 新系统最终可以完全替换旧系统，但不需要在同一天完成替换。 对于HIS也是一样，门诊、住院、收费、药房、检验、病历等模块可以根据相互依赖和风险程度，制定不同的现代化改造路线。 
历史数据库，可能比几百万行代码更加重要 还有一个特别容易忽略的问题：当我们说重新开发软件时，真正需要保护的是什么？ 很多人首先想到源代码，但对于一家运营几十年的企业来说，我认为更重要的可能是：历史数据。 一家医院二十年的电子病历，患者既往诊疗记录，检验检查数据，药品和医嘱记录，手术麻醉信息。 这些数据不仅涉及当前业务，还涉及医疗质量、科研、审计和法律责任。 代码可以重写，历史记录却不能凭空重新生成。 所以AI辅助重建系统，必须重视旧数据库的保护和兼容。 但这里也有一个陷阱，旧数据库本身可能存在大量不合理设计。 例如同一个患者在不同系统里的身份标识不一致，某些字段被重复利用，同一个概念采用多种编码，历史表结构没有完整文档。 因此我们不能简单认为：“旧数据库完全不变，只重写程序就好了。” 更合理的方式是保留可信的原始历史记录，整理数据字典，建立新旧字段映射，让新系统通过标准化接口读取历史数据。 对于必须迁移的数据，进行完整性、一致性与可追溯性校验。 这样既能保留几十年积累的业务资产，又不必让新系统永远被旧数据库结构限制。 
最让我担心的是：AI重写以后，会不会再造一座新的屎山？ 这个问题其实比AI能不能读懂旧代码还重要。 假设AI非常厉害，几个月就帮助企业重建了一套软件，结构漂亮，代码简洁，界面现代化，运行速度也很快。 但如果企业的管理方式没有改变，每个客户继续随意定制，每位工程师继续按照自己的习惯修改，没有统一的数据标准，没有自动化测试，没有严格的版本管理。 几年以后，新的系统仍然可能再次变成屎山，而且AI写代码越来越快，甚至可能让这个过程进一步加速。 因为过去工程师一天只能编写有限的代码，现在一个AI Agent可以在很短时间内生成大量程序，如果缺乏架构约束和质量管理，垃圾代码也可能以更快的速度积累。 所以未来的软件现代化，必须同时改变软件公司的工程管理方式，统一版本，模块化，标准接口，自动测试，持续集成 完善的文档，明确的代码责任。 更重要的是，重要业务规则应当始终与设计、代码和测试用例保持对应。 这样即使二十年以后，所有工程师都已经换了一批，新的人和新的AI仍然能够理解这套系统。 我们需要的不只是一次成功重写，而是建立一种让软件能够持续进化、不再轻易失去可维护性的机制。 
写在最后：我们真正需要继承的，不是几十年的代码，而是几十年的业务经验 过去，企业面对老旧软件，经常只有两个选择：要么继续修修补补，或者冒着巨大风险重新开发。 前者可能越来越昂贵，后者又充满不确定性，所以很多企业不得不继续使用早已过时的系统。 但AI的发展，可能逐渐改变这种局面，尤其当企业拥有完整源代码、历史数据库和实际业务资料的时候，AI就有机会帮助恢复那些已经被遗忘的业务知识。 它可以分析代码，整理依赖关系，寻找隐藏规则，生成文档，辅助重新设计 编写新程序，生成测试，再帮助工程师逐步完成新旧系统替换。 当然，今天的AI还做不到完全自主承担这些工作。 业务判断、软件架构、安全验证和最终责任，仍然需要人类专家。 但即便如此，它已经开始改变软件现代化改造的经济成本和可行性。 我认为，未来这个市场可能非常庞大，因为全世界不仅需要开发新的AI应用，还拥有无数已经运行十年、二十年甚至五十年的老软件。 航空，银行，保险，医院，政府，制造业，能源。 这些系统承载着现代社会大量最重要的业务，它们不能轻易停止，但也不能永远依赖几十年前的技术和逐渐退休的工程师。 所以未来AI在软件行业最有价值的工作之一，可能不是不断开发全新的App，而是把几十年积累在旧软件里的业务知识重新提取出来，让它们进入下一代软件系统。 这让我对软件工程的未来产生了一种新的期待。 过去，一套软件经过二十年的发展，可能成为谁都不敢修改的庞然大物。 但未来，如果AI能够持续理解代码、更新文档、检查依赖和生成测试，那么软件也许不再必然随着年龄增长而变得越来越难以维护。 当然，这仍然需要良好的架构设计和严格的工程制度，AI不会自动消除技术债务，但它可能成为人类管理技术债务的一种非常重要的工具。 回到最开始的问题：AI能不能拯救那些已经没人敢修改的老软件？我的回答是它已经开始具备这种能力。 但真正的目标，不应该只是让老代码继续运行，而是让企业几十年积累的业务知识与历史数据，能够摆脱旧代码的束缚，继续服务未来几十年。 也许有一天，一家医院终于可以告别二十年前开发的HIS，不是因为它被迫放弃历史数据，重新开始，而是因为AI帮助它完整整理了旧系统的业务知识，并让这些知识在一套更加先进、更加可靠的新系统中得到延续。 旧代码可以退出历史舞台，但几十年积累的业务经验，不应该随之消失。 这可能才是AI重建遗留系统最重要的意义。 我们真正需要继承的，不是几十年的代码，而是几十年的业务经验。 
知而后行，行而求知。 从手术室到机房，从临床到系统。记录一名麻醉医生关于医疗AI、医院信息化与持续成长的探索。 —— 医路智行录 主要参考资料 1. 美国交通部：西南航空2022年圣诞节运营中断及处罚 2. 英国民航局：NATS 2023年飞行计划系统故障独立调查 3. IBM Research：利用watsonx Code Assistant理解和改造COBOL遗留系统 4. AWS Transform：大型机遗留系统AI现代化改造 5. Martin Fowler：Strangler Fig渐进式软件系统现代化方法
