告别“拼接Prompt”，这些Spring AI特色能力让我直呼真香
告别“拼接Prompt”，这些Spring AI特色能力让我直呼真香
上两篇文章聊了Spring AI的本地搭建和一些基础用法。这次不写搭建了，直接上硬菜——聊聊Spring AI那些让我觉得“这东西真的不一般”的特色能力。
先说明一下我的立场：我不是Spring AI的布道师，更不是拿钱推广的。我就是一个在Java生态里摸爬滚打了好多年的普通开发者，因为工作原因接触过LangChain4j、LlamaIndex、Dify好几个框架。用下来的真实感受是：每个框架都有自己的脾气，但Spring AI最打动我的是它把Spring的那套工程化思维原封不动地搬到了AI场景里。
今天聊的这几个案例，都是我在实际项目中反复折腾、踩坑、最后真香的东西。
案例一：多模型切换，干掉“供应商锁定”焦虑
先说说一个特别真实的痛点。
去年我接手一个项目，客户一开始选了OpenAI的API，代码都写得差不多了，结果客户突然变卦，说数据不能出境，要换成国内某厂商的模型。
这时候就体现出Spring AI多模型抽象的价值了。代码基本上就是改一下配置文件，核心逻辑完全不用动。
传统写法的痛点：
// 如果你直接封装OpenAI的API，换模型得重写publicclassOpenAIChatService{publicStringchat(Stringmessage){// 直接调用OpenAI的HTTP接口// 换成其他模型，整个类都得改}}Spring AI的解法：
@ServicepublicclassChatService{privatefinalChatClientchatClient;// 注意：构造器注入ChatClient.BuilderpublicChatService(ChatClient.Builderbuilder){this.chatClient=builder.build();}publicStringchat(StringuserMessage){// 业务逻辑完全不知道背后用的是哪个模型returnchatClient.prompt().user(userMessage).call().content();}}配置上简单得让人怀疑人生：
# 用OpenAIspring:ai:openai:api-key:${OPENAI_API_KEY}chat:options:model:gpt-4# 换成阿里云百炼，只改这几行spring:ai:dashscope:api-key:${DASHSCOPE_API_KEY}chat:options:model:qwen-max# 换成本地Ollama，只改这几行spring:ai:ollama:base-url:http://localhost:11434chat:options:model:qwen2.5:7b换模型的时候，改一下依赖和配置文件就行，核心代码一行不动。这种抽象的价值，只有你被供应商锁定坑过一次之后才能真正体会到。
案例二：Tool Calling + 结构化输出，让AI真正“干活”
老实说，单纯的聊天AI价值有限。真正让业务产生价值的是让AI能动手——查数据库、调用API、发邮件、创建工单。
Spring AI的Tool Calling机制让我觉得最舒服的地方是：它把工具的定义写成了最自然的Java方法。
场景：智能客服工单系统
假设你要实现一个客服系统，用户可以问“我上周买的那件外套能退吗”，系统需要：
- 判断用户是谁（查用户表）
- 查询最近的订单（查订单表）
- 判断退货策略（业务规则）
- 创建退货工单（写工单表）
用Spring AI实现：
@ComponentpublicclassCustomerServiceTools{@Tool(description="根据用户名或手机号查询用户信息")publicUserInfogetUser<