很多企业手头都压着一套跑了好几年的Java老系统，Spring Boot + MyBatis，数据库里攒了不少业务数据，接口文档零零散散，领导突然说要“接入AI”。我的建议是：别慌，别想着重写，更别因为这事把一个好好的Java团队逼着去学Python和一堆新框架。低成本改造老系统的核心，不是把技术栈推倒重来，而是利用现有Java生态，把AI能力当成一个外部服务接进来，让老系统“长出新功能”，同时原有业务逻辑照常运转。这篇文章不聊空泛理论，只讲我们在两套真实的传统企业系统上做AI改造时踩过的坑和最终采用的落地方案——从选场景、搭脚手架、接大模型，到把AI结果写回业务库，整个过程摊开了讲，希望能给你一条可以直接抄作业的路线。
1. 整体设计：老系统AI改造的底层逻辑与思路
1.1 先回答一个关键问题：老系统改造到底在改什么
很多团队的误区是，一提到AI改造就想着把系统整个重写，换语言、换架构、上向量数据库，甚至想把跑了几年、几十万行的业务代码全部推倒。我在实际评估过几套老系统后得出的结论是：企业老系统的价值在于“确定”二字——业务流程是确定的、权限模型是确定的、多年积累的业务数据是确定的宝贵资产。AI改造要做的事情，是给这些“确定”的部分加上一层“不确定但聪明”的能力：比如从工单文本里自动提取分类、根据客户历史行为生成推荐话术、对长文档做结构化摘要。说白了，核心业务逻辑不该被AI重写，AI只是帮系统“看见”那些原本难以处理的非结构化信息，再通过业务接口把结果喂回老逻辑。
1.2 为什么Java生态是低成本的第一选择
这里强调的“低成本”，并不单指API调用费用，更重要的是“改造过程本身的成本”。第一，团队不必学习新的语言，也不需要引入一套新的部署体系。Java工程师在国内存量巨大，哪怕临时拉一个外包，写个HTTP调用接口都很熟，这直接就省掉了团队学习和培训的成本。第二，老系统已有的HTTP、JSON、数据库连接池、定时任务、权限体系等基础设施都可以复用。像java面试里反复考的集合、异常处理、线程池这些基础能力，在AI接入时同样够用，不需要额外学什么高阶语法。第三，Java生态里已有大量现成的AI集成资源，无论是直接用Spring框架的RestClient/RestTemplate，还是引入Spring AI或LangChain4j，都是加依赖而不是改架构。我直接说结论：在不考虑极端高并发的情况下，完全没必要为了一个AI功能单独部署一个Python微服务，那样反而把运维链路拉长了。
1.3 改造的核心路径：松耦合 + 渐进式替换
我总结的老系统AI改造路径就八个字：松耦合、渐进式。AI能力不要直接嵌进每个Service里，而是独立封装成一层LlmService或AiProcessor，通过接口对外提供服务。老系统业务侧只在需要的地方调用这一层，其他地方保持不变。这样做的最大好处是可以独立升级AI模型的版本、切换不同供应商、调整提示词策略，都不用动原有业务代码。渐进式替换则意味着不要一期想把所有功能都AI化，哪怕第一个季度只落地一个工单分类场景，也比憋大招半年然后失败强得多。这套思路在我参与的项目里几乎没有被推翻过。
2. 选准第一个场景：AI改造的“最小可行切片”
2.1 从老系统里筛出“高频且可验证”的场景
找一个合适的AI落地场景，是改造成功的第一步，也是最容易被忽略的一步。我的判断标准很简单：这个功能如果原来有人手动做、每天要做很多次、结果还相对客观，那就值得先用AI顶上去。常见的低风险切片包括：客服工单分类和摘要、销售记录中的客户意向识别、合同或文档里的关键字段提取、运维日志分级。我处理过的一个典型老系统，是一套企业内部IT服务台系统，每天几百条工单，分类全靠人肉看一遍再打标签。老系统本身没有机器学习能力，但工单的文本、处理人、时间等字段都在数据库里。我们改造的第一步，就是写一个定时任务，把新增工单文本捞出来，调用大模型API，返回“分类、优先级、是否需要升级”，再自动回写工单表。整个改动没有触碰原业务流程，只是在老系统旁边加了一个“AI处理器”。
2.2 场景确定后的三个配套准备：数据出口、人工兜底、效果口径
一旦场景定下来，先别急着写代码，有三件事必须提前想清楚。第一是数据出口干不干净：工单文本是存在一个字段还是被拆到多个备注字段里，这决定了要不要做文本拼接和清理。第二是人工兜底：AI返回结果后，系统里必须保留“人工确认/修改”的入口，千万不能直接让AI去改数据库里的关键状态。第三是效果口径：比如分类准确率达到多少算成功，这个必须和业务方提前对齐，否则上线后全凭感觉争论。我在实际项目中是把AI输出先放到一张临时表里，由系统根据置信度阈值自动生效或进入人工复核队列。这个设计虽然多写了几十行代码，但上线后业务部门和我们技术团队之间少吵了非常多架。
3. 核心实操：在Java老系统里接入AI能力
3.1 选对接入方式：轻量HTTP客户端对老系统最友好
我在改造中实测过三种方式。第一种直接用JDK自带HttpURLConnection，优点是零额外依赖，但代码繁琐、可读性差；第二种用Spring框架里的RestTemplate/RestClient，这是老Spring项目里最常用的方式，集成成本极低；第三种引入Spring AI框架，优点是封装了对话、提示词模板、函数调用，很现代，但如果老系统还在Spring Boot 2.x，为了引入它去升级框架版本，本身就是不小的工程。我的经验是：老系统停留在Spring Boot 2.x的，优先用RestTemplate或OkHttp，风险几乎为零；如果系统已经是Spring Boot 3.x，可以考虑引入Spring AI，但也要先做版本兼容性验证。下面这段代码是我在一套公开示例风格改造里常用的写法，放在绝大多数老Spring项目里可以直接跑：
@Service public class LlmService { @Value("${llm.api.url}") private String apiUrl; @Value("${llm.api.key}") private String apiKey; private static final RestTemplate restTemplate = new RestTemplate(); public LlmResult chat(String userMessage) { HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); headers.setBearerAuth(apiKey); // 按OpenAI兼容格式组装请求，国内绝大多数模型服务也都兼容这种格式 Map<String, Object> body = new HashMap<>(); body.put("model", "model-name"); body.put("messages", List.of(Map.of("role", "user", "content", userMessage))); body.put("temperature", 0.3); HttpEntity<String> entity = new HttpEntity<>(JsonUtils.toJson(body), headers); ResponseEntity<String> response = restTemplate.postForEntity(apiUrl, entity, String.class); return LlmResult.parse(response.getBody()); } }3.2 老系统配置与参数调优：别把temperature拉满
接入时需要理解两个容易被忽略的参数：temperature和max_tokens。做分类、字段提取这类确定型任务，temperature建议设置在0到0.3之间，太高了AI会“自由发挥”，可能出现全新标签；做文案生成类任务可以放宽到0.7左右。max_tokens是成本控制的关键，很多团队习惯把回复长度上限设成4096，实际上分类任务返回几十个字符就够，调成512能明显降低token消耗。老系统里的配置建议统一放在application.yml中并区分环境，尤其要注意API Key不能硬编码在代码里，更不能提交进Git仓库，这个坑我在早期项目里踩过不止两次，一旦key泄露，损失的不只是费用，还可能影响业务数据安全。
3.3 结果回写老业务库的两种模式：直接回写与置信度回调
AI结果要进老系统，最简单的做法是在原表旁边加几个扩展字段，比如ai_category、ai_priority、ai_status，把API返回内容解析后直接UPDATE。使用MyBatis-Plus的老项目尤其方便，在实体类上直接加字段，再调updateById就能回写，连自定义SQL都不用写。但更稳妥的是“置信度回调”模式：要求大模型返回JSON时同时输出confidence字段，系统只对confidence大于0.8的结果自动生效，其余进入人工确认列表。我们当时把阈值定在0.85，每天几百条工单里需要人工复核的大概只有几条，业务方看着这个比例也很放心。这里给个提醒：大模型返回的confidence不是真正的概率，它只是一个“自我估计”，所以阈值要根据实际数据做小样本调参，别照抄网上经验值。
3.4 进阶：让老系统支持“函数调用”式的高级交互
如果想让AI能直接查询老系统里的订单接口，或者主动触发某个动作，就得用“函数调用/工具调用”。原理其实很朴素：你告诉大模型“系统里有哪些函数、分别需要哪些参数”，模型根据用户问题决定要不要调用某个函数以及传入什么参数。Java侧只需要实现一个通用dispatcher，把模型返回的函数名和参数映射到对应的Service方法。这里有个容易翻车的地方：函数调用的参数校验必须放在Java侧做，因为大模型给出的参数经常出现“自创枚举值”，比如客户类型传了一个“重要用户”，但数据库里根本没有这个值，直接反射调用或者拼SQL就会报错。我们后来在dispatcher里加了一个参数白名单校验，宁可拒绝调用也不能盲目执行。
4. 进阶：低成本给老系统加上企业知识库
4.1 老系统里散落的知识资产要怎么处理
业务系统跑久了，里面积累的FAQ、操作手册、客户备注、历史工单，这些非结构化数据就是建设企业知识库的最佳素材。RAG的基本思路是：先把文档切成小段，用向量模型转成向量存起来；用户提问时，把问题也转成向量，去库里找最接近的几段，连同问题一起发给大模型，让它基于这些片段回答。老系统改造时不需要自己实现向量算法，只需要选一个轻量级的向量化方式和向量存储。有些团队一上来就引入Elasticsearch的向量模块或者独立部署一个Milvus，如果数据量只有几十万条，这明显过度设计。用关系型数据库加一个向量字段，或者引入一个简单的向量搜索库，成本要低一个数量级。
4.2 用Java实现一个最小RAG链路的踩坑记录
我给一个低成本可验证的思路：文档切分可以先用字符数粗切，每段500字符、重叠50字符，后面再按效果调优；向量化可以直接调用大模型服务商提供的embedding接口；向量存储方面，如果项目已经用了MySQL，可以先用一个float数组字段或者字符串存储向量，再用工具类计算向量相似度。我们当时是先用Hutool的HttpUtil调用embedding接口，把向量转成float数组存进内存List里做离线验证，等确认效果后再决定是否引入Redis存储。整个验证阶段没有引入任何新的中间件，成本几乎为零。下面是我在验证阶段经常写的一段代码，实际项目里可以换成你们项目已经统一的HTTP客户端：
public List<Float> embed(String text) { String body = HttpRequest.post(embeddingUrl) .header("Authorization", "Bearer " + apiKey) .body(JsonUtil.toJson(Map.of( "model", "embed-model", "input", text ))) .execute().body(); JSONObject data = JsonUtil.parseObj(body); return data.getJSONObject("data") .getJSONArray("embedding") .toList(Float.class); }4.3 embedding模型选型与切分策略的实战经验
embedding模型的选择会直接影响检索质量。我测过几个主流服务商的通用模型，中文场景差异并没有宣传的那么大，真正影响效果的是“切分方式”。比如把整段工单原文压成几个长片段，检索到的片段常常会在关键数字或结论处被切断，导致问答不准。后来我们改成按句子切分，并保留段落标题作为前后缀，效果立刻好了不少。另外，向量化后的存储格式要统一，Java侧用float数组计算余弦相似度时，要注意范数是否为0，空向量经常出现在纯符号文本上，不处理会直接报除以零的错误。
5. 成本控制与老系统性能的平衡
5.1 token成本怎么算，以及三个立竿见影的省钱手段
既然讲低成本，就必须把API费用聊透。一个简易估算方式：1个汉字在多数模型里约等于1.5到2个token。省钱有三招，都很实操。第一招，把max_tokens压到任务需要的合理范围，比如分类任务设256就够；第二招，精简系统提示词，把客套话和冗余背景信息拿掉；我们自己的提示词从最初300字压缩到120字，效果没降，token直接省了一半；第三招，做结果缓存：同一个客户ID、同一周的摘要请求，如果没有新数据就直接用库里的缓存结果，这个在老系统里用一张redis或普通表就能做，效果立竿见影。还有一点别忽略：回复内容里的固定头部和格式模板也会消耗token，可以在解析后只保存有效内容，减少下次输入拼接体积。
5.2 老系统并发低，不能因为AI把接口拖垮
老系统普遍没有为长耗时接口做准备。大模型API的响应时间通常在1到5秒，如果直接在用户请求线程里同步调用，用户侧会感觉明显卡顿，数据库连接池也可能被占满，进而拖垮整个系统。改造时的铁律是：所有AI调用一律异步化。做法很简单，用Spring的@Async或者MQ把AI任务丢到后台，接口立即返回“处理中”，AI完成后通过WebSocket或轮询把结果推给前端。如果不想引入MQ，用@Async加任务表轮询就能撑住绝大多数场景。我见过一个项目忘了这条，在秒级超时的网关后面直接同步调大模型，结果线上反馈“系统变慢”，最后定位到是连接池被AI请求拖死了。
5.3 灰度发布与回滚预案：AI功能必须能一键关闭
企业老系统改造最怕上线后出问题却没法快速恢复。我给团队定过三条规则，今天也分享出来。第一，AI功能全部走独立配置开关，放在配置中心或application.yml里的llm.enabled字段，关闭后立即回退到原人工流程；第二，AI的写操作不直接触碰原表，统一经过一个可观测的服务层，操作日志全记录；第三，灰度按用户分组进行，一开始只对内部测试组开放，跑两周没问题再逐步放量。这些听起来像老生常谈，但我亲眼见过不少团队上线AI时连开关都没留，一有问题就得改代码重新发布，一个不必要的高成本事件。
6. 常见问题与排查技巧实录
6.1 大模型接口返回延时越来越高
排查时先看是不是网络层没做超时配置。RestTemplate默认的超时可能很长，一旦上游服务出现抖动，老系统里的请求就会跟着大量阻塞。建议统一设置connectTimeout和readTimeout，connect设5秒，read设60秒基本够用。还要看是不是API Key有并发限制，很多服务商默认限制每分钟请求数，如果定时任务一次性捞了一万条工单并发请求，会被限流，甚至触发封禁。我们当时的对策是加一个信号量做限速令牌，每秒钟最多放5个请求出去，整个运行期都很稳。
6.2 AI返回JSON经常解析失败
大模型虽然被要求返回JSON，但偶尔会夹带解释文字，或者把中文引号换成全角，甚至自动加一个markdown代码块。解决思路不是反复调模型，而是Java侧做容错：提取内容里第一个“{”到最后一个“}”再解析；同时在提示词里明确要求“只输出JSON对象，不要markdown，不要解释”。我自己的工具类里专门写了一个stripJson方法，把常见非法字符按规则剔除，实测解析成功率能到99.5%以上。这里提醒一句：不要指望正则一次到位，模型输出格式会换着花样给你惊喜，建议用三层降级：先直接解析，失败就清洗后再解析，再失败就返回一个默认的“处理失败”结果并告警。
6.3 老系统JDK版本太低能不能接AI
Java 8仍然是很多老系统的主力，好消息是，调用大模型API本质上就是发HTTP请求，Java 8自带的HttpURLConnection也能干，只是代码比较丑。如果选第三方HTTP类库，注意选兼容Java 8的版本，比如OkHttp 3.x、Hutool、RestTemplate都没问题。Spring Boot 2.x本身就是基于Java 8的，所以完全不用为了接AI去升级JDK。我自己就在一个Java 8的系统上完整跑通了AI接入，核心依赖只加了Hutool和fastjson或Jackson，老系统也能玩得很顺畅。
6.4 业务方觉得AI“不够专业”怎么办
这其实不是技术问题，而是预期和反馈闭环的问题。我的经验是：在AI处理结果展示区域加上“AI处理”的标识，同时支持人工修改并记录修改原因；积累两周后，把人工修改比例高的场景拿出来，重新优化提示词或补充知识库内容，形成一个持续改进的闭环。让业务方看到AI和人在协作、AI确实减少了重复劳动，比任何汇报文档都管用。你甚至可以做一个简单的“AI节省工时”统计看板，把每天自动分类成功的工单数量换算成人工时间，这个数字对向上汇报非常有效。
如果让我总结这次Java老系统AI改造最值得记住的一点，那就是“别把AI当神仙，也别把改造当推倒重来的大工程”。我见过太多项目死在“想一步到位建一个完美的AI中台”上，结果半年过去连第一个场景都没上线。反过来，用最小的切片、最平实的技术、老团队原本就熟悉的代码方式，先让一个工单分类功能跑起来，再顺着业务反馈慢慢扩展RAG、函数调用这些能力，反而走得又快又稳。改造老系统不是给老车换发动机，更像给一台准点跑了十年的车配一套聪明的导航——发动机不动，轮子照转，但从此再也不怕走错路了。
