1. 从 Spring Boot 4 的传闻说起Java 后端正在进入一个新周期最近社区里关于 Spring Boot 4 的讨论越来越多虽然官方正式版本还在路上但 Spring 团队在 roadmap 里已经明确释放了几个信号升级到 Jakarta EE 11、基于 Spring Framework 7、对 GraalVM Native Image 做更深度的支持以及把 Spring AI 从实验性质的项目逐步纳入主航道。如果你一直在用 Spring Boot 3.x 做业务开发可能觉得这些变化离自己还有一段距离但从我个人的实践体会来看Boot 4 代表的并不是一次普通的版本升级而是 Java 后端开发范式的一次重塑从数据库 CRUD 中间件集成的传统模式转向模型驱动 智能体编排 本地化推理的新模式。这就要说到那个更底层的问题了AI 时代工程师真正不可替代的能力是什么最近我刷到了很多相关的讨论也陆陆续续在几个项目里用 Spring AI 和 AI Agent 做了不少尝试包括基于 Spring Boot 的预约服务系统、婚庆服务平台的智能化改造甚至还有一些内容生成方向的 Demo。实话讲工具层的变化真的很快今天你还在手写 Prompt明天可能就在调 Agent 框架后天可能又在研究模型微调。但做得越多我越清楚地感觉到一件事技术栈会不断被替换但对业务问题的拆解能力、对系统边界的判断能力、以及对 AI 输出的批判性验证能力才是真正能穿越周期的东西。这篇文章我不想写成 Spring Boot 4 的新特性罗列也不想熬一碗AI 时代要拥抱变化的鸡汤。我想结合我最近一段时间用 Spring Boot 做 AI 应用开发的实际经历拆一拆 Spring AI 到底解决了什么问题、AI 编程工具的真实边界在哪里、以及我们这些被AI 替代焦虑包围的工程师应该把精力花在哪些短期内不会被替代的能力上。如果你正在做 Java 后端或者你正在纠结要不要把 AI 融入自己的技术体系这篇文章应该能给你一些具体的参考。2. Spring Boot 4 的核心走向AI 不是外挂而是基础设施2.1 Java 后端为什么需要一个官方的 AI 集成方案先聊一个很多人可能没细想的问题Java 后端做 AI 应用难吗从纯技术角度说调用 OpenAI、通义千问或者本地部署的 DeepSeek 接口并不难一个 HTTP 请求带上 Key 和 Prompt 就能拿到结果。但一旦进入真实业务场景问题就变得复杂了。举个例子我在做基于 Spring Boot 的上门烹饪预约服务系统的时候最初的设想很简单用户提交预约需求后系统自动生成一条服务说明推荐合适的厨师。但真正做起来发现AI 的接入远不止调一次接口那么简单。你需要考虑上下文管理用户是多轮对话你不能每次都把整个聊天记录全部塞给模型你需要考虑模型输出格式的稳定性推荐结果要结构化不能靠正则去解析自由文本你需要考虑模型不可用时的降级方案不能因为第三方接口超时就让整个预约流程瘫痪你还需要考虑流式输出、Token 消耗、Prompt 版本管理、敏感信息过滤等一系列问题。这些需求单独看都不难但组合在一起如果每个项目都从零开始做那就是巨大的重复劳动。Spring AI 的价值就在于此它把模型调用、Prompt 管理、结构化输出、向量数据库集成这些能力封装成了统一的抽象层让 Java 开发者可以用 Spring 风格的 API 去对接不同厂商的模型而不是为每家模型厂商写一套适配代码。Spring Boot 4 把 Spring AI 纳入核心生态其实就是在传递一个态度AI 能力正在从可选的加分项变成基础设施级的标配能力。2.2 从 WebFlux 到 AI Agent响应式架构的新用武之地Spring Boot 4 另一个值得关注的底层变化是它建立在 Spring Framework 7 之上而 Spring Framework 7 会进一步强化响应式编程模型。很多同学可能觉得响应式编程学起来麻烦、调试困难业务系统用得也不多所以干脆只用一个 WebMVC 就够用了。这个想法放在过去没什么问题但在 AI 应用场景下响应式模型的价值会重新凸显。原因很简单AI 推理的响应时间通常比普通数据库查询慢一个数量级而且大模型普遍支持流式输出。你要做一个打字机效果的 AI 对话界面后端如果走传统的同步阻塞模型一个请求占一个线程几十个并发就能把线程池打满你还得额外引入消息队列来削峰。但在响应式模型下你可以基于 WebFlux 配合 SSEServer-Sent Events把模型输出的 token 流实时推给前端整个过程中线程始终处于非阻塞状态系统可以支撑更高的并发连接数。我在做一个 AI 辅助业务数据分析的小工具时就用到了这个特性。前端页面有一个生成分析报告的按钮点击之后后端调用大模型接口模型边生成内容边通过 SSE 推送到页面用户的体验是看着文字一个个蹦出来而不是白屏转圈等十几秒。如果走传统方式这个功能也可以实现但响应式模型写起来更自然而且在模型完全不可用的时候我们可以直接在流中推一个错误事件前端立刻展示降级提示体验会好很多。2.3 对现有 Spring Boot 项目的迁移影响说了这么多 Spring Boot 4 的新特性可能有人会问那我现有的 Spring Boot 2.x / 3.x 项目怎么办是不是得大改根据 Spring 团队一贯的兼容性策略以及 Spring Boot 2.7 到 3.x 迁移时给过的过渡方案Boot 4 大概率会提供一条相对平滑的迁移路径但有几个点你需要提前关注。第一是 Jakarta EE 版本的升级。Spring Boot 3 已经强制切到了 Jakarta EE 9Boot 4 如果升级到 Jakarta EE 11意味着一些老旧的第三方库如果还停留在 javax 命名空间就需要单独处理兼容性。第二是 Springfox 这类老的 API 文档工具我在 springfox 3.0.0 与 Spring Boot 2.6 的集成上踩过不少坑社区里也一直在推荐用 springdoc-openapi 替代到了 Boot 4 这个趋势只会更明显。第三是配置属性的变化每次大版本升级都会有一批配置项被重命名或废弃你需要借助官方迁移工具加人工审查来逐一确认。但比起这些技术细节我更想强调的是架构层面的转变。如果你现在的项目还在用传统的 MVC 分层、一个 Service 里写几百行业务逻辑、通过 XML 或注解硬编码各种规则那么即使不升级到 Boot 4面对 AI 应用的快速迭代需求也会越来越吃力。因为 AI 应用的核心特点是不确定性模型输出不确定Token 消耗不确定链路中的每个环节都可能需要动态调整。传统的面向稳定业务逻辑的架构在这种高不确定性场景下会显得非常僵硬。3. Spring AI 实践拆解模型接入、结构化输出、Prompt 工程的落地姿势3.1 一个最简单的 Spring AI 接入案例先看一个最直白的例子在 Spring Boot 项目中接入一个大语言模型到底需要几步我用 Spring AI 的 OpenAI 模块做了一个测试工程整个过程比我预期的还要简单核心依赖加上之后只需要一个 Config 类和一个 Service 类就能跑通。Configuration public class AIConfig { Bean public OpenAiChatModel openAiChatModel() { OpenAiApi api new OpenAiApi( https://xxx.api.endpoint, // 代理服务地址或官方地址 sk-your-key, Duration.ofSeconds(30) ); return new OpenAiChatModel(api); } }然后在 Service 里注入 ChatModel调用 call 方法拿到响应Service public class RecipeSuggestionService { private final ChatModel chatModel; public RecipeSuggestionService(ChatModel chatModel) { this.chatModel chatModel; } public String suggestRecipe(String ingredients) { String prompt 你是一名专业厨师请根据以下食材推荐一道家常菜 并给出详细的烹饪步骤。食材 ingredients; return chatModel.call(prompt); } }这看起来简单到有点不像真的但 Spring AI 做的最重要的事情就是把这个过程统一和简化了。以后如果要从 OpenAI 切到通义千问你只需要换一个 Client 实现或者改一下配置项业务代码完全不用动。这种可替换性在真实项目里非常关键因为模型厂商的能力和价格都在快速变化你不可能把业务绑死在某一家上。3.2 结构化输出让模型按规矩办事调用模型拿到一段自然文本这只是入门。真实业务系统需要的往往是结构化数据。还是拿上门烹饪预约系统举例用户说了一句我想明天晚上七点预约一位能做川菜的厨师预算五百以内三个人吃你要把这段自然语言转成结构化的预约表单包含时间、菜品类型、预算、人数、地址等字段。如果让模型自由发挥然后靠正则解析一次两次可能没问题但一旦用户的表达方式变化解析逻辑就会变得很难维护。Spring AI 提供的办法是让你在调用时指定输出格式。你可以定义一个 Java record然后在 Prompt 里告诉模型只输出 JSON 对象字段必须包括 date、cuisineType、budget、headcount、address代码层面再用一个转换器把模型输出映射成 Java 对象。这样模型返回的内容就能直接进入 Service 层做业务处理不需要额外的字符串解析。以下几点是我在实际使用中总结出来的经验输出 Schema 一定要在 Prompt 里给出明确的示例尤其是字段枚举值模型容易理解偏差。对关键字段要加取值范围校验模型偶尔会输出超出预期的值你必须在业务层兜住。如果模型频繁返回非法 JSON可以打开 Spring AI 的 ContentModeration 或日志功能先把原始输出打印出来分析不要盲目调整 Prompt。我踩过的一个典型坑是在婚庆服务预约平台里我让模型提取婚礼日期模型返回了下周六这种相对时间而不是具体的日期字符串。后来我在 Prompt 里强制加了一条规则必须把相对时间换算成 yyyy-MM-dd 格式的绝对日期以当前日期为基准效果立刻改善。这说明结构化输出的核心不是让模型读懂你的需求而是你如何把业务规则翻译成模型能遵守的指令。3.3 Prompt 工程不是写几段话而是设计一条链路很多人对 Prompt 工程的理解还停留在把需求描述清楚这个层面但真正做过 AI 应用后你会发现Prompt 是一个需要版本管理、需要测试、需要线上线下联调的系统工程。我在做 AI 辅助内容生成方向的小工具时维护了一个 Prompt 模板仓库每个模板都有版本号、参数列表和评测用例。每次修改 Prompt都要跑一遍回归测试确认对已有场景没有破坏。Spring AI 的 Prompt 模板机制给了我不少帮助。它支持类似 Thymeleaf 的模板语法你可以把动态参数嵌入到模板字符串中也可以定义多个 Prompt 组合成一条完整的对话链路。一个比较常见的设计模式是先系统后用户系统 Prompt 设定角色、行为边界和输出规则用户 Prompt 只负责输入具体的业务请求。这样做的好处是当业务需求变化时你只需要调整系统 Prompt用户侧的输入不需要跟着改。还有一个容易忽略的点是 Prompt 的 Token 消耗。很多模型是按 Token 计费的如果你的 Prompt 模板写得非常啰嗦每一个请求都会产生不必要的开销。我个人的习惯是系统 Prompt 控制在 500 Token 以内业务参数尽量精简固定模板和动态内容分开管理。在访问量大的场景下这个细节会直接变成成本指标的差异。提示无论是 Spring AI 还是其他框架Prompt 都不是一次写对的。务必保留每个版本的 Prompt 副本标注改动原因和验证结果这能帮你避免调着调着不知道哪个版本好用的窘境。3.4 向量数据库与 RAG让模型懂你的业务数据如果你只是想做一个通用问答机器人那直接用大模型的通用知识就够了。但大多数业务场景没那么简单。比如婚庆服务预约平台里有一个套餐 AI 推荐的功能平台有自己的一套套餐体系、定价策略、档期规则这些数据是模型在训练时没见过的。如果直接把用户的需求丢给模型模型只会根据自己的理解胡乱推荐结果完全不可用。RAG检索增强生成就是解决这个问题的标准方案先把业务文档向量化存入向量数据库用户提问时先从向量库中检索相关信息再把检索结果作为上下文一起交给模型生成回答。Spring AI 在向量数据库这一块做了比较清晰的抽象支持 Chroma、PGVector、Redis 等多种存储。我建议小团队直接从 PGVector 起步就好因为它不需要额外引入一个中间件直接在现有的 PostgreSQL 上就能用运维成本很低。但 RAG 也不是银弹我踩过的几个坑分享给你切分策略很关键。文档不是切得越短越好切得太短会丢失上下文切得太长会超过模型上下文窗口。我的经验是中文场景下按 300 到 500 字一段做重叠切分效果相对稳定。向量检索的相似度阈值要实测调整。默认的余弦相似度阈值是 0.7但实际业务中 0.5 的结果也可能是有效的。要拿真实用户的提问去反复测试找到最适合当前数据分布的那个值。检索结果不是越多越好。你喂给模型的上下文越长模型越容易迷失在无关信息中。一般情况下检索 Top 4 到 Top 6 条就足够了。4. AI 时代工程师的真实工作流从 AI Agent 到本地部署4.1 AI Agent 是什么以及它和简单 Prompt 调用的区别接下来聊聊 AI Agent。这是当前热度最高的概念之一但我发现很多开发者对 Agent 的理解停留在能多轮对话的聊天机器人这个层面。实际上Agent 和普通聊天机器人的核心区别在于Agent 有工具调用能力它能根据用户的目标自主决定调用哪些工具、按什么顺序调用、如何根据工具返回结果调整下一步行动。举个具体的例子。在基于 Spring Boot 的预订系统里我设计了一个智能客服 Agent。用户问帮我看看下周三还有没有空档如果是普通聊天机器人模型只能给出泛泛的答复它不知道实际的档期数据。但 Agent 不一样我在工具注册表里给它加了一个queryAvailableSlots(date)的函数模型收到用户问题后会先解析出日期然后调用这个工具查询数据库拿到真实的空档信息后再组织自然语言回复。整个过程不需要人工干预。Spring AI 对 Agent 的支撑正在逐步完善包括函数注册机制、会话记忆管理、多 Agent 协作框架等。但在实际项目中我建议你在引入 Agent 之前先把一个基础问题想清楚这个功能真的需要 Agent 吗很多场景用简单流程编排就能解决引入 Agent 反而会增加不可控性。不过反过来说如果你是做 AI 应用开发的掌握 Agent 的编排思想是迟早的事因为未来的业务系统一定会出现越来越多由模型驱动、按需调用服务的模式。4.2 本地部署 AI 模型哪些场景值得做哪些慎重做本地部署也是最近的热门话题。GitHub 上有很多开源项目在做本地模型部署本地部署的核心优势是数据安全可控、没有外部接口调用的网络延迟和限流风险、长期使用成本更低。但劣势也很明显显卡成本高、运维复杂、模型能力不如顶级商用模型。从我的实践来看以下场景适合本地部署涉及用户敏感数据的业务比如医疗、金融数据不能出内网。高频低延迟的辅助功能比如代码补全、短文本分类、实体抽取模型不需要太强大但响应必须够快。有 GPU 资源的团队本地化部署比按量付费更划算。而在需要复杂推理、创意生成、开放式问答的场景本地小模型的体验和商用大模型差距还是比较明显的我建议这类需求优先走 API 调用。如果实在有成本压力可以结合本地小模型做初步处理、商用大模型做最终生成的两级流水线在成本和效果之间找一个平衡点。以我现在的团队为例我们做了一个AI 辅助工程文档生成的小工具用本地部署的量化模型做初稿生成再用商用模型做润色和格式化。原因很简单初稿生成对质量要求不高本地模型已经能完成任务而润色这步需要更好的语义理解和风格把控交给更强的模型更稳妥。这种混合编排的架构在真实项目里非常实用。4.3 AI 编程工具的现实与幻觉再聊一个和每个开发者都密切相关的话题AI 编程工具。我在调研 AI 编程提示词、试用 Cursor 等工具的时候感受是复杂的。用得好它确实能帮你大幅提升效率。举个例子我写一个常见的 Service 接口实现、写一个 Spring Data JPA 的 Repository、写一段配置类的属性绑定这些重复性工作交给 AI 工具准确率非常高基本可以直接用。但问题也很突出。首先是 AI 幻觉问题。模型在你不熟悉的库或框架上会一本正经地给你一段不存在的 API 用法。让我印象最深的一次是我让 Cursor 帮我写一段 Spring AI 的向量存储配置它给了一个EmbeddingStore的实现方式代码结构看起来非常合理但实际上那个类在当前的版本里根本不存在编译就直接报错。这种错误如果你没经验、没仔细看文档就很容易被带偏。所以我的原则是AI 生成的代码你至少要能看懂它在干什么并且有能力验证它是否正确。能力不是拉低而是能否判断模型输出是否正确。这个门槛看起来基础但在 AI 时代恰恰是分水岭。还有一个容易被忽略的问题是上下文窗口的局限。你在 IDE 里让 AI 帮你改一个项目它很多时候是看不到完整项目上下文的只能基于当前打开的文件做推断。这意味着大型重构、跨模块联动修改这类任务AI 工具目前更像一个聪明的新手可以帮你做局部修改但整体架构设计还是得由人来把控。注意不要在生产环境直接使用 AI 生成的完整模块代码尤其是涉及权限校验、事务管理、支付逻辑等功能时必须逐行审查。我见过不止一次 AI 生成的代码在边界校验上漏掉空指针判断一旦上线就是事故。5. 工具在变什么能力是不可替代的5.1 拆解问题AI 能写代码但谁能讲清楚要写什么前面聊了 Spring Boot 4、Spring AI、AI Agent、本地部署这些都在说明一件事AI 正在不断降低编码的门槛。以前要花一个下午手写的 CRUD 代码现在几分钟就能生成。那你可能会问工程师的价值是不是真的在缩水我的答案是写代码的时间确实在缩水但搞清楚到底要写什么代码的时间没有缩水反而更值钱了。你去看很多失败的 AI 项目问题往往不是模型能力不行而是业务需求从一开始就没被定义清楚。产品的目标用户是谁核心场景是什么哪些环节必须人工兜底模型的输出如何与现有系统衔接这些问题的答案AI 是无法替你产生的。我参与过基于 Spring Boot 的上门烹饪预约服务系统这类项目其实它表面上是个业务管理系统但真正的难点在于把线下的服务履约流程抽象成线上的数据模型和状态机。AI 可以帮你写预约实体的字段定义可以帮你写状态流转的代码但它不能替你回答预约取消之后厨师那边要怎么补偿用户爽约怎么记录信用分这类业务规则问题。能回答这些问题的只有懂业务、懂用户、懂系统边界的工程师。5.2 评估 AI 输出把看起来对变成确定对AI 的输出天然带有概率性尤其在大语言模型场景下同样的输入可能每次返回不同的结果。这在写作、创意生成这类场景里没问题但在业务系统里不确定性是需要被严格控制的风险源。因此我这两年最深的体会是工程师的一个核心能力就是验证。验证分为三个层面。第一是技术验证你能否判断一段 AI 生成的代码是否真的能跑通、是否没有安全隐患第二是业务验证你能否判断 AI 输出的业务内容是否符合规则、是否偏离了产品设计的初衷第三是数据验证你能否监控线上 AI 服务的输出质量建立一套从用户反馈到模型迭代的闭环。这三个层面前两个是基础的工程素养第三个则开始涉及 AI 产品运营的能力很多团队恰恰是在这个环节掉链子的。在 AI 应用开发项目中我建议一定要做好可观测性设计。给每次模型调用生成唯一的 traceId把 Prompt 版本号、模型参数、输入输出、耗时和 Token 消耗全部记录下来一旦线上出现质量问题能快速定位是模型的问题、Prompt 的问题还是业务逻辑的问题。没有这个观测链路AI 应用就是一团黑盒出问题了根本不知道从哪里查起。5.3 架构判断在不确定性中做决策的能力AI 应用最大的特点就是不确定。模型今天和明天的能力可能不一样模型厂商今晚可能推出一个新的 API 版本第三方接口可能随时限流或故障。在这种环境下工程师的核心竞争力不再是把代码写得漂亮而是在不确定中做决策的能力——而这个能力恰恰是 AI 很难替代的。举一个非常具体的例子。在设计系统架构时你面临两个方案方案 A 是用 Spring AI 的抽象层对接模型厂商好处是灵活坏处是多了一层封装排查问题时要多看一层代码方案 B 是直接用各个模型厂商的原生 SDK好处是直接、文档全坏处是模型厂商一升级你可能就要跟着改代码。你在做这个取舍时需要考虑团队的技术能力、业务对稳定性的要求、未来的进化方向这些因素不是一个 AI 工具能帮你权衡的。再比如是否引入 AI Agent 的决策。Agent 看起来很美好但它的代价是调试复杂、行为不可预测、对观测系统的要求极高。很多业务场景根本不需要 Agent一个带函数调用的单轮模型就够用了。能做出这种克制的判断不被技术热词绑架这也是资深工程师和新手之间的一个核心差距。5.4 沟通与协作AI 不懂业务但懂业务的人懂 AI 的边界最后我想聊聊一个最容易被技术人忽视的能力沟通和协作。做 AI 应用项目时你要同时和业务方、产品经理、数据工程师、运维工程师甚至法务合规团队打交道。业务方往往对 AI 有很高的期待他们会相信AI 什么都能干而你需要建设性地把这些期待拉到现实的水平上。我遇到过不止一次这样的场景业务方拿来一个需求说让 AI 帮我们自动生成营销文案一键成片市场部就不用招人了。但实际上一个AI 广告视频一键成片或者AI 带货视频一键成片的系统背后的复杂程度远超业务方的想象。你需要拆解目标是什么平台的视频素材从哪里来是否需要真人出镜审核机制怎么设计营销话术需要符合哪些规范。这些需要你对业务有足够深刻的理解才能给出一个真正可落地的方案而不是盲目给出一个实现不了或效果很差的承诺。所以我的结论很朴素AI 越来越像一个能力极强的实习生它能做很多事但每一件事都需要你给出清晰的目标并且有人来对它负责。能把这个实习生用好能跟各方讲清楚它的可能性和边界这才是 AI 时代工程师真正意义上的不可替代性。6. 几个实战中必须留意的细节与踩坑记录6.1 模型接入方式的选型建议我把最近的实践体会整理成一张对照表适合你根据自己的团队情况来选型接入方式优点缺点推荐场景直接调官方 API接入快、效果最好数据出外网、按量付费成本不确定非敏感业务、快速验证原型通过 Spring AI 统一抽象层可替换模型厂商、与业务代码解耦多一层封装、新框架有学习成本中大型项目需要长期演进本地部署开源模型数据不出内网、长期成本低、延迟可控需要 GPU、效果有限、运维复杂敏感数据场景、高频低复杂度任务混合编排灵活、成本效果平衡架构复杂度高、链路长、问题排查困难有专门 AI 应用团队的团队从我个人的项目经验看小团队起步阶段最适合的方式是直接用 Spring AI 对接一个主流模型 API因为它的学习曲线最平滑、可替换性也最好。等你的业务规模上来了、访问量大了、用户对成本和合规提出了更高要求再逐步引入本地推理和专用模型不要一开始就把架构搞得过于复杂。6.2 与现有 Spring 生态的集成细节Spring AI 在 Spring Boot 项目里的集成有一个比较省心的点它本身是 Spring 家族的一员所以和 Spring Boot 的自动配置、Actuator 监控、配置属性绑定这些机制融合得非常好。你可以直接用application.yml配置模型密钥和参数也可以用ConfigurationProperties管理自定义的模型配置项。但这里有一个安全细节必须提醒你模型 API 的密钥不要硬编码在代码里也不要直接提交到 Git 仓库。要么用环境变量要么用配置中心要么用云厂商的密钥管理服务。我在一些开源项目里看到过把 sk-xxx 这种密钥直接写在配置文件的例子这在真实生产环境里是重大安全隐患。如果你的项目使用了第三方 AI 接口务必把密钥管理纳入上线前的安全检查列表。还有一个容易被忽略的细节是超时设置。大模型接口的响应时间和传统的 REST API 完全不是一个量级普通接口 3 到 5 秒超时是合理的但模型接口在复杂推理时可能要 30 秒甚至更久。我在 Spring AI 的配置里会把连接超时设为 10 秒、读取超时设为 60 秒以上同时配合响应式模型和流式输出避免用户长时间无反馈。如果你的业务场景对响应时间有硬性要求那就要在架构层面考虑异步任务加轮询的方案而不是简单地调大超时。6.3 测试与回归AI 应用的质量保障怎么做最后说说 AI 应用的测试。这是我在工作中发现很多团队做得很薄弱的地方传统的单元测试和接口测试在 AI 场景下会遇到两个挑战第一模型输出是概率性的你不能用结果等于某个字符串来断言第二第三方模型接口不是本地可控的测试过程中可能出现网络波动或限流。我的做法是引入快照测试 规则测试的组合。快照测试是指用固定的输入跑一次模型把输出结果保存为快照后续每次改动 Prompt 或模型参数后重新跑一遍并对比快照的差异人工判断差异是否可接受。规则测试则是用正则或 JSON Schema 验证模型输出的格式是否合规比如是否包含必填字段、枚举值是否合法、长度是否在限制范围内。这两种方式结合起来能在不追求输出完全一致的前提下有效控制模型输出的质量风险。除此之外我强烈建议在 AI 应用上线前准备一套降级预案。模型厂商可能出现故障密钥可能过期网络可能出现抖动。你的系统必须在这种异常情况下仍然能给出一个用户可接受的响应。比如在预约服务里如果 AI 推荐服务不可用就回退到基于规则的商品推荐和人工客服入口如果 AI 文案生成失败就回退到模板文案。没有降级方案的 AI 功能本质上是一个定时炸弹。7. 写在最后的个人体会回看Spring Boot从1.x走到4.x这段路我做过的项目从传统的后台管理系统、预约平台到最近不断尝试的AI应用和Agent集成工具和框架换了一轮又一轮。说实话早些年我也会焦虑担心新框架、新语言、新工具的出现会让自己的经验贬值。但现在我的心态反而稳定了很多因为看得越清楚就越明白技术永远在变但定义问题-拆解问题-验证方案这条主线一直没变过。如果让我给还在纠结学Spring Boot 4还是学AI的同行一句建议我不会让你二选一。我的建议是继续把自己的后端基本功做扎实——事务、并发、缓存、消息、架构设计这些是软件工程的底子任何时候都不会过时同时积极把AI当成一种新的能力来集成。学会用Spring AI写一个结构化输出的服务学会用一个Agent完成一次工具调用学会评估一个模型输出的质量和风险这些都是能把你的工程能力放大十倍的新技能。最后再分享一个小技巧AI时代学习新东西最好的方式不是看一堆课程而是找一个真实的小项目从一个最小的闭环开始做起来。我当时就是这样拿一个基于Spring Boot的预约系统试着给它的推荐功能接上AI推一步走一步。遇到问题、解决问题、再遇到新问题这个过程本身就是建立AI时代工程直觉的最好方式。