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

开篇：从“被替代的焦虑”到“被增强的底气”

我做了十年后端开发。Spring Boot用了八年，微服务架构跟风了五年。坦白说，这两年是我职业生涯里最焦虑的一段时间。

不是怕加班，不是怕业务复杂。焦虑的根源是：大模型来了，我手里的这些技能，还能用多久？

每天打开技术社区，满屏都是“AI替代程序员”“大模型自己写代码”。我一度怀疑自己是不是要失业了。直到我开始真正动手做一件事——把我参与过的一个老旧的合同管理系统，用SpringAI做了智能化改造。

做完之后，我的心态完全变了。我不再担心被替代。因为AI不是来抢我饭碗的，它是来给我的技能加杠杆的。而打通这层认知的钥匙，就是SpringAI。

这篇文章，我想从一个普通后端程序员的角度，聊聊我对应用架构未来趋势的判断，以及为什么SpringAI会是传统系统智能化转型最务实的一条路。

一、传统系统智能化：一个被严重低估的存量市场

1.1 新应用是浪花，旧系统才是大海

整个科技行业的聚光灯，永远打在那些从零开始的新项目上。“某大厂推出AI原生应用”这类新闻天天见。但很少有人认真想过一个问题：全世界有多少行代码正在生产环境里跑着？

这个数字没人能精确统计，但常识告诉我们：那些支撑着银行、物流、制造、零售、政务运转的核心系统，90%以上都不是“AI原生”的。它们是十年、甚至十五年前用Java、Spring、Hibernate、MyBatis堆出来的。它们不性感，但它们每天都在处理真实的交易、真实的订单、真实的客户。

这些存量系统的智能化升级，才是真正的蓝海。

为什么？因为企业不会因为AI出现了就把老系统推倒重来。成本不允许，风险不允许，业务连续性不允许。它们的真实需求是：能不能不动核心代码，给老系统“加装”一个AI引擎？

这就是传统系统智能化转型的核心命题。

1.2 什么叫“智能化”？我说四个具体场景

光说概念太虚。我说几个我自己经历过或者认真想过的场景，你就懂了：

场景一：智能审批。 原来的合同审核系统，所有条款都要人工一条条看。如果能在提交审核前，让AI先扫描一遍合同，标出“偏离标准模板”的条款、建议修改措辞、提示潜在风险——审核效率至少翻一倍。

场景二：工单辅助。 客服工单系统里，每天涌入几百条不同类型的诉求。能不能让AI自动识别工单类型、判断优先级、甚至推荐回复模板？坐席员点一下确认就行，不用从头打字。

场景三：知识问答。 每个公司内部都有成堆的文档、SOP、操作手册。员工遇到问题，要么问老同事（人家不一定有空），要么自己翻（找不到）。把知识库向量化，做一个“问自己公司”的AI助手，能省下大量沟通成本。

场景四：异常检测。 订单处理流程中，总有一些订单走到半路卡住了。传统做法是等用户投诉才发现。能不能让AI实时监控流程状态，发现异常就自动标记并推送相关人员？

这些场景有一个共同特点：核心业务逻辑不动，只是在关键节点“插入”AI能力。 这不像新建一座大楼，更像给老房子加装电梯——工程量可控，回报却很实在。

二、为什么是SpringAI？——一个老Spring程序员的选型心路

选技术方案，我最看重三点：学习成本、集成代价、长期可维护。 在这三个维度上，SpringAI是目前我看到的最优解。

2.1 对既有经验的尊重

我大概是这样一群人：十几年Java后端，熟悉Spring生态，对Spring Boot、Spring Cloud、Spring Data如数家珍。但要我去学Python那套AI栈——FastAPI、LangChain、Pandas、Jupyter Notebook——不是说学不会，而是切换成本太高。

不光是我一个人的学习成本，还有团队、基建、部署规范、监控体系……换一套技术栈，牵一发而动全身。

SpringAI最大的价值，就是把AI集成这件事，拉回到了Spring程序员熟悉的范式里。依赖注入、RestTemplate、ApplicationContext……这些东西你用了十年，现在还是它们。你不需要换阵地，只需要在阵地上增加新的武器。

2.2 抽象层带来的自由

说实话，大模型厂商的生态我有点看不懂。OpenAI、通义千问、智谱、文心……各家API不一样，参数不一样，返回格式不一样。如果代码里直接调某个厂商的SDK，哪天想换一家，或者想同时支持多家，那叫一个酸爽。

SpringAI在上层做了一层抽象：ChatClient、ChatModel、PromptTemplate、OutputParser……这些接口跟你用过的JdbcTemplate、RestTemplate神似。底下对接哪个模型，是配置层面的问题，不是代码层面的问题。

这对于做企业级应用的人来说太重要了。企业不想被任何一家云厂商绑定，这是基本的商业诉求。

2.3 工程化细节补齐得好

很多AI框架，demo跑得飞起，一到生产就露馅。SpringAI在几个关键工程化问题上考虑得很周全：

可观测性：集成了Micrometer，调用大模型的耗时、token消耗、成功率都可以纳入现有的监控体系

重试与降级：内置了RetryTemplate风格的容错机制，模型调用失败时如何处理，你自己说了算

提示词管理：提示词不再是代码里的字符串，可以外置、可以版本化、可以动态组装

这些东西，做过生产系统的人都懂有多重要。AI项目失败，十个有八个不是因为模型不够强，而是因为工程化没做好。

三、RAG：让老系统的数据“活”起来

3.1 大模型不懂你的业务，但你的数据库懂

一个朴素的事实：通义千问再聪明，它也不知道你们公司的产品目录、客户等级、审批流程。它没学过这些。如果你直接问它“这个订单该不该给VIP折扣”，它只能瞎猜。

RAG的思路非常简单也很优雅：你先把业务数据准备好（存到向量数据库），当用户提问时，先从你的数据里找相关内容，连问题带内容一起给大模型，让它基于这些信息回答。

用技术人熟悉的方式类比：传统的查询是select * from orders where order_id = ?。RAG做的事情是：先做相似度检索（用语义而不是精确匹配），把检索结果作为上下文组装到提示词里，然后调用大模型生成回答。

3.2 一个老系统的改造实录

我改造的那个合同管理系统，改造后的流程是这样的：

用户上传一份合同草稿。系统不是直接存文件，而是做三件事：

把合同文本切片，每一片转成向量

把向量存到Milvus

调用大模型生成一份“风险初评”

当审核人员打开合同时，系统自动做一次RAG检索：用合同里的关键条款去向量库里找“历史上类似的合同过往是怎么审的”，把历史案例作为参考，让大模型给审核人员生成一份修改建议。

核心业务逻辑一行没改。合同存储还是那张表，审核流程还是那些状态，权限控制还是那些角色。只是在界面上多了一个“AI建议”的侧边栏，在后台多了几条RAG调用。

这就是我理解的“传统系统智能化转型”——不动筋骨，加装智能。

3.3 不需要完美，只需要有用

很多人对AI落地有一个误解：必须是99%准确才能上线。这是研究思维，不是工程思维。

真实业务场景里，AI的建议准确率70%就已经很有用了。审核人员本来要一张张合同从头看到尾，现在AI帮他先标出可疑条款、给出修改建议，他只需要确认或者微调。哪怕AI只对了70%，也节省了大量时间。

我经常跟团队说：别追求AI替代人，追求AI帮人省时间。 前者的门槛极高，后者的门槛其实没那么高，而且价值已经足够大。

四、程序员的新能力模型：从写代码到编排智能

4.1 AI时代，什么能力更值钱了？

有些技能在贬值。比如纯记忆性的知识、模式化的代码编写、格式转换这类机械劳动。大模型干这些比你快。

但有些能力在升值，而且是大幅升值：

第一，业务理解能力。 AI不懂业务上下文。谁能在不完整的信息中抽象出业务规则，谁就能指挥AI做正确的事。

第二，系统架构能力。 AI能力不是孤立的，它要嵌入现有的系统里。哪里放检索、哪里放缓存、哪里降级、哪里人工兜底——这些决策越来越重要。

第三，问题拆解能力。 一个复杂的业务问题，往往不能直接丢给AI。得拆成若干个子问题，设计好每个子问题的输入输出，再用AI一个个解决，最后把结果组装起来。

你会发现，这些能力跟AI没出现之前一个优秀程序员应该具备的能力，本质上是一样的。AI不是改变了能力的排序，而是放大了这些能力的价值。

4.2 从“手工艺人”到“智能编导”

我用一个类比来描述这种角色的变化。

以前的程序员像“手工艺人”：拿到需求，画流程图，写代码，调试，上线。每一个步骤都要自己动手。

有了AI之后，程序员更像“编导”：我知道这场戏需要什么效果（业务目标），我能调配不同的演员（大模型、搜索引擎、数据库、API），我设计这场戏的剧本（提示词、流程编排），我来判断什么时候用替身（降级方案），我负责最后的效果审核（人工校验）。

代码量的多少不再是衡量能力的唯一标准。能不能设计出一套高效的“人机协作流程”，才是新的分水岭。

SpringAI这套工具链，恰好就是帮你完成这个角色转变的训练场。它不要求你放下已有的Spring技能，而是让你在已有基础上长出新能力——就像给你手里的工具加了一个“智能”附魔。

五、务实的前进路线：从今天开始，不要等

如果你认同我的判断——传统系统智能化是未来三年最大的增量市场——那么下一步就是行动。我给你的建议很务实：

第一步：认同转变（1周）

别把AI当成对手，把它当成工具。这个心态转变是后面一切的前提。你可以焦虑，但不能一直焦虑。把焦虑转化成动手的动力，一周时间足够。

第二步：跑通一个最小原型（2周）

选一个你最熟悉的、体量不大的内部系统。不要太复杂。比如你们团队的一个知识库、一个FAQ页面、一个工单列表。用SpringAI + 一个免费的大模型API，做一个“问这个系统”的demo。

不追求性能，不追求完美，甚至不追求上线。只追求一件事：你亲手跑通了从用户输入到AI回答的完整链路。这一圈跑通，你的信心就建立起来了。

第三步：找一个真实场景深入（1-2个月）

这是最关键的一步。找一个真实的生产场景——不是demo，是真的有人在用的功能。哪怕一开始只做一个很小的AI辅助功能，比如表单填写时的智能推荐、列表页面的自动摘要。

在真实场景里，你会遇到所有教科书不写的问题：延迟、成本、准确率波动、用户不信任……解决这些问题的过程，就是你真正掌握这门技术的时刻。

第四步：沉淀为能力和作品（持续）

把你做的项目写成案例。不要只写技术点，要写清楚：原来的痛点是什么？AI解决了什么？效果怎么度量？用户反馈如何？

这些东西，就是你说服下一个雇主或者下一个客户的最好证据。在AI时代，作品比简历重要一百倍。