3 篇博文 含有标签「legacy-systems」

二十五年以来，“绝不从零开始重写”一直是软件工程界最接近诫律的一条原则。这一公认论点背后的成本结构曾被所有人视为理所当然：重写意味着重新阅读、重新理解并重新编写多年积累的代码；而当你忙于这些时，旧系统仍在运行，竞争对手仍在不断交付。重写之所以被禁止，是因为它太慢了。

编程智能体刚刚消除了这个“慢”的部分。一个智能体可以在几天之内——而不是几个季度——将一个拥有十万行代码的代码库从一种语言或框架翻译成另一种。研究大型机现代化的团队发现，主要由于 AI 辅助转换，平均程序成本从 2024 年的 910 万美元下降到了 2025 年的 720 万美元，咨询机构目前报告称现代化进度加速了 40–50%。那么，这条诫律失效了，对吗？如果重写中最昂贵的部分变便宜了，那么重写又重新回到了选项中。

问题在于：编写代码从来都不是最昂贵的部分，它只是最显眼的部分。在大规模迁移中失败的组织，很少是因为代码难以转换。他们的失败源于代码之外的一切——未记录的行为、数据迁移、集成切换，以及那些没人想到要写下来的运维肌肉记忆。智能体让重写的开始变得廉价，但对于让重写安全完成的那些因素，它们几乎没有提供帮助。

大多数 AI 编码演示展示的是智能体从零构建一个 Todo 应用，或者干净地实现一个全新的 API。而你的代码库，却是一个有着十五年历史的单体应用：充满未文档化的隐性契约、三个团队都依赖但没人完全搞清楚的废弃依赖，以及一个从单一类起步、如今已蔓延到四十个文件的服务层。演示与现实之间的差距，不仅仅是规模问题——更是结构性问题。在把代码库的"钥匙"交给智能体之前，理解这一点，能让你避开一类既隐蔽又代价高昂的失败。

AI 编码智能体确实能帮助处理遗留系统，但只在特定任务边界内才有效。超出这些边界，它们不是显眼地失败——而是生成外观可信、语法正确、语义却有误的变更，这些变更能通过代码审查，最终在生产环境中暴露出来。

每个 AI 演示都从绿地起步：一个干净的代码仓库、一个全新的 API key，不到一小时就能跑通流式聊天响应。然后有人问："我们能把这个加到真正的产品里吗？"——那个运行在十年老单体系统上、存有无数未记录存储过程的产品，那个部署流程需要三个团队外加一个变更顾问委员会的产品，那个数据模型比 JSON 还古老的产品。

大多数 AI 集成工作都死在这里。不是因为 LLM 不好用，而是因为周围的系统根本不肯配合。超过 75% 的企业 AI 项目都卡在集成边界上——无法将 AI 能力与真正持有所需数据的系统连接起来。

本能反应是计划重写。别这样做。那些真正将 LLM 功能推进生产遗留系统的团队，都是以渐进的方式完成的——通过将现有代码库视为具有已知接口的黑盒的适配器模式。以下是具体做法。