*“2024年初，某银行花费了1800万美元，用AI’重写’了他们的核心交易系统。9个月后，新系统上线，性能提升了40%，但业务逻辑错误率上升了300%。问题不在于AI，而在于他们试图用AI解决一个根本不是技术的问题。” *

一、那个价值1800万美元的教训

让我们从一个真实的故事开始。

2019年，某大型保险公司启动了一个雄心勃勃的项目：用AI辅助重写他们的核心保单系统。这个系统有40年历史，超过2000万行COBOL代码，承载着公司80%的业务。

项目团队信心满满。他们使用了最先进的AI代码转换工具，可以将COBOL自动转换为Java。AI还能”理解”业务逻辑，生成相应的单元测试。

18个月后，项目”成功”交付。所有COBOL代码都被转换成了Java，测试覆盖率达到了85%，性能提升了3倍。

但上线第一周，灾难发生了。

  • 某类特殊保单的折扣计算逻辑被错误转换，导致公司多赔付了1200万美元
  • 与第三方系统的集成接口发生了微妙的改变，影响了200+下游系统
  • 某个只在闰年触发的边界条件被遗漏，导致2月29日的所有批处理失败

事后调查发现，问题不在于AI的能力，而在于一个根本性的误解：遗留系统的复杂性不在代码里，而在代码周围的”隐性知识”里。

二、核心观点：遗留系统的三层债务

让我说一个反直觉的事实：遗留系统的问题不是技术问题，是知识问题。

传统的遗留系统现代化思路假设：

  • 遗留系统的复杂性在代码里
  • 只要把代码重写/重构，问题就解决了
  • AI可以帮助我们更快地重写代码

但这个假设忽略了一个关键事实：遗留系统的真正成本不是技术债务，是认知债务。

我提出一个三层债务模型：

债务类型 描述 AI能解决？ 占比
技术债务 过时的技术栈、糟糕的代码结构 ✅ 可以 20%
认知债务 业务逻辑的历史沉淀、 tribal knowledge ❌ 不能 60%
契约债务 与外部系统的隐性契约、边界条件 ❌ 不能 20%

技术债务是显性的：代码耦合、缺乏测试、过时的框架。AI确实可以帮助解决这部分。

认知债务是隐性的：为什么这个字段要这样计算？这个看似奇怪的逻辑是为了解决什么历史问题？这些知识存在于退休老员工的头脑里，存在于已经丢失的文档里，存在于”我们一直是这样做的”的习惯里。

契约债务是最危险的：系统与外部世界形成的各种隐性契约。某个API的行为可能在文档中没有明确说明，但下游系统依赖它。某个批处理的时间窗口看似任意，但它是与第三方系统协调的结果。

关键洞察：AI可以处理技术债务，但认知债务和契约债务需要人类的领域知识和社会工程学。而这两类债务占遗留系统复杂性的80%。

三、穿越周期：从巴别塔到丝绸之路

让我们看看人类如何处理”遗留系统”。

公元前3000年，苏美尔文明：当新的统治者征服一个城市，他们面临一个选择：是摧毁原有的行政系统，还是继承它？大多数明智的统治者选择继承——因为摧毁系统意味着失去记录税收、管理灌溉、维持秩序的能力。

罗马帝国扩张：罗马人没有强迫被征服地区采用罗马的行政系统，而是建立了一个”分层架构”——核心使用罗马法，地方保留传统习俗。这种”渐进式现代化”让帝国维持了数百年。

工业革命：当工厂主引进新机器时，他们没有立即解雇所有工匠。相反，他们让老工匠和新技术共存了数十年，逐渐转移知识。

1980年代，Y2K危机：全球企业面临一个选择——重写所有系统，还是打补丁？大多数选择了打补丁。不是因为重写不可能，而是因为重写意味着重新验证所有业务逻辑，成本是无法承受的。

时代 遗留系统 现代化策略 结果
古代 行政体系 渐进继承 文明延续
罗马 地方法律 分层架构 帝国稳定
工业革命 工匠技艺 人机共存 平滑过渡
Y2K 日期系统 打补丁 成功过渡
AI时代 软件系统 ??? ???

历史在押韵：每一次”遗留系统”危机，最危险的策略都是”彻底重写”。最安全的策略都是”渐进式演进”。

四、反直觉洞察：AI现代化的三个陷阱

陷阱一：过度自信陷阱

误区：”AI可以理解代码，所以它可以帮我们重写”

现实：AI可以理解代码的”语法”，但很难理解代码的”语义”——尤其是那些没有被显式表达的业务逻辑。

案例：

IF CUSTOMER-TYPE = "VIP" AND REGION-CODE = "NE"
    COMPUTE DISCOUNT = BASE-PRICE * 0.15
ELSE
    COMPUTE DISCOUNT = BASE-PRICE * 0.10

AI可以完美地将其转换为Java。但它不知道的是：

  • 为什么VIP客户只在东北地区有额外折扣？（历史原因：东北地区曾是竞争最激烈的市场）
  • 这个折扣率是否与某些合同条款冲突？
  • 下游系统是否依赖这个特定的折扣计算顺序？

陷阱二：冰山陷阱

误区：”我们看到的代码就是全部”

现实：遗留系统像冰山，代码只是水面上的部分。水面下还有：

  • 与外部系统的集成（可能包括已经倒闭的公司的系统）
  • 定时任务、批处理、报表生成的复杂时序依赖
  • 数据迁移的历史路径（字段A的值实际上来自字段B的历史值）

AI能看到代码，但看不到这些隐性依赖。

陷阱三：完美复刻陷阱

误区：”我们要完全复刻原有系统的行为”

现实：遗留系统的行为本身可能就是bug。有些”特性”实际上是历史错误，但因为被依赖而变成了”功能”。

如果你用AI完美复刻了这些行为，你只是在复制债务。

五、实战：遗留系统的AI-Native现代化策略

策略一：绞杀者模式（Strangler Fig Pattern）

不是重写，而是逐步替换。

步骤：

  1. 在新系统中实现新功能
  2. 在遗留系统和新系统之间建立适配层
  3. 逐步将遗留系统的功能”绞杀”（迁移到新系统）
  4. 最终遗留系统只剩下一个空壳，可以安全退役

AI的角色：

  • 帮助构建适配层
  • 生成数据迁移脚本
  • 辅助编写新系统的代码
  • 但不是：重写遗留系统

策略二：知识萃取优先

在开始任何技术工作之前，先解决认知债务。

知识萃取四步法：

  1. 访谈：与系统维护者深度访谈，记录tribal knowledge
  2. 逆向工程：通过代码分析反推业务规则
  3. 契约映射：识别所有外部集成点和隐性契约
  4. 边界条件收集：整理所有特殊场景、历史特例

AI的角色：

  • 辅助分析代码，提取潜在的业务规则
  • 帮助整理访谈记录，识别遗漏点
  • 生成知识文档的初稿

策略三：双轨运行

新旧系统并行运行，逐步验证。

阶段：

  1. 影子模式：新系统接收相同输入，但不影响生产，对比输出
  2. 金丝雀发布：新系统处理1%流量，监控差异
  3. 渐进切换：逐步增加新系统的流量比例
  4. 完全切换：遗留系统退役

AI的角色：

  • 生成对比测试用例
  • 自动检测输出差异
  • 辅助根因分析

现代化评估矩阵

评估维度 重写 绞杀者模式 封装
风险 极高 中 低
成本 高 中 低
时间 长 中 短
技术债务解决 彻底 渐进 不解决
认知债务解决 否 是 否
AI适用性 低 高 中

六、写在最后

遗留系统不是技术债务的监狱，是组织知识的宝库。

每一个看似混乱的代码片段，可能都承载着 years of business knowledge。每一个奇怪的业务规则，可能都是某个历史事件的产物。AI可以帮助我们更快地理解这些代码，但不能替代我们理解这些知识。

优雅的技术组织不是拥有最新技术栈的组织，而是最懂得与遗留系统共处的组织。

向死而生，不是悲观，是清醒。承认遗留系统的复杂性，然后选择最安全的现代化路径。

这就是AI-Native软件工程的智慧。

延伸阅读

经典案例

  • Y2K危机：历史上最大规模的遗留系统现代化
  • Netflix的绞杀者模式实践
  • AWS的渐进式架构演进

技术实现

  • Strangler Fig Pattern: Martin Fowler的经典模式
  • Domain-Driven Design: 理解业务复杂性的方法
  • Event Sourcing: 处理遗留数据的新思路

学术与理论

  • 《Working Effectively with Legacy Code》: 遗留代码处理圣经
  • 《Building Evolutionary Architectures》: 演进式架构
  • 《Software Architecture: The Hard Parts》: 架构决策的复杂性

Published on 2026-03-09 深度阅读时间：约 13 分钟

AI-Native软件工程系列 #18 —— 探索AI时代的软件工程范式转移