老系统加AI，改造还是重做？先算清三笔账

“给我们ERP加个AI吧”——这句话在需求会上出现的频率越来越高。真往下聊，发现老板想要的是“查数据不用点八层菜单”，业务部门想要的是“自动生成周报”，IT负责人担心的是“老系统没接口，别动出问题”。三个诉求，对应三种完全不同的改造方式。

先找读多写少的场景

老系统里最适合先加AI的，是那些员工反复查、反复抄、反复写的环节。

查：制度、合同、历史工单、产品参数，散在文档和系统里，找一次要问三个人。

抄：把A系统的数据填到B系统的表单里，每天重复几十遍。

写：周报、月报、会议纪要、客户回复，格式固定，内容靠人拼。

这三类场景的共同点是读多写少，AI 出错的影响可控，人还能复核。反过来，直接让AI改库存、下采购单、审批付款，风险太高，不适合作为第一个项目。

外挂：不动老系统，单独做一个入口，通过数据库只读账号或导出文件拿数据，AI 在外部完成查询和生成。适合老系统没有接口、但数据结构相对清楚的情况。

嵌入：在老系统的页面里加一个侧边栏或按钮，调用AI服务。需要老系统支持前端扩展或至少能加一个链接。体验最顺，改造量中等。

重建：把某个模块单独重做，用新架构接AI能力，老系统继续跑其他模块。适合老模块已经严重过时、维护成本高于重写的情况。

大部分项目从外挂开始，验证有效后再考虑嵌入。一上来就重建，周期和风险都不可控。

AI 能不能答对，取决于数据质量；能不能给员工用，取决于权限设计。

数据散在Excel、邮件、共享盘、老系统里，格式不统一，字段没人维护。做知识库之前，先得把文档收拢、去重、打标签。这部分工作量经常被低估，能占到项目的一半。

权限更麻烦。销售只能看自己的客户，HR只能看自己的模块，财务数据不能出内网。AI 的检索必须继承这些权限，不能因为接了一个大模型，就把所有数据放进同一个向量库。

私有化还是走API，要看数据敏感度。客户名单、合同条款、财务数据，通常不适合直接发给公有云模型。混合方案是常见做法：敏感数据本地检索，脱敏后再调用外部模型。成本怎么算，可以看大模型成本计算器或AI推理成本。

三种情况可以考虑重做：老系统的技术栈已经停止维护，找不到开发人员；系统没有数据库文档，也没有任何接口，外挂都接不上；业务流程已经变了，老系统只能靠打补丁维持。

重做不是把老系统翻译一遍，而是借机会梳理流程。哪些字段没人用，哪些审批是多余的，哪些报表可以合并。不梳理就重做，等于把旧问题搬进新系统。

如果只是界面老、操作繁琐，但数据和流程都还清楚，改造通常比重做划算。

第一期只做一个场景，选一个部门、一个高频动作，两到四周上线。验收标准不是“AI回答得像不像人”，而是“这个动作的耗时有没有下降”。

第二期扩到相邻场景，比如从查制度扩到查合同，从生成周报扩到生成月报。每期独立报价、独立验收，效果不好可以停。

第三期才考虑嵌入主系统、接更多数据源。这时候团队已经知道AI能做什么、不能做什么，需求会更现实。

以2026年市场行情为参考，单场景改造通常几千到一万多，多场景按阶段叠加。费用主要花在数据整理、接口对接和权限设计上，模型调用费占比不高。

如果老系统是 ERP、MES 这类核心系统，改造前要先确认厂商是否支持扩展。有些厂商锁了数据库和接口，第三方很难接。选型阶段的问题可以看MES和ERP的区别，这里不展开。

先问这个场景出错一次代价多大；再问数据能不能拿到、权限能不能控；最后问员工愿不愿意用。三个答案都过得去，再谈技术方案。

改造的目标不是让系统显得智能，是让某个人每天少花半小时。这个目标越具体，项目越容易成。服务范围见老项目AI改造，如果涉及多个系统的数据打通，需要系统集成一起做；知识型问答的基础建设可以看AI知识库。

描述你的需求，我们将结合本文涉及的场景给出针对性评估建议。