一篇刊登于AI News的实操文章提出，AI应作为新增层而非新地基；用API中间层、RAG、事件驱动和Strangler Fig四种模式把模型与核心系统隔开，并建议先从搜索、摘要、报表等只读场景起步。
AI解读：这篇文章最值得注意的不是技术名词，而是它对改写范围的判断：AI通常可以坐在现有软件之上，不需要替换核心模块。对已经跑了十几年的业务系统来说，推倒重来意味着在旧系统继续支撑业务的同时，让团队重新发现那些没人完整记录的规则、边缘情况和合规逻辑，这类大型替换项目常常超支、延期，有些根本做不完。
文章给出的落地方式是把AI当新增层：既然成熟系统经过多年真实使用检验，数据和流程相对可靠，模型就能建在这上面。文中引用的开发公司SumatoSoft也把自己的做法描述为在客户既有系统之上加智能层，而不是拆掉原有部分。
具体集成有四种模式：API与中间层只暴露定义明确的操作，避免模型直接查生产库或改表；RAG用独立管线把文档索引进向量库，让模型基于已有资料回答并给出引用来源；事件驱动与变更数据捕获让AI订阅数据库的增删改，近实时识别可疑交易或预测延迟；Strangler Fig通过门面逐块替换或增强功能，避免一次性切换。
开始前要核对几个现实问题：系统能否通过API暴露数据，还是需要新建集成层；数据是否足够干净一致；AI会触碰的流程归谁负责，以及适用哪些安全合规要求。常见错误是过早给AI太多权限，正确顺序是先用只读场景建立信任，写操作和敏感动作之后再加上人工审批。
文章还提醒把持续成本算进去：商用语言模型API通常按token计费，监控、评估和再训练在发布后仍要持续投入。把AI层当一次性项目的团队，往往会随着数据和业务条件变化看着它慢慢退化——说白了，这东西不是装修完就完事，更像是请了个需要持续发工资、还要定期体检的新同事。
一篇刊登于AI News的文章提出，多数运行遗留软件的公司默认加AI就得推倒重来，这个假设在项目启动前就拦住了很多事。文章称，重写一套支撑业务 15 年的系统代价高、风险大，而且很少真有必要；多数情况下AI可以坐在现有软件之上，不替换任何核心模块。
文章的核心主张是把AI当作新增的一层，而不是新的地基。它把有经验的AI开发者比作谨慎的翻新者：保留还能用的结构，升级周边部分。
文章给出的理由是，遗留系统里往往沉淀了数十年的业务规则、边缘情况和监管逻辑，且没有完整文档。全面重写会迫使团队在旧系统继续支撑业务的同时把这些内容重新发现一遍；大型替换项目以超支和延期著称，有些根本完不成。
文章还给出一个更简单的理由：AI最适合建立在可靠数据和稳定流程之上，而一个经过多年真实使用检验的成熟系统正好提供这样的基础。文章提到，SumatoSoft等开发公司现在把AI定位为既有软件的延伸而非替代，该公司称自己的做法是在客户长期积累的系统之上加一层智能，而不拆掉已经能用的部分。
文章强调，给AI增加能力最安全的方式是让它与核心保持距离。下面四种集成模式各有侧重，很多项目会组合使用多种。
API与中间层、RAG、事件驱动、Strangler Fig四种集成模式
第一种是API与中间层。文章建议不要让AI模型直接查询生产数据库，而是由开发者构建一个中间层，只暴露特定且定义明确的操作。AI可以请求某条客户记录或起草订单，但不能执行任意查询或修改表。文章称，这能保护遗留系统免于意外负载、畸形请求，以及提示注入攻击——即恶意输入诱骗模型去做本不该做的事。
第二种是在既有数据上做检索增强生成，即RAG。文章解释，RAG让语言模型用企业自己的文档和记录来回答问题。遗留系统照旧存储数据，另一条独立管线把相关内容索引进向量数据库，用户由此获得对多年信息的对话式访问。文章补充，做得好的RAG系统还能为每个答案标注来源，让结果更容易核实。
第三种是事件驱动集成。文章称，许多老系统可以发出事件，或通过变更数据捕获来监控——这是一种追踪数据库插入、更新和删除的技术。AI服务可以订阅这些变化，近实时地做出反应，标记可疑交易或预测延迟，而不会给遗留应用本身增加负载。
第四种是Strangler Fig模式，得名于软件工程师Martin Fowler，取的是一种藤蔓逐渐缠绕寄主树的意象。文章介绍，这种模式逐块替换或增强功能：新的AI功能经过一个门面路由，其余部分继续跑在老系统上。随着时间推移，重心可以慢慢转移，不需要任何一次冒险的整体切换。
- API与中间层：只暴露定义明确的操作，AI不能跑任意查询或改表
- RAG：遗留系统照旧存数据，独立管线建向量索引，用户获得对话式访问，答案可标注来源
- 事件驱动：用事件或变更数据捕获追踪数据库增删改，AI近实时响应，不给遗留应用加负载
- Strangler Fig：新AI功能走门面，其余继续跑旧系统，逐块迁移而非一次性切换
动手前的核对清单与两个常见错误
文章建议在开发开始前先回答几个关于环境的实际问题：系统能否通过API暴露数据，还是需要新建集成层；数据是否干净、一致到足以让模型检索或学习；AI将触碰的流程由谁负责，以及适用哪些安全与合规要求。文章称，明确的答案会决定架构，并避免项目中途出现昂贵的意外。
文章点出最常见的错误是过早给AI太多权限。它建议从只读用例起步，例如搜索、摘要或报表，先建立信任并衡量准确率，之后再让模型做修改。写权限应当更晚才开放，敏感操作还要加上人工审批步骤。
另一个错误是忽视持续成本。文章称，商用语言模型API通常按token计费，监控、评估和再训练在发布后很久仍需要持续投入。把AI层当成一次性项目的团队，往往会在数据和业务条件变化时，看着它悄悄退化。文章建议从第一天起就为运营做预算，以保持系统可靠。
文章在结尾称，遗留软件常被当成负担，但它通常握着一家公司最有价值的知识。在它之上加AI，能把累积的数据和逻辑变成竞争优势，而不是迁移的麻烦。文章的建议是：从一个窄用例开始，让真实结果决定这层智能应该长到多大。
- 核对项：能否通过API暴露数据；数据是否干净一致；流程归属；安全与合规要求
- 先上只读场景（搜索、摘要、报表），写操作后置并配人工审批
- 商用模型API通常按token计费，监控、评估、再训练需持续投入
- 从一个窄用例起步，由实际结果决定智能层的扩展范围