获课地址：789it.top/17385/

开篇：我为什么从一个“AI怀疑者”变成了“AI拥抱者”
说实话，一年前我对大模型的态度是：热闹是他们的，我什么也没有。

我当时觉得，这东西跟我每天写的Java代码、调的数据库、做的接口，关系不大。那些用Python调模型的，是另一个工种的人。直到有一次，我们团队接了一个需求——给一个用了八年的工单系统加上智能辅助功能。

客户的要求很明确：不动现有代码，不换数据库，不要复杂的训练，两个月上线。我当时的第一反应是：这不可能。但后来我们做到了，用的就是 SpringAI + RAG + Milvus。

做完那个项目之后，我对“传统应用升级”这件事的理解彻底变了。这不是一个技术概念，而是一个正在发生的、巨大的、属于我们这些普通后端程序员的红利窗口。

这篇文章，我想把这次经历中的真实体感和思考沉淀下来。不讲虚的，只讲一个干了十几年后端的人，怎么看待这轮技术红利。

第一章、为什么说“传统应用升级”是一波确定性的红利
1. 绝大多数软件都是“传统应用”，这才是真相
打开任何一个技术大会的议程，满眼都是AI原生应用、大模型时代的新范式。但这些演讲忽略了一个基本事实：全世界正在生产环境里运行的应用，90%以上都是“传统应用”。

这些应用的特征很统一：Spring Boot或SSM框架、MySQL或Oracle数据库、Redis缓存、微服务或SOA架构，运行在物理机或云服务器上。它们不性感，但它们支撑着银行的转账、物流的派单、医院的挂号、学校的选课、工厂的进销存。

这些系统有一个共同的困境：它们很“重”，改造成本极高；但它们又必须“变”，因为用户习惯已经被ChatGPT们重塑了。现在的人，不管用你的什么系统，都希望它能“聪明一点”。

2. 企业想要的不是推倒重来，而是“加装电梯”
我接触过的所有客户，没有一个说“我们把现有系统废了，用AI重写一套”。没有。

他们说的是：

“能不能在现有的合同审批流程里，加一个AI预审？”

“能不能让我们内部的FAQ系统，变成一个能对话的机器人？”

“能不能让客服在回复工单的时候，AI自动推荐几条回复模板？”

这些需求的核心特征是：底层业务逻辑不要动，数据库结构不要改，只是在流程的关键节点上，插入AI能力。 这种行为，我给起了个名字叫“加装电梯”——老房子的承重结构不变，只是多了垂直交通的能力。

传统应用升级的市场，就是给成千上万的“老房子”加装AI这个“电梯”。这工程量远远小于推倒重建，价值又远远大于不升级。供需两旺，红利天然存在。

3. 技术成熟度刚刚好：不太早，也不太晚
为什么是这个时间点？因为三个关键技术都已经到了“工程可用”的临界点：

大模型调用成本：一年前调用一次的费用是现在的十几倍，而且可用性差。现在已经降到可以规模化使用的水平了。

向量数据库成熟度：Milvus这类产品，已经从实验室走向了生产环境，有集群方案、有监控、有备份恢复。

Java生态集成：SpringAI的出现，让Java程序员不用切换技术栈就能接入AI能力。

这个时间点非常微妙：太早，工具不成熟，踩坑成本高；太晚，红利被瓜分完，竞争激烈。现在就是那个“黄金窗口”。

第二章、SpringAI：为什么它是传统Java应用的“最佳AI入口”
1. 不换赛道，只加技能
作为一个Java后端，我最大的资产不是什么高深的技术，而是对Spring生态的熟悉程度。Spring的IOC、AOP、事务管理、RestTemplate……这些概念我闭着眼睛都能说清楚。

SpringAI最让我舒服的一点是：它没有让我重新学一套新的编程范式。

使用SpringAI的感觉，跟当年从Spring Boot 1.x升级到2.x差不多——增加了一些新注解、新配置、新的Template类，但底层的思维模式完全一致。依赖注入、面向接口、配置分离……这些东西还是原来那套。

这意味着什么？意味着我和我的团队，不需要招AI specialist，不需要学Python，不需要换IDE。直接在现有能力的基础上“生长”出新能力。

2. 抽象层给的是自由，不是绑定
现在的AI模型生态是一个“战国时代”。OpenAI领先，但阿里通义千问、智谱、文心一言都在快速追赶。企业客户最怕的一个词叫“供应商锁定”。

如果直接在代码里调用OpenAI的SDK，哪天客户说“我们用通义千问，因为数据合规要求”——你就等着改代码吧，不是一个简单的配置能解决的。

SpringAI在底层做了一层抽象：ChatModel、EmbeddingModel、VectorStore……这些接口定义好了，底下具体是哪个模型，由配置文件决定。切换模型的时候，只要换依赖和配置参数，业务代码一行不改。

这种设计，做过企业级软件的人都知道有多重要。客户不喜欢被绑架，好的架构要给客户选择权。

3. 工程化细节，才是真正的差距
很多AI工具在小demo上跑得很漂亮。但一放到生产环境，问题就来了：超时怎么办？限流怎么办？token消耗怎么记录？出错怎么重试？

SpringAI在这方面的积累，远超那些“论文风”的AI框架。它内置了：

重试机制：模型调用失败时，可以配置重试策略

降级策略：AI服务不可用时，可以fallback到本地规则或人工处理

可观测性：集成了Micrometer，可以统计调用次数、耗时、token消耗

缓存：相同问题的答案可以缓存，节省调用成本

这些东西，是Spring生态十几年工程化经验的沉淀。一个框架好不好，不是看它demo跑得多快，而是看在生产环境里稳不稳。

第三章、RAG：让AI“学会”你的业务，而不只是秀智商
1. 大模型什么都懂，就是不懂你的公司
我经常用一个比喻来解释为什么传统应用需要RAG。

GPT-4读过全网几万亿个token，它知道什么是合同、什么是客服、什么是工单。但它不知道你们公司的合同模板长什么样，不知道你们客服的SOP是什么，不知道你们工单的流转规则。它是个通才，但不是你家企业的专才。

那怎么让一个通才变成专才？传统做法是微调——用你们公司的数据去继续训练模型。但这条路对大多数公司来说走不通：需要GPU资源，需要清洗标注数据，需要专业团队，而且还面临数据隐私问题。

RAG换了一个思路：不训练模型，而是在模型回答问题时，临时从你们公司的数据里“查资料”。

流程是这样的：

用户问一个问题

系统把这个问题转成向量

用这个向量去Milvus里做相似度检索，找到相关的业务文档或历史记录

把检索到的内容作为“参考资料”，连同原问题一起发给大模型

大模型基于参考资料生成回答

本质上就是：开卷考试。

2. 一个亲身经历的例子
我们做的那个工单系统，改造前是这样的：客服接到一个问题，先判断属于哪个分类，再在知识库里搜索相关的解决方案，然后打字回复。遇到复杂问题，还得请教老员工。

改造后的流程是：当客服点开一个工单，系统自动做RAG检索——用工单内容去向量库里找“类似的工单以往是怎么解决的”，然后把找到的案例和标准答案一起展示在侧边栏。客服看一眼，觉得靠谱就点“发送”，不靠谱就自己写。

就这么一个侧边栏，让客服的平均处理时间从7分钟降到了3分钟。用户满意度还提高了，因为回复更一致、更规范。

关键点：我们没有改工单系统的一行核心代码，工单流转逻辑、数据库结构、权限体系，全都是原样。只是在界面加了一个组件，在后台加了几条RAG调用。

这就是我理解的“传统应用升级”——不推倒、不重来、只增强。

3. RAG的工程挑战，其实不在AI
做一个RAG demo很容易。但做一个生产可用的RAG，挑战完全不在AI本身，而在工程细节：

数据怎么切分？ 文档切得太细，上下文不完整；切得太粗，向量检索不准。

检索怎么排序？ 得分最高的几个片段未必是最有用的，可能需要根据业务规则做rerank。

上下文窗口不够怎么办？ 大模型的上下文有限，检索出来的内容放不下怎么办？

怎么保证检索结果不跑偏？ 如果不是技术问题而是政策问题，检索到不该出现的内容怎么办？

这些问题，需要你了解业务、了解数据、了解大模型的能力边界。纯AI背景的人解决不了，因为不懂业务；纯业务背景的人解决不了，因为不懂技术。这个中间地带，恰恰是传统后端程序员最擅长的位置。

第四章、Milvus：向量数据库，后端程序员的新朋友
1. 为什么需要专门的向量数据库？
你可能已经知道，向量是一个高维空间里的点。两段文本的语义相似度，可以用它们在向量空间中的距离来度量。

向量检索这事儿，用传统数据库做不了。不是不能做，而是做不了规模化。如果你有几百万条文档，每条对应一个上千维的向量，做一次相似度检索需要计算几百万次距离——MySQL肯定崩了。

Milvus做的事情，就是为这种高维向量检索专门优化的存储和计算引擎。它之于向量检索，就像Elasticsearch之于全文检索。 是一个专门化的基础设施。

2. Milvus给后端程序员的“熟悉感”
说实话，我一开始以为向量数据库的学习曲线会很陡。但用了Milvus之后发现，它的设计理念对我们后端程序员很友好：

集合（Collection） ≈ 关系数据库里的表

插入（Insert） ≈ 还是插入

索引（Index） ≈ 数据库索引，只不过类型不同（IVF_FLAT、HNSW等）

搜索（Search） ≈ 查询，只不过条件不是等值或范围，而是“找最相似的k个”

这种类比一旦建立，上手就非常快。而且Milvus支持标量字段的过滤——你可以先筛选“创建时间在最近一个月”，再在这个范围内做向量检索。这种混合查询能力，在真实业务场景里极其重要。

3. 部署和运维，已经足够成熟
一年前我还担心向量数据库的生产运维问题。但现在的Milvus，已经有了很成熟的生态：

单机开发：Docker Compose一键启动

集群部署：K8s Operator自动化运维

托管服务：阿里云等云厂商提供托管版，不需要自己管集群

对于绝大多数传统应用升级的需求，单机版Milvus的性能已经足够了。等数据量真的上来了，再考虑迁移到集群版。这种从小到大的平滑演进路径，让我可以“先用起来，再逐步优化”。

第五章、程序员的新生态位：不是被替代，而是被增强
1. 我最怕的不是AI替代我，而是我用不好AI
说句心里话，我之前对AI的恐惧，本质上不是怕被替代，而是怕别人会用我不会用。

就像Excel出现之后，会用的财务人员效率翻倍，不会用的就慢慢边缘化了。AI也是一样。它不会让程序员这个职业消失，但它会让“会用AI的程序员”和“不会用AI的程序员”之间，出现一道明显的效率鸿沟。

掌握了SpringAI+RAG+Milvus这套组合，我不是在学一门新语言，而是在给自己手里的Java工具箱增加一套“智能外挂”。以后接到“给老系统加AI”这类需求，别人还在犹豫能不能做，我已经知道怎么做了。这就是竞争力。

2. 这个红利窗口，不会永远敞开
任何一个技术红利，都有窗口期。

第一波：只有少数人知道怎么做，他们吃到最大的红利

第二波：很多人开始学，竞争加剧，但还供不应求

第三波：变成标配能力，不再有溢价

目前，SpringAI+RAG+Milvus这套组合，大概在第一波到第二波的过渡阶段。知道的人不少，真正动手做过生产项目的不多。这意味着，现在入局，仍然可以享受到“稀缺性”带来的红利。

等到三年后，这套技术变成Java后端招聘的“必选项”时，你再来学，就没有红利了。那不是你的错，但那是你的损失。

3. 传统系统升级，是我们这群人最擅长的事
我想说的是：传统应用升级这件事，天然适合我们这群人。

因为我们懂业务——写过那么多年的CRUD，什么样的流程没见过？
因为我们懂系统——知道老系统的坑在哪里，知道怎么在不推倒的情况下加新功能。
因为我们懂工程——知道生产环境要的不是炫技，而是稳定、可运维、可兜底。

AI算法工程师不懂你的业务，产品经理不懂你的技术约束，架构师可能已经脱离一线太久。真正能把AI能力落地到传统业务场景里的人，就是还在写代码、还在跟数据库打交道、还在被业务部门追着改需求的后端程序员。