最近在不少技术群里都能看到类似的提问做 Java 的想往 AI 方向靠是不是必须转 Python不搞算法、不看论文后端开发还有没有出路我每次的回答都很直接——先别急着换语言你要先想明白自己说的“AI”到底是哪一个。这篇文章就是给“用 Java 吃饭”的开发者准备的一份 AI 入门路线图。我不会逼你去啃深度学习和数学公式而是从工程落地的角度把大模型应用开发这条路上的关键节点、Java 生态里的主力工具链、以及我自己踩过的坑逐一拆开。看完之后你至少能做出一件能跑、能演示、能写进简历的 AI 应用并且知道自己下一步该补什么。1. 先把话说透Java 做 AI 到底在做什么1.1 三种“AI 工作”先别搞混我见过太多人一听说 AI 就想到 TensorFlow、PyTorch、反向传播然后自己把自己劝退了。实际上在一个 AI 产品真正落地的过程里大致有三种性质完全不同的工作第一种是模型训练也就是调整神经网络内部的数亿个参数让它学会理解语言或者识别图像。这个方向需要比较扎实的数学基础、深度学习理论以及大量的 GPU 调参实验。Python 生态在这个领域确实垄断了PyTorch 的文档和社区资源最多你用 Java 硬闯进来基本是给自己找不痛快。业务后端开发者如果没有读博的打算不建议把主要精力押在这里。第二种是模型应用开发也就是把别人已经训练好的大模型当成一个黑盒服务通过 API 调用来实现聊天、摘要、分类、信息抽取、智能客服这些具体功能。这个方向的重点不在模型内部而在工程整合——怎么接入模型、怎么管理上下文、怎么让输出稳定、怎么做安全与限流。这才是 Java 开发者真正的主场。第三种是基础设施与工具链建设比如模型网关、Prompt 管理平台、向量数据库服务、模型评测系统。这类系统对并发、稳定性、可观测性的要求极高和传统后端架构大同小异JVM 技术栈完全可以在里面挑大梁。所以我的建议非常明确如果你是个业务后端想“入门 AI”目标应该是第二种最多再往第三种靠一靠。模型参数调整这种事交给算法团队和专业训练平台你负责的是把模型能力变成产品价值。1.2 Java 开发者手里的牌其实不差“Java 太老、太重不适合 AI”——这句话我听了无数遍但它是错的至少对“应用开发”这个方向是错的。大模型本身是无状态的 HTTP 服务真正考验你的是把它融进业务系统之后的事高并发下怎么保证响应速度调用失败怎么容错对话上下文怎么存敏感信息怎么过滤。这些东西恰恰是 Java 后端最擅长的。举个实际场景一个电商平台的 AI 导购助手。模型负责理解用户问题、生成推荐话术但用户的订单数据、商品库存、历史购买记录放在哪里肯定还是在你们自己的服务里。你写一个工具方法去查订单让模型在需要的时候调用它再把结果拼进回答——这就是典型的 Agent智能体开发而这里面的工程难点是 API 设计、鉴权、超时控制、数据一致性全是 Java 开发者的日常。另外JVM 生态的工具沉淀太厚了。Spring Boot 的自动装配、Micrometer 的监控指标、Sentinel 的限流熔断这些在接大模型时全是现成的。我一开始做 AI 功能时还担心要自己写一堆轮子后来发现 Spring 生态已经把这些整合得差不多了后面工具链章节我会细说。一句话总结AI 应用开发 模型能力 工程能力。模型能力靠调用现成服务获得工程能力你有而且已经练了十年。2. 入门路线图四个阶段按节奏走2.1 阶段一把大模型当成一个 HTTP 接口很多人一上来就去看各种偏底层的框架结果被抽象概念绕晕了。我的建议是第一阶段什么都别学先手动调一次接口。你要理解的核心事实是大模型和你日常调的 Redis、数据库没本质区别都是通过网络发请求、拿响应。随便打开一家国内模型服务商的开放平台注册之后拿到一个 API Key然后把一段拼接好的文本 POST 过去你会收到一段 JSON里面藏着模型生成的回答。这个过程里你要搞明白三件事请求头怎么带鉴权信息、请求体里的 messages 是什么结构、返回结果里的 content 字段在哪个位置。我让你先做这件事是因为它是后面所有框架的底层逻辑。Spring AI、LangChain4j 这些工具再怎么封装最终发出去的还是这样的 HTTP 请求。你亲手调通一次以后排查问题时就不会觉得那层封装是黑魔法。用 Java 调这个接口我建议直接上 JDK 11 以上自带的HttpClient或者 Spring 的RestClient。别急着引大框架先写一个最简单的main方法把“用户问一句模型答一句”跑通你就迈过门槛了。然后在这个基础上你可以自己加一个循环做成语料输入式的交互这就是你人生第一个 AI 程序。2.2 阶段二掌握提示词工程与上下文管理接口调通之后很快会遇到一个尴尬的问题模型回答得不像人话或者答非所问。这时候你该学的不是换个模型而是提示词工程。说白了就是学会怎么把问题说清楚。提示词的基本结构有三个部分系统提示词System Prompt告诉模型“你是什么角色、输出什么格式、遵循什么约束”历史对话History提供上下文背景用户问题User Message是当前的实际诉求。很多人只会写最后一部分模型拿不到角色设定和背景效果自然差。上下文是被绝大多数初学者忽略的坎。大模型有固定的上下文长度比如 32K、128K token超出部分会被直接截断。你不可能把一个 500 页的文档全塞进去。所以你要学会管理上下文长对话做滑动窗口只保留最近几轮再长就用摘要压缩如果知识是静态的应该用检索而不是硬塞。这些经验没有固定的公式靠的是对不同模型的性格把握。这一阶段还有一个必须练的指标Temperature温度。它控制模型输出的随机性越低越稳定越高越发散。做客服答案、信息抽取温度调到 0.2 左右做创意文案、头脑风暴温度可以拉到 0.8。这个参数非常影响效果建议你做一组对比实验感受一下差别。2.3 阶段三接上工具调用做出 Agent如果提示词是一张嘴工具调用就是给这张嘴装上手脚。模型本身不会主动查数据库、调外部接口但它可以在回答中提出“我需要调用某个工具”由你的程序去执行再把结果返回给它让它基于真实数据继续回答。这个功能的官方叫法是 Function Calling也有叫 Tool Use 的。实现起来其实不复杂你先定义几个带描述的方法比如queryOrder(String orderId)然后在发给模型的请求里带上这些方法的“说明书”。模型根据用户问题决定调用哪个方法、传什么参数你收到这个调用指令后自己执行把结果作为一条新消息再发给模型。Java 框架里这个能力已经被封装得很友好了Spring AI 里一个Tool注解就能把一个 Service 方法暴露给模型。当你的应用能“说话 动手”之后就是真正的 Agent 了——可以做客服助手、工单机器人、数据分析助手。这一步做完你的简历上就能写“大模型 Agent 应用开发”了。2.4 阶段四RAG 与私有知识库接入最后一个阶段是RAG检索增强生成。前面说上下文长度有限没法把海量资料塞进对话那如果模型需要回答的问题涉及公司内部文档、产品手册、历史工单怎么办RAG 的思路是先用 Embedding 模型把文档切成小块并转成向量用户提问时也在向量库中检索最相关的内容然后把检索结果拼进 Prompt让模型参考这些资料回答。这个阶段你会接触一堆新名词向量化、余弦相似度、Chunk 切分、召回率。别怕它们的含义用一句话就能解释清楚——把文字变成坐标找坐标相近的句子。Java 生态里有现成的向量库集成比如 Spring AI 的 VectorStore 抽象底层接 Redis 的向量检索、Milvus、Chroma 都可以。RAG 是业务后端最容易出成果的方向因为你们手里有别人没有的东西业务数据。模型通用知识再强也比不上你对自家系统的深入了解。把 RAG 做好AI 功能就不再是 Demo而是真正能服务业务的工具。3. 工具链梳理Java 生态的主力选手3.1 Spring AI与 Spring Boot 深度整合如果你本身就是 Spring Boot 用户第一个该看的就是Spring AI。它的目标很明确把 AI 能力做成 Spring 风格的 Starter让你像配置数据源一样配置模型像写 Controller 一样写 AI 接口。Spring AI 目前已经发布了 1.0.0 GA核心抽象包括ChatClient对话客户端、ChatModel模型接口、EmbeddingModel向量化模型、VectorStore向量存储和ToolCallback工具调用。你只需要在pom.xml里引入对应的模型厂商 starter然后在application.yml里配置好 API Key 和模型名代码里注入ChatClient.Builder就能开写。我特别推荐它的ChatClient链式 API风格很像 Spring WebFlux可读性非常高。比如要做一个带系统提示词的问答RestController public class AskController { private final ChatClient chatClient; public AskController(ChatClient.Builder builder) { this.chatClient builder.build(); } PostMapping(/ask) public String ask(RequestBody String question) { return chatClient.prompt() .system(你是一个经验丰富的技术客服回答要简洁、准确。) .user(question) .call() .content(); } }一个最小的 AI 接口就出来了。Spring AI 还屏蔽了各家模型服务的差异你换一家厂商只需要改配置代码基本不动。对于做多模型灾备或者对比评测的场景这个抽象很有价值。3.2 LangChain4j更贴近 LLM 社区习惯如果你看过 Python 的 LangChain 教程再看LangChain4j会有强烈的既视感。它的设计思路和 Python 版一脉相承强调 Chain 的概念——你可以把提示词、模型调用、输出解析组合成一条处理链。它同样支持主流模型服务商并且提供了很完整的 RAG 模块和 AI Service 接口。LangChain4j 和 Spring AI 怎么选我的经验是如果项目已经深度依赖 Spring Boot优先 Spring AI集成成本最低如果你想借鉴大量 Python 社区的案例和教程LangChain4j 的对应关系更强因为它的概念和 LangChain 几乎一一对应你搜到的很多思路都能平移过来。两个库现在都在快速迭代功能重叠度也很高。我不建议同时引入两套容易让团队维护起来很痛苦。选定一套深入用比来回切换高效得多。3.3 本地模型与向量库把依赖留在自己手里很多时候你不想把业务数据发给外部模型服务或者需要低延迟的私有化部署这时可以考虑本地模型方案。Ollama是我目前最常用的本地推理工具安装简单一条命令就能拉起模型并提供兼容标准协议的 HTTP 接口。# 安装完成后拉取一个 7B 左右的中文模型 ollama pull qwen2.5 ollama run qwen2.5本地跑 7B 模型一张消费级显卡就能有可用的推理速度没有 GPU 的话内存大一些的机器也能跑只是速度慢一点。Java 后端把地址指向http://localhost:11434代码层面的对接方式和云端模型完全一样。这对开发调试尤其有用——本地跑一套不烧 API 额度代码写好了再切云端。向量库的选择上业务量小可以用 Spring AI 内置的SimpleVectorStore内存存储重启数据丢失适合演示和测试。生产环境我建议用 Redis 自带的向量能力或者单独部署 Milvus。选型标准很朴素别为了一个刚上线的 AI 功能引一堆重组件先看复用现有基础设施能不能解决。3.4 辅助工具AI 编程助手与测试插件现在写 Java 代码不开个 AI 编程辅助工具效率确实差一截。国内可用的通义灵码、CodeGeeX这类插件装进 IDEA 后能补全代码、解释报错、生成测试用例甚至直接根据注释写方法体。我的体会是这些工具对写胶水代码、重复性样板代码帮助最大但对设计架构和排查复杂问题只能当个参考。站得再高一点现在面试后端岗位时AI 相关经验也越来越常被问起。哪怕公司主业务还没上 AI面试官也大概率会问“你对大模型应用有没有了解”“怎么在你的项目里引入 AI 能力”。所以提前练好这套工具链不只是为了做产品也是在市场环境里保持竞争力。4. 实操过程从零搭一个带记忆的 AI 客服接口4.1 环境准备与依赖配置理论说了这么多咱们直接上手。目标搭一个 Spring Boot 服务提供一个聊天接口支持多轮记忆和流式输出。先说环境JDK 17、Spring Boot 3.2 以上、Maven 3.8 以上再加一个可用的模型服务 API Key。以 Spring AI 为例pom.xml里最核心的依赖是这样dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-openai-spring-boot-starter/artifactId version1.0.0/version /dependency这里说的 spring-ai-openai 是对“OpenAI 兼容协议”的统一适配目前国内多数主流模型服务商都提供这类兼容接口因此你可以在application.yml里通过base-url指向任何一家兼容厂商再配上自己的 Key 和模型名spring: ai: openai: base-url: https://your-model-provider.example.com/v1 api-key: ${LLM_API_KEY} chat: options: model: qwen-plus temperature: 0.7请务必把 API Key 放到环境变量或者配置中心不要硬编码到代码里。我在团队 review 时看到过有人把 Key 直接写在application.yml里提交到代码仓库第二天就被供应商告警泄漏这个坑大家一定要躲开。4.2 核心代码多轮对话与流式输出为了让接口具备会话记忆我使用InMemoryChatMemory配合MessageChatMemoryAdvisor。它的作用是把每次请求的历史消息自动带上下文中你不用手动拼历史记录Configuration public class AiConfig { Bean ChatClient chatClient(ChatClient.Builder builder) { ChatMemory chatMemory new InMemoryChatMemory(); return builder .defaultSystem(你是一个耐心的技术支持助手回答不超过 200 字。) .defaultAdvisors(new MessageChatMemoryAdvisor(chatMemory)) .build(); } }控制器里写一个普通 POST 接口RestController RequestMapping(/ai) public class AiChatController { private final ChatClient chatClient; public AiChatController(ChatClient chatClient) { this.chatClient chatClient; } PostMapping(/chat) public String chat(RequestBody ChatRequest request) { return chatClient.prompt() .user(request.message()) .call() .content(); } }到这里一个带记忆的聊天接口就通了。注意InMemoryChatMemory是存 JVM 内存里的多实例部署时互相不共享。生产环境如果要做会话级记忆得把 ChatMemory 换成 Redis 实现或者自己根据会话 ID 管理消息列表。这是初学阶段最容易忽略的“单机 demo 没问题、一上集群就露馅”的问题。流式输出体验更好用户看到字一个一个蹦出来心理等待时间短很多。Spring AI 对 SSE 流式有原生支持接口返回改成FluxString即可PostMapping(value /chat/stream, produces text/event-stream) public FluxString chatStream(RequestBody ChatRequest request) { return chatClient.prompt() .user(request.message()) .stream() .content(); }前端用fetch配合ReadableStream或者直接用 Postman 都能看到效果。需要提醒的是用了响应式流式接口整个链路最好都用异步编程避免把线程池撑爆。4.3 关键技巧结构化输出聊业务时最烦的是一件事让模型返回 JSON它总爱在 JSON 外面包解释文字。比如你要抽取用户问题里的订单号和意图模型输出经常是“好的根据您的问题我整理如下{...}”前端一解析就炸。解决办法是让模型按结构化输出。Spring AI 里可以直接把返回内容绑定到 Java 类型上public record AnalysisResult(String intent, String orderId, Integer confidence) {} AnalysisResult result chatClient.prompt() .system(从用户输入中抽取意图和订单号。直接输出 JSON。) .user(request.message()) .call() .entity(AnalysisResult.class);这比自己在字符串里做正则抓 JSON 可靠得多。不过我建议在业务代码里仍然做一层兜底校验——模型不是数据库偶尔仍然会给出不合 schema 的结果捕获解析异常后返回“暂未识别”要比直接 500 好得多。4.4 接入工具调用让模型真正动起来最后一个实操点让模型调用你写的 Java 方法。假设你做客服系统用户问“我的订单寄到哪了”模型自己不知道数据但它能决定调用一个查询工具。你只需要定义一个带Tool注解的方法Component public class OrderTools { private final OrderRepository orderRepository; public OrderTools(OrderRepository orderRepository) { this.orderRepository orderRepository; } Tool(根据订单号查询最新物流状态) public String queryLogistics(String orderId) { return orderRepository.findLogisticsByOrderId(orderId) .orElse(未找到订单 orderId); } }然后把工具注册进ChatClientBean ChatClient chatClient(ChatClient.Builder builder, OrderTools orderTools) { return builder .defaultTools(orderTools) .build(); }Spring AI 会自动把方法名、参数、注释里的描述转换成模型的 Tool Schema并在模型要求调用时反射执行方法、把结果回传给模型。这个机制把“ Agent ”的门槛降得很低你只需要写普通 Service 方法加一个注解。整个过程中模型只描述“我要调用 queryLogistics参数是 20250101”真正的数据安全、权限校验还在你自己的方法里控制。5. 常见问题与排查技巧实录5.1 一次请求要 30 秒超时与重试大模型推理是慢操作云端模型在高峰期动辄十几秒才返回。传统接口的“2 秒超时重试”如果直接套用在 AI 接口上会把好好的服务打爆。我处理过的最典型线上事故就是网关层设了 5 秒超时模型 8 秒才返回网关直接断开客户端收到超时报错同时底层模型那头实际已经生成了结果——钱照样扣客户却没拿到答案。这类问题的标准解法是三板斧分辨是流式还是非流式流式接口把整体超时放宽非流式调用建议单独设置 30 到 60 秒的读取超时重试只对偶发的连接类错误生效不要对业务报错做无脑重试。另外生产环境一定要记录模型调用的耗时分布把 P95、P99 指标挂在监控面板上才能判断是模型侧抖动还是自己代码有问题。5.2 Token 超限与上下文管理“上下文长度超过限制”是第二大高频错误。表面原因是消息太长深层原因是开发者懒得管理历史。对话轮数一多所有历史全量发过去很快就把上下文窗口塞满。我的处理习惯是给每个会话设置消息条数上限超过 N 轮就把最早的消息折叠成摘要如果业务涉及大量固定知识用 RAG 检索替代全量塞入发送前估算 token 数常见的估算规则是中文每 1.5 到 2 个字占一个 token超限时要主动截断。另外模型厂商的计费也跟 token 挂钩省上下文不只是技术优化直接省真金白银。5.3 结构化输出不稳定即便用了entity()绑定也会遇到模型返回 JSON 里多了一个字段、少了一个字段、把布尔值写成字符串。我总结了三层保险先靠框架的 schema 约束再做一层 JSON 解析兜底解析失败就重试一次最后给解析失败的情况一个商品化的降级文案保证用户侧体验。模型输出天然有概率性工程上要接受“不是每次都能完美解析”提前设计兜底路径。5.4 关于“无限制”“免登录”的那类渠道写这一节是我真心想提醒新手网上经常能看到标榜“无禁词、免登录、无限聊”的站点和工具看着很诱人但我建议碰都别碰。这类服务大多环境不明、接口随时失效回答质量和数据安全完全不可控。你要是把业务数据发过去或者拿它训练正式系统等于把产品命运交给一个黑盒。正规模型厂商的开放平台都有足够的新用户免费额度学习阶段完全够用。合规这件事不只是为了稳妥更是为了保证你的代码和系统长时间不出事故。AI 应用做到后面数据安全、内容安全、可审计性才是真正拉开差距的地方。我做 AI 功能时还有一个习惯所有发给模型的请求和模型返回的原始响应都会打日志但不记录敏感字段。这让你在出问题时能回溯“用户到底问了什么、模型为什么这么答”这个习惯救过我很多次。6. 一些个人体会与后续扩展走完上面这条路你手里的东西就非常实在了会调模型接口、会写提示词、会做多轮对话、会接工具调用、能搭一套基础 RAG。这份能力放在任何一家有业务系统的公司里都能立刻转化为可演示、可评审、可上线的功能。我个人在实践中最深的体会是Java 开发者入门 AI真正的瓶颈从来不是“不会 Python”而是“不敢试”。总觉得自己在算法、数学上比不过科班出身的人就迟迟不动手。其实现在大模型应用开发的工程化程度已经非常高你调一个高质量模型的接口在多数场景下效果都优于自己从零训一个小模型。把现有系统里一个真实的痛点——比如客服、文档检索、报表解读——用 AI 重做一遍比看一百份教程都有用。最后分享一个小技巧把你的 AI 功能做出来之后顺手写一份“技术方案 效果对比”的文档记录你踩过的坑、调过的参数、选择这个框架而不是那个框架的理由。这份东西不仅是你自己下一次项目的参考也是团队评审、晋升汇报里最硬气的素材。技术路线图我会一直更新但工具和框架只是手段真正值钱的是你动手做出来的那个能解决问题的应用。
最近在不少技术群里都能看到类似的提问做 Java 的想往 AI 方向靠是不是必须转 Python不搞算法、不看论文后端开发还有没有出路我每次的回答都很直接——先别急着换语言你要先想明白自己说的“AI”到底是哪一个。这篇文章就是给“用 Java 吃饭”的开发者准备的一份 AI 入门路线图。我不会逼你去啃深度学习和数学公式而是从工程落地的角度把大模型应用开发这条路上的关键节点、Java 生态里的主力工具链、以及我自己踩过的坑逐一拆开。看完之后你至少能做出一件能跑、能演示、能写进简历的 AI 应用并且知道自己下一步该补什么。1. 先把话说透Java 做 AI 到底在做什么1.1 三种“AI 工作”先别搞混我见过太多人一听说 AI 就想到 TensorFlow、PyTorch、反向传播然后自己把自己劝退了。实际上在一个 AI 产品真正落地的过程里大致有三种性质完全不同的工作第一种是模型训练也就是调整神经网络内部的数亿个参数让它学会理解语言或者识别图像。这个方向需要比较扎实的数学基础、深度学习理论以及大量的 GPU 调参实验。Python 生态在这个领域确实垄断了PyTorch 的文档和社区资源最多你用 Java 硬闯进来基本是给自己找不痛快。业务后端开发者如果没有读博的打算不建议把主要精力押在这里。第二种是模型应用开发也就是把别人已经训练好的大模型当成一个黑盒服务通过 API 调用来实现聊天、摘要、分类、信息抽取、智能客服这些具体功能。这个方向的重点不在模型内部而在工程整合——怎么接入模型、怎么管理上下文、怎么让输出稳定、怎么做安全与限流。这才是 Java 开发者真正的主场。第三种是基础设施与工具链建设比如模型网关、Prompt 管理平台、向量数据库服务、模型评测系统。这类系统对并发、稳定性、可观测性的要求极高和传统后端架构大同小异JVM 技术栈完全可以在里面挑大梁。所以我的建议非常明确如果你是个业务后端想“入门 AI”目标应该是第二种最多再往第三种靠一靠。模型参数调整这种事交给算法团队和专业训练平台你负责的是把模型能力变成产品价值。1.2 Java 开发者手里的牌其实不差“Java 太老、太重不适合 AI”——这句话我听了无数遍但它是错的至少对“应用开发”这个方向是错的。大模型本身是无状态的 HTTP 服务真正考验你的是把它融进业务系统之后的事高并发下怎么保证响应速度调用失败怎么容错对话上下文怎么存敏感信息怎么过滤。这些东西恰恰是 Java 后端最擅长的。举个实际场景一个电商平台的 AI 导购助手。模型负责理解用户问题、生成推荐话术但用户的订单数据、商品库存、历史购买记录放在哪里肯定还是在你们自己的服务里。你写一个工具方法去查订单让模型在需要的时候调用它再把结果拼进回答——这就是典型的 Agent智能体开发而这里面的工程难点是 API 设计、鉴权、超时控制、数据一致性全是 Java 开发者的日常。另外JVM 生态的工具沉淀太厚了。Spring Boot 的自动装配、Micrometer 的监控指标、Sentinel 的限流熔断这些在接大模型时全是现成的。我一开始做 AI 功能时还担心要自己写一堆轮子后来发现 Spring 生态已经把这些整合得差不多了后面工具链章节我会细说。一句话总结AI 应用开发 模型能力 工程能力。模型能力靠调用现成服务获得工程能力你有而且已经练了十年。2. 入门路线图四个阶段按节奏走2.1 阶段一把大模型当成一个 HTTP 接口很多人一上来就去看各种偏底层的框架结果被抽象概念绕晕了。我的建议是第一阶段什么都别学先手动调一次接口。你要理解的核心事实是大模型和你日常调的 Redis、数据库没本质区别都是通过网络发请求、拿响应。随便打开一家国内模型服务商的开放平台注册之后拿到一个 API Key然后把一段拼接好的文本 POST 过去你会收到一段 JSON里面藏着模型生成的回答。这个过程里你要搞明白三件事请求头怎么带鉴权信息、请求体里的 messages 是什么结构、返回结果里的 content 字段在哪个位置。我让你先做这件事是因为它是后面所有框架的底层逻辑。Spring AI、LangChain4j 这些工具再怎么封装最终发出去的还是这样的 HTTP 请求。你亲手调通一次以后排查问题时就不会觉得那层封装是黑魔法。用 Java 调这个接口我建议直接上 JDK 11 以上自带的HttpClient或者 Spring 的RestClient。别急着引大框架先写一个最简单的main方法把“用户问一句模型答一句”跑通你就迈过门槛了。然后在这个基础上你可以自己加一个循环做成语料输入式的交互这就是你人生第一个 AI 程序。2.2 阶段二掌握提示词工程与上下文管理接口调通之后很快会遇到一个尴尬的问题模型回答得不像人话或者答非所问。这时候你该学的不是换个模型而是提示词工程。说白了就是学会怎么把问题说清楚。提示词的基本结构有三个部分系统提示词System Prompt告诉模型“你是什么角色、输出什么格式、遵循什么约束”历史对话History提供上下文背景用户问题User Message是当前的实际诉求。很多人只会写最后一部分模型拿不到角色设定和背景效果自然差。上下文是被绝大多数初学者忽略的坎。大模型有固定的上下文长度比如 32K、128K token超出部分会被直接截断。你不可能把一个 500 页的文档全塞进去。所以你要学会管理上下文长对话做滑动窗口只保留最近几轮再长就用摘要压缩如果知识是静态的应该用检索而不是硬塞。这些经验没有固定的公式靠的是对不同模型的性格把握。这一阶段还有一个必须练的指标Temperature温度。它控制模型输出的随机性越低越稳定越高越发散。做客服答案、信息抽取温度调到 0.2 左右做创意文案、头脑风暴温度可以拉到 0.8。这个参数非常影响效果建议你做一组对比实验感受一下差别。2.3 阶段三接上工具调用做出 Agent如果提示词是一张嘴工具调用就是给这张嘴装上手脚。模型本身不会主动查数据库、调外部接口但它可以在回答中提出“我需要调用某个工具”由你的程序去执行再把结果返回给它让它基于真实数据继续回答。这个功能的官方叫法是 Function Calling也有叫 Tool Use 的。实现起来其实不复杂你先定义几个带描述的方法比如queryOrder(String orderId)然后在发给模型的请求里带上这些方法的“说明书”。模型根据用户问题决定调用哪个方法、传什么参数你收到这个调用指令后自己执行把结果作为一条新消息再发给模型。Java 框架里这个能力已经被封装得很友好了Spring AI 里一个Tool注解就能把一个 Service 方法暴露给模型。当你的应用能“说话 动手”之后就是真正的 Agent 了——可以做客服助手、工单机器人、数据分析助手。这一步做完你的简历上就能写“大模型 Agent 应用开发”了。2.4 阶段四RAG 与私有知识库接入最后一个阶段是RAG检索增强生成。前面说上下文长度有限没法把海量资料塞进对话那如果模型需要回答的问题涉及公司内部文档、产品手册、历史工单怎么办RAG 的思路是先用 Embedding 模型把文档切成小块并转成向量用户提问时也在向量库中检索最相关的内容然后把检索结果拼进 Prompt让模型参考这些资料回答。这个阶段你会接触一堆新名词向量化、余弦相似度、Chunk 切分、召回率。别怕它们的含义用一句话就能解释清楚——把文字变成坐标找坐标相近的句子。Java 生态里有现成的向量库集成比如 Spring AI 的 VectorStore 抽象底层接 Redis 的向量检索、Milvus、Chroma 都可以。RAG 是业务后端最容易出成果的方向因为你们手里有别人没有的东西业务数据。模型通用知识再强也比不上你对自家系统的深入了解。把 RAG 做好AI 功能就不再是 Demo而是真正能服务业务的工具。3. 工具链梳理Java 生态的主力选手3.1 Spring AI与 Spring Boot 深度整合如果你本身就是 Spring Boot 用户第一个该看的就是Spring AI。它的目标很明确把 AI 能力做成 Spring 风格的 Starter让你像配置数据源一样配置模型像写 Controller 一样写 AI 接口。Spring AI 目前已经发布了 1.0.0 GA核心抽象包括ChatClient对话客户端、ChatModel模型接口、EmbeddingModel向量化模型、VectorStore向量存储和ToolCallback工具调用。你只需要在pom.xml里引入对应的模型厂商 starter然后在application.yml里配置好 API Key 和模型名代码里注入ChatClient.Builder就能开写。我特别推荐它的ChatClient链式 API风格很像 Spring WebFlux可读性非常高。比如要做一个带系统提示词的问答RestController public class AskController { private final ChatClient chatClient; public AskController(ChatClient.Builder builder) { this.chatClient builder.build(); } PostMapping(/ask) public String ask(RequestBody String question) { return chatClient.prompt() .system(你是一个经验丰富的技术客服回答要简洁、准确。) .user(question) .call() .content(); } }一个最小的 AI 接口就出来了。Spring AI 还屏蔽了各家模型服务的差异你换一家厂商只需要改配置代码基本不动。对于做多模型灾备或者对比评测的场景这个抽象很有价值。3.2 LangChain4j更贴近 LLM 社区习惯如果你看过 Python 的 LangChain 教程再看LangChain4j会有强烈的既视感。它的设计思路和 Python 版一脉相承强调 Chain 的概念——你可以把提示词、模型调用、输出解析组合成一条处理链。它同样支持主流模型服务商并且提供了很完整的 RAG 模块和 AI Service 接口。LangChain4j 和 Spring AI 怎么选我的经验是如果项目已经深度依赖 Spring Boot优先 Spring AI集成成本最低如果你想借鉴大量 Python 社区的案例和教程LangChain4j 的对应关系更强因为它的概念和 LangChain 几乎一一对应你搜到的很多思路都能平移过来。两个库现在都在快速迭代功能重叠度也很高。我不建议同时引入两套容易让团队维护起来很痛苦。选定一套深入用比来回切换高效得多。3.3 本地模型与向量库把依赖留在自己手里很多时候你不想把业务数据发给外部模型服务或者需要低延迟的私有化部署这时可以考虑本地模型方案。Ollama是我目前最常用的本地推理工具安装简单一条命令就能拉起模型并提供兼容标准协议的 HTTP 接口。# 安装完成后拉取一个 7B 左右的中文模型 ollama pull qwen2.5 ollama run qwen2.5本地跑 7B 模型一张消费级显卡就能有可用的推理速度没有 GPU 的话内存大一些的机器也能跑只是速度慢一点。Java 后端把地址指向http://localhost:11434代码层面的对接方式和云端模型完全一样。这对开发调试尤其有用——本地跑一套不烧 API 额度代码写好了再切云端。向量库的选择上业务量小可以用 Spring AI 内置的SimpleVectorStore内存存储重启数据丢失适合演示和测试。生产环境我建议用 Redis 自带的向量能力或者单独部署 Milvus。选型标准很朴素别为了一个刚上线的 AI 功能引一堆重组件先看复用现有基础设施能不能解决。3.4 辅助工具AI 编程助手与测试插件现在写 Java 代码不开个 AI 编程辅助工具效率确实差一截。国内可用的通义灵码、CodeGeeX这类插件装进 IDEA 后能补全代码、解释报错、生成测试用例甚至直接根据注释写方法体。我的体会是这些工具对写胶水代码、重复性样板代码帮助最大但对设计架构和排查复杂问题只能当个参考。站得再高一点现在面试后端岗位时AI 相关经验也越来越常被问起。哪怕公司主业务还没上 AI面试官也大概率会问“你对大模型应用有没有了解”“怎么在你的项目里引入 AI 能力”。所以提前练好这套工具链不只是为了做产品也是在市场环境里保持竞争力。4. 实操过程从零搭一个带记忆的 AI 客服接口4.1 环境准备与依赖配置理论说了这么多咱们直接上手。目标搭一个 Spring Boot 服务提供一个聊天接口支持多轮记忆和流式输出。先说环境JDK 17、Spring Boot 3.2 以上、Maven 3.8 以上再加一个可用的模型服务 API Key。以 Spring AI 为例pom.xml里最核心的依赖是这样dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-openai-spring-boot-starter/artifactId version1.0.0/version /dependency这里说的 spring-ai-openai 是对“OpenAI 兼容协议”的统一适配目前国内多数主流模型服务商都提供这类兼容接口因此你可以在application.yml里通过base-url指向任何一家兼容厂商再配上自己的 Key 和模型名spring: ai: openai: base-url: https://your-model-provider.example.com/v1 api-key: ${LLM_API_KEY} chat: options: model: qwen-plus temperature: 0.7请务必把 API Key 放到环境变量或者配置中心不要硬编码到代码里。我在团队 review 时看到过有人把 Key 直接写在application.yml里提交到代码仓库第二天就被供应商告警泄漏这个坑大家一定要躲开。4.2 核心代码多轮对话与流式输出为了让接口具备会话记忆我使用InMemoryChatMemory配合MessageChatMemoryAdvisor。它的作用是把每次请求的历史消息自动带上下文中你不用手动拼历史记录Configuration public class AiConfig { Bean ChatClient chatClient(ChatClient.Builder builder) { ChatMemory chatMemory new InMemoryChatMemory(); return builder .defaultSystem(你是一个耐心的技术支持助手回答不超过 200 字。) .defaultAdvisors(new MessageChatMemoryAdvisor(chatMemory)) .build(); } }控制器里写一个普通 POST 接口RestController RequestMapping(/ai) public class AiChatController { private final ChatClient chatClient; public AiChatController(ChatClient chatClient) { this.chatClient chatClient; } PostMapping(/chat) public String chat(RequestBody ChatRequest request) { return chatClient.prompt() .user(request.message()) .call() .content(); } }到这里一个带记忆的聊天接口就通了。注意InMemoryChatMemory是存 JVM 内存里的多实例部署时互相不共享。生产环境如果要做会话级记忆得把 ChatMemory 换成 Redis 实现或者自己根据会话 ID 管理消息列表。这是初学阶段最容易忽略的“单机 demo 没问题、一上集群就露馅”的问题。流式输出体验更好用户看到字一个一个蹦出来心理等待时间短很多。Spring AI 对 SSE 流式有原生支持接口返回改成FluxString即可PostMapping(value /chat/stream, produces text/event-stream) public FluxString chatStream(RequestBody ChatRequest request) { return chatClient.prompt() .user(request.message()) .stream() .content(); }前端用fetch配合ReadableStream或者直接用 Postman 都能看到效果。需要提醒的是用了响应式流式接口整个链路最好都用异步编程避免把线程池撑爆。4.3 关键技巧结构化输出聊业务时最烦的是一件事让模型返回 JSON它总爱在 JSON 外面包解释文字。比如你要抽取用户问题里的订单号和意图模型输出经常是“好的根据您的问题我整理如下{...}”前端一解析就炸。解决办法是让模型按结构化输出。Spring AI 里可以直接把返回内容绑定到 Java 类型上public record AnalysisResult(String intent, String orderId, Integer confidence) {} AnalysisResult result chatClient.prompt() .system(从用户输入中抽取意图和订单号。直接输出 JSON。) .user(request.message()) .call() .entity(AnalysisResult.class);这比自己在字符串里做正则抓 JSON 可靠得多。不过我建议在业务代码里仍然做一层兜底校验——模型不是数据库偶尔仍然会给出不合 schema 的结果捕获解析异常后返回“暂未识别”要比直接 500 好得多。4.4 接入工具调用让模型真正动起来最后一个实操点让模型调用你写的 Java 方法。假设你做客服系统用户问“我的订单寄到哪了”模型自己不知道数据但它能决定调用一个查询工具。你只需要定义一个带Tool注解的方法Component public class OrderTools { private final OrderRepository orderRepository; public OrderTools(OrderRepository orderRepository) { this.orderRepository orderRepository; } Tool(根据订单号查询最新物流状态) public String queryLogistics(String orderId) { return orderRepository.findLogisticsByOrderId(orderId) .orElse(未找到订单 orderId); } }然后把工具注册进ChatClientBean ChatClient chatClient(ChatClient.Builder builder, OrderTools orderTools) { return builder .defaultTools(orderTools) .build(); }Spring AI 会自动把方法名、参数、注释里的描述转换成模型的 Tool Schema并在模型要求调用时反射执行方法、把结果回传给模型。这个机制把“ Agent ”的门槛降得很低你只需要写普通 Service 方法加一个注解。整个过程中模型只描述“我要调用 queryLogistics参数是 20250101”真正的数据安全、权限校验还在你自己的方法里控制。5. 常见问题与排查技巧实录5.1 一次请求要 30 秒超时与重试大模型推理是慢操作云端模型在高峰期动辄十几秒才返回。传统接口的“2 秒超时重试”如果直接套用在 AI 接口上会把好好的服务打爆。我处理过的最典型线上事故就是网关层设了 5 秒超时模型 8 秒才返回网关直接断开客户端收到超时报错同时底层模型那头实际已经生成了结果——钱照样扣客户却没拿到答案。这类问题的标准解法是三板斧分辨是流式还是非流式流式接口把整体超时放宽非流式调用建议单独设置 30 到 60 秒的读取超时重试只对偶发的连接类错误生效不要对业务报错做无脑重试。另外生产环境一定要记录模型调用的耗时分布把 P95、P99 指标挂在监控面板上才能判断是模型侧抖动还是自己代码有问题。5.2 Token 超限与上下文管理“上下文长度超过限制”是第二大高频错误。表面原因是消息太长深层原因是开发者懒得管理历史。对话轮数一多所有历史全量发过去很快就把上下文窗口塞满。我的处理习惯是给每个会话设置消息条数上限超过 N 轮就把最早的消息折叠成摘要如果业务涉及大量固定知识用 RAG 检索替代全量塞入发送前估算 token 数常见的估算规则是中文每 1.5 到 2 个字占一个 token超限时要主动截断。另外模型厂商的计费也跟 token 挂钩省上下文不只是技术优化直接省真金白银。5.3 结构化输出不稳定即便用了entity()绑定也会遇到模型返回 JSON 里多了一个字段、少了一个字段、把布尔值写成字符串。我总结了三层保险先靠框架的 schema 约束再做一层 JSON 解析兜底解析失败就重试一次最后给解析失败的情况一个商品化的降级文案保证用户侧体验。模型输出天然有概率性工程上要接受“不是每次都能完美解析”提前设计兜底路径。5.4 关于“无限制”“免登录”的那类渠道写这一节是我真心想提醒新手网上经常能看到标榜“无禁词、免登录、无限聊”的站点和工具看着很诱人但我建议碰都别碰。这类服务大多环境不明、接口随时失效回答质量和数据安全完全不可控。你要是把业务数据发过去或者拿它训练正式系统等于把产品命运交给一个黑盒。正规模型厂商的开放平台都有足够的新用户免费额度学习阶段完全够用。合规这件事不只是为了稳妥更是为了保证你的代码和系统长时间不出事故。AI 应用做到后面数据安全、内容安全、可审计性才是真正拉开差距的地方。我做 AI 功能时还有一个习惯所有发给模型的请求和模型返回的原始响应都会打日志但不记录敏感字段。这让你在出问题时能回溯“用户到底问了什么、模型为什么这么答”这个习惯救过我很多次。6. 一些个人体会与后续扩展走完上面这条路你手里的东西就非常实在了会调模型接口、会写提示词、会做多轮对话、会接工具调用、能搭一套基础 RAG。这份能力放在任何一家有业务系统的公司里都能立刻转化为可演示、可评审、可上线的功能。我个人在实践中最深的体会是Java 开发者入门 AI真正的瓶颈从来不是“不会 Python”而是“不敢试”。总觉得自己在算法、数学上比不过科班出身的人就迟迟不动手。其实现在大模型应用开发的工程化程度已经非常高你调一个高质量模型的接口在多数场景下效果都优于自己从零训一个小模型。把现有系统里一个真实的痛点——比如客服、文档检索、报表解读——用 AI 重做一遍比看一百份教程都有用。最后分享一个小技巧把你的 AI 功能做出来之后顺手写一份“技术方案 效果对比”的文档记录你踩过的坑、调过的参数、选择这个框架而不是那个框架的理由。这份东西不仅是你自己下一次项目的参考也是团队评审、晋升汇报里最硬气的素材。技术路线图我会一直更新但工具和框架只是手段真正值钱的是你动手做出来的那个能解决问题的应用。
