我一直觉得Java 开发者和 AI 之间最大的距离不是技术栈是心理上的距离。前阵子有个工作三年的同事找我聊他 JDK 21、Spring Boot 3 玩得挺溜Redis、消息队列、微服务都实战过结果刷了几篇 AI 教程第一页就在讲 Python 的 NumPy、PyTorch直接给整不会了跑来问我“是不是得先转语言才能搞 AI”。我的回答很简单不用。 Java 在 AI 时代不是没有位置反而位置相当稳。只是过去几年互联网上关于“AI 编程”的讨论几乎全被 Python 开发者占领了导致很多 Java 工程师产生了错觉觉得自己被 AI 浪潮甩下了。实际上你去看真正落地的 AI 产品接业务系统的部分一大半还是 Java 写的——模型推理服务后面挂的订单查询、用户画像、权限控制、数据同步这些都是 Java 的主场。这篇文章就是给还在观望的 Java 工程师划一条实在的路线从最省力的入口切入 AI把工具链摸一遍知道哪些东西能用 Java 直接调、哪些东西需要绕路、哪些地方最容易踩坑。适合已经在用 Java 写业务、对 AI 感兴趣但没有系统入门思路的人。我不会劝你放弃 Java 去学 Python我只会告诉你怎么让 Java 成为你在 AI 时代的优势而不是包袱。1. 先想清楚Java 工程师学 AI到底是在学什么1.1 三个层次你属于哪一层很多人一上来就搞混了方向觉得“学 AI”就是学机器学习、学深度学习、学神经网络。这个误区害人很深。我习惯把 Java 工程师接触 AI 的场景分成三个层次你先认清自己需要哪个层次。用 AI不关心模型怎么训练的只关心怎么把大模型的接口接到自己的业务系统里。比如做一个智能客服、做一个文档摘要工具、做一个内容分类服务。这个层次的技术重心在 HTTP 调用、接口协议、参数调优、结果解析全是 Java 的强项。调 AI不仅会用还要让模型输出的结果更符合业务预期。你可能会接触 Prompt 工程、RAG检索增强生成、微调。这个层次开始有一点 AI 的味道了但不需要自己从零训练模型。造 AI自己训练模型、优化网络结构、研究新的算法。这个层次才需要啃 Python、PyTorch、CUDA 那些东西。1.2 Java 工程师的生态位不是 AI 的创造者是 AI 的连接者绝大多数 Java 工程师应该瞄准的是前两个层次尤其第二个层次“调 AI”这是目前市场上最缺人的位置。你看那些折腾 AI 到半夜的团队最后瓶颈往往不在模型本身而在模型怎么跟现有系统无缝衔接——大模型输出的 JSON 怎么落到数据库里、调用失败怎么重试、多用户并发调用怎么限流、提示词里怎么动态拼上业务数据。这些活儿Java 工程师做起来是降维打击。拿厨师行业打个比方Python 工程师更像是研究新菜谱的研发厨师而 Java 工程师更像是把菜品标准化、规模化生产出来的中央厨房。一个 AI 应用要真正服务成千上万用户不能靠科学家在 Jupyter Notebook 里慢慢调参得有可靠的工程系统把它包起来。这个“包起来”的过程就是 Java 的领地。1.3 心态纠偏Python 不是必经之路很多教程告诉你“学 AI 必须会 Python”我要明确说这是针对“造 AI”的人说的不是针对“用 AI”的人说的。你要做的事情是把现成的 AI 能力当成一个外部服务来调用就跟调用支付宝支付、调用阿里云 OSS 一样。支付 SDK 有 Java 版本OSS SDK 有 Java 版本大模型 API 当然也有 Java 能用的方式——哪怕官方 SDK 不给 Java用原生的 HTTP 客户端也能接后面我会讲怎么实现。我见过太多 Java 工程师花了三个月学 Python 语法又花两个月学 NumPy、Pandas最后发现工作里还是写 Java 业务AI 也没摸到边。这属于典型的路径错误。正确的做法是先在你最熟悉的 Java 体系里把 AI 应用跑起来跑通了之后如果真的对底层算法感兴趣再回头补 Python 也不迟。那时候你会发现Python 的语法花不了多少时间因为你已经知道 AI 的工程全貌了。2. 知识衔接补哪些数学、换哪种思维、保哪些优势2.1 数学只需要一个最小集合别被吓跑我理解 Java 工程师看到“高数、线性代数、概率论”就头皮发麻。实话说如果你只做应用层需要补的数学知识非常有限我把这个集合叫做“AI 应用最小数学包”。向量与矩阵你至少要知道什么是向量、什么是向量的点积。因为大模型处理文本的时候会把文字转换成几百上千维的向量两个文本“像不像”就看向量的余弦相似度高不高。你在做 RAG 的时候会频繁接触这个概念。这不需要你手推公式理解几何意义就行——两个向量的夹角越小就越相似。概率的基本直觉知道模型输出是概率分布知道“置信度”是什么意思。例如模型生成一段话时每个 token 都是按概率采样出来的所以同一个问题问两次答案可能不完全一样。理解了这点你就知道为什么 AI 调用不能完全用“输入输出一致的确定性系统”那套思维去考量。梯度下降了解“模型是靠反复调整参数让误差越来越小”这个思想就够了。应用层的你不需要自己实现梯度下降但微调模型时你会用到这个概念最少最少要知道它在干嘛。如果你连向量都不懂也别慌。我始终建议先跑通再补课先把一个 AI 功能在你的 Spring Boot 项目里跑起来碰到“向量相似度”这个概念了花半小时搞清楚再继续。带着问题去学效率高得多。2.2 换思维从“精确匹配”到“概率生成”Java 工程师写业务天然追求确定性一个方法传参进去预期结果就是那个值单元测试里断言写得好好的。AI 不一样它是概率系统同一个 Prompt 可能返回不同结果同一个问题换个说法可能回答质量差一大截。这个思维转换是我觉得 Java 工程师学 AI 最大的坎。举个例子你给用户做一个“合同关键信息提取”功能传统做法是写好正则表达式去匹配甲方、乙方、金额。现在用大模型你把合同文本扔给它让它按要求输出 JSON。你会发现两件事一格式偶尔会乱可能漏个字段也可能多输出一段废话二就算格式对了提取出来的金额偶尔也会错。这时候你不能用“if else”思维去修得用校验 重试 规则兜底的组合拳。比如先让模型输出 JSON你用 Jackson 解析解析失败就带上错误信息再问一次模型让它自己修正。这种“概率系统 确定性校验”的模式是 Java 工程师做 AI 应用最核心的套路。2.3 Java 技能里最值钱的三样东西别扔掉学 AI 的过程中别把 Java 的基本功丢了。我反而觉得以下三样东西是你区别于纯 AI 从业者的护城河。Spring 生态Spring Boot 的自动配置、依赖注入、AOP能帮你把 AI 客户端封装得非常优雅。尤其是 Spring AI 出现之后后面详细讲把大模型客户端做成了 Spring 风格对 Java 开发者来说亲和力拉满。并发与性能调优AI 接口的调用往往有网络延迟一个请求可能几百毫秒甚至几秒。高并发场景下你如何管理线程池、如何做超时熔断、如何保证不把下游模型服务打爆这些都是 Java 工程师的拿手好戏。数据管道思维传统 Java 开发者天天跟数据库、MQ、ETL 打交道这种对数据流转的敏感度在做 RAG 的知识库构建时特别重要数据从哪来、怎么清洗、怎么切片、怎么存向量库、怎么更新索引完全是一套工程体系。3. 路线图拆解从最省力的入口一路走到能落地先给一个总览我推荐的 Java 工程师 AI 入门路线分五个阶段每个阶段都有明确的产出物不是纯理论学习。阶段核心任务产出物主要工具一调用大模型 API能跑通的聊天接口Java HttpClient / OpenAI 兼容接口二Prompt 工程与结构化输出能把模型输出稳定解析成 JSONJackson / Spring AI三RAG 知识库问答能基于自己的文档回答问题向量数据库 LangChain4j / Spring AI四Agent 与工具调用模型能主动调用你的 Java 服务Function Calling五本地模型部署与微调不依赖外部 API 的私有化推理DJL / ONNX Runtime3.1 阶段一直接调用大模型 API先跑通一个链路这是最没有心理负担的入口。现在主流通用大模型基本都提供了 OpenAI 兼容的 HTTP 接口你不需要任何 Python 环境用 Java 原生HttpClient就能调。我建议第一件事用任何一个主流的模型服务商申请一个 API Key然后用下面这种最简单的方式发出你的第一次请求HttpClient client HttpClient.newHttpClient(); String requestBody { model: gpt-4o-mini, messages: [ {role: user, content: 用一句话解释什么是 RAG} ] } ; HttpRequest request HttpRequest.newBuilder() .uri(URI.create(https://api.openai.com/v1/chat/completions)) .header(Content-Type, application/json) .header(Authorization, Bearer YOUR_API_KEY) .POST(HttpRequest.BodyPublishers.ofString(requestBody)) .build(); HttpResponseString response client.send(request, HttpResponse.BodyHandlers.ofString()); System.out.println(response.body());第一次看到模型返回结果的时候你对 AI 的神秘感就会消失大半这不就是个远程 HTTP 服务嘛。这个阶段的关键收获是把大模型当成一个黑盒服务来用跟调用任何第三方接口没有本质区别。你不必关心 tokenizer 是怎么切的、注意力机制是怎么算的那些以后再说。3.2 阶段二Prompt 工程与结构化输出跑通接口之后你马上会碰到第一个实际问题模型返回的结果没法直接对接你的业务代码。你在 Java 里定义了一个ContractInfo类里面是partyA、partyB、amount模型默认返回的是一大段自然语言你怎么映射办法是让模型输出 JSON并且规定字段。这就要用到 Prompt 工程的最基本技巧你是一个合同信息提取助手。请从用户提供的合同中提取以下信息并严格按照 JSON 格式返回 {partyA: 甲方名称, partyB: 乙方名称, amount: 合同金额数字} 注意只输出 JSON不要输出任何解释。然后在 Java 侧用 Jackson 解析解析失败就异常重试。这一步开始你已经在“调 AI”了。我特别想强调结构化输出是 Java 工程师最容易上手、也最有成就感的 AI 应用切入点。因为你天然懂 JSON、懂类型、懂序列化。很多 Python 从业者反而不太在意输出 Schema 设计这正好是你的优势。3.3 阶段三RAG——让 AI 学会读你的文档光靠通用大模型回答不了你公司内部的业务问题因为它没学过你家系统的用户手册。RAG 是当下最实用的解决方案把文档提前切碎、转成向量存起来用户提问时先检索出相关内容片段再把这些片段连同问题一起丢给大模型让它基于这些资料回答。Java 工程师做 RAG 有天然优势因为你原本就熟悉数据的存储和处理流程。你只需要理解一个新的存储概念——向量数据库。为了让流程跑通建议用 Spring AI 来做代码量会小很多我在第六章会给出具体例子。3.4 阶段四Agent 与工具调用当模型不仅要“回答问题”还要“完成任务”时就进入了 Agent 阶段。比如用户说“帮我查一下订单 A1001 的物流状态”模型本身没有查询你数据库的能力但通过函数调用Function Calling你可以给模型注册一个工具告诉它“有一个queryLogisticsOrder方法参数是订单号”。模型理解用户意图后会生成一个特定的函数调用请求你在 Java 侧执行这个函数把结果再交回给模型让模型组织语言回复用户。这个阶段是 Java 工程师最容易出彩的地方。因为工具本身的实现——查询数据库、调用其他微服务、发消息通知——都是你的日常你只需要在模型和工具之间做一个翻译层。LangChain4j 对 Function Calling 的封装做得相当好后面我会细说。3.5 阶段五可选本地模型部署与微调如果你的项目有数据安全要求所有数据不能出内网那就得考虑私有化部署模型。这一阶段开始脱离“API 调用”的舒适区你需要接触真正的模型推理。Java 侧有两套方案值得关注。一是DJLDeep Java LibraryAWS 出品的 Java 深度学习框架支持加载 PyTorch、TensorFlow 和 ONNX 格式的模型。二是ONNX Runtime 的 Java APIONNX 作为一种中间格式很多开源模型都能转成它再用 Java 加载推理。这个阶段不再建议纯用 Spring而是要开始理解张量、输入输出维度、GPU 显存这些概念难度明显上升但对深度做 AI 的 Java 团队来说值得攻克。4. Java 生态的 AI 工具链盘点哪些能直接用哪些要绕路很多 Java 开发者迟迟没动手是觉得“Java 没有 AI 生态”。这句话在“造 AI”层面成立但在“用 AI、调 AI”层面已经过时了。近两年变化非常大我把 Java 侧能用的主力工具盘点一遍。4.1 四个主力选手工具 / 框架定位适合场景上手难度Spring AISpring 官方的 AI 应用框架已有 Spring Boot 项目的团队想把 AI 能力集成进现有微服务体系低Spring 风格LangChain4jLangChain 的 Java 移植版需要灵活编排 Prompt、Agent、RAG 流程中DJLAWS 维护的深度学习推理库加载本地模型做推理支持 PyTorch/ONNX 格式中高ONNX Runtime Java API微软 ONNX Runtime 的 Java 绑定高性能推理与平台无关的模型部署中高先说Spring AI。这是我最推荐的起点。它在 2025 年发布了 1.0 正式版API 已趋于稳定。它支持 OpenAI、通义千问、智谱 GLM、Ollama 等多种模型提供商而且抽象出了一套统一的ChatClient接口。具体好处是你写业务代码时不用关心底层是接的哪家模型换个模型商只需要改配置代码几乎不用动。而且它原生支持结构化输出——你可以定义 Java record让 AI 的输出直接映射进去这个对 Java 开发者太友好了。再看LangChain4j。如果你在主项目里不方便引入 Spring AI比如不是 Spring Boot 项目或者你需要更细粒度的控制——比如手动管理 Prompt 模板、复杂的多轮工具调用LangChain4j 是更好的选择。它基本把 LangChain 的核心概念都搬到了 Java 世界ChatLanguageModel、EmbeddingModel、ContentRetriever、AiServices。它对 Function Calling 的封装做得尤其成熟你只需要写普通的 Java 方法加上Tool注解模型就能自动调用它。DJL和ONNX Runtime属于进阶工具做私有化部署时才用得上。DJL 的优势是纯 Java 实现模型推理支持在 CPU/GPU 上运行且对 Maven 依赖友好ONNX Runtime 则胜在模型格式通用性能优化做得好。4.2 选型建议怎么挑不纠结我的建议很简单如果团队技术栈是 Spring Boot直接用Spring AI它和 Spring 的配置体系、错误处理、线程池管理天然集成。如果项目是非 Spring 的 Java 后端或者你特别在意流程编排的灵活性用LangChain4j。两者怎么选我个人的经验是做产品原型用 Spring AI做复杂 Agent 编排用 LangChain4j。当然两个都装也能跑但不建议在同一个服务里混用容易出现依赖冲突后面会细说。补充一个点如果你只是想让老 Java 项目快速跑通一个 AI 功能其实连框架都不用上直接非阻塞 HTTP 客户端调 API 就行。框架的价值在于标准化、可维护、可扩展但如果项目生命周期短、就一个临时工具别过度设计。4.3 别忘了配套设施向量库和可观测性做 RAG 离不开向量数据库。Java 生态里我实际用过的几个方案Redis Stack如果你的团队已经在用 Redis启用 Search and Query 模块就能存向量集成成本极低适合中小规模知识库。Milvus专业的向量数据库支持高并发、大规模向量检索。Java SDK 写得很完善。Elasticsearch 8.x老牌搜索引擎自带密集向量检索能力Java 客户端顺手适合已有 ES 的技术栈。可观测性也好提一嘴。AI 接口是外部依赖你要像监控数据库一样监控它的调用量、延迟、报错率、Token 消耗。我用过比较实用的方案是给RestClient加拦截器把每次调用的模型、输入字符数、耗时打到日志里再接到监控系统。别觉得这是小事AI 接口出问题的时候没有日志你根本无从排查。5. 我在 Java AI 实践中踩过的坑这一部分我单独拉出来讲因为这些坑几乎每个 Java 工程师都会碰到而且网上专门讲 Java 侧踩坑的资料少。我按时间线复盘一下我自己的经历。5.1 坑一被 Python 生态的“优越感”带着跑偏我最初想搞 AI 的时候也踩过这个。当时跟着一位算法同事学了两个周末的 Python还装了一堆数据分析包。学了差不多一个月我发现自己根本用不上这些技能——我在 Java 里调一个 HTTP 就能完成的事情绕了一大圈反而复杂了。教训是你的项目需要什么你就学什么。如果你的目标是把 AI 能力接进 Java 服务那就直接从 Java 侧入手。如果你真想读模型源码、做算法训练那再去碰 Python。很多人在第一步就被吓退其实是把“辅助技能”当成了“必要技能”。5.2 坑二Token 数估算不准被账单吓了一跳Java 侧没有像 Python 那样统一的 tiktoken 库各个模型的 tokenizer 也不一样。我早期在生成 Prompt 时没有估算长度直接把大段日志文本塞进去结果一个月下来模型调用费用远超预期。后来用了jtokkit这个 Java 库它是 OpenAI tiktoken 的 Java 移植版可以比较准确地统计一段文本的 token 数量。虽然它只适配 OpenAI 系的 tokenizer但大部分兼容 OpenAI 协议的模型用它估算误差已经可以接受。我现在写调用逻辑时有个习惯构造 Prompt 之后先估算一下 token超预算就做截断或者换更高效的 Prompt 模板。5.3 坑三超时、重试、熔断AI 调用不是数据库查询我第一次把 AI 调用接入生产系统只做了简单的超时设置结果遭遇模型服务端偶发变慢线程池被长时间占满整个服务的响应时间都上去了。后来老老实实补了配置spring: ai: openai: timeout: connect: 10s read: 60s retry: max-attempts: 3 backoff: multiplier: 2经验是AI 接口的响应时间远高于普通 HTTP 接口最坏情况可能几十秒所以一定要用独立的线程池或者异步调用不能阻塞业务主线程另一头要做熔断当模型服务连续失败达到阈值要快速降级返回兜底文案不要无限重试雪上加霜。好在 Spring AI 现在已经支持把调用逻辑纳入常见的熔断框架但再不济也要自己控制好重试次数。5.4 坑四Spring AI 与 LangChain4j 的依赖冲突我一激动在同一个模块里同时引入了 Spring AI 和 LangChain4j想着哪个好用用哪个。结果启动时直接报错两个框架都各自带了一套对模型服务的封装底层类名冲突类加载阶段就开始打架。折腾了半天最后二选一项目里只保留 Spring AI问题消失。这个教训写在明面上在一个 Java 服务里AI 框架尽量只选一个。它们定位同质化严重同时引入的复杂度远大于收益。如果你确实有不同需求用不同的微服务分别承载而不是堆在同一个进程里。5.5 坑五模型输出不能全信要做校验兜底有一次做合同解析模型返回的 JSON 里甲方字段值是null按正常逻辑应该重新调用一次或者标记人工核查结果我的代码没有做字段非空校验直接把null存进了数据库。后来线上用户看到合同信息缺甲方排查才发现是模型输出不稳定。所以我在所有 AI 输出接入业务系统的边界上都加了一层验证器。自定义一个接口专门检查模型输出的 JSON 是否包含所有必需字段、字段类型是否符合预期、数值是否在合理范围内。不通过就自动重试一次再不行就抛异常走人工处理流程。这层校验看起来繁琐但它是“概率系统”接入“确定性业务”的压舱石。6. 一个可抄作业的最小实践Spring Boot 接入大模型实现知识库问答纸面上讲了这么多不如来一个能直接跑起来的例子。我用 Spring AI 做一个最小可用的“会员政策知识库问答”功能先把一段政策文档导入向量库用户提问时系统检索相关片段并让模型基于片段回答。6.1 准备工程与依赖建议直接用 Spring Initializr 创建项目勾选 Web 和 OpenAI 依赖。如果你用的是国内的模型服务商很多也支持 OpenAI 兼容协议配置base-url和api-key就能连上。核心依赖dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-openai/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-vector-store-redis/artifactId /dependency测试阶段向量存储先用 Redis Stack 临时跑够用了。生产环境再按体量评估是否迁移到专业向量库。6.2 初始化向量库让 AI 读文档写了两个组件一个负责把文档内容切成小块并向量化存入 Redis一个负责回答问题。Component public class KnowledgeBaseInitializer { private final VectorStore vectorStore; private final EmbeddingModel embeddingModel; public KnowledgeBaseInitializer(VectorStore vectorStore, EmbeddingModel embeddingModel) { this.vectorStore vectorStore; this.embeddingModel embeddingModel; } PostConstruct public void init() { String policyText 会员等级分为普通会员、黄金会员、铂金会员。 黄金会员享受 95 折优惠每日可领取 3 张免运费券。 铂金会员享受 88 折优惠每日可领取 5 张免运费券并享有专属客服。 会员积分每消费 1 元累积 1 分积分可在积分商城兑换商品。 ; ListDocument documents splitText(policyText); vectorStore.add(documents); } private ListDocument splitText(String text) { // 实际场景应按段落或固定长度切片这里简化为一整块 return List.of(new Document(text)); } }向量化的原理不复杂EmbeddingModel把文本变成一串浮点数数组VectorStore负责存储和相似度检索。切片切得好不好直接影响检索质量实际项目里建议按语义段落来切同时保留章节上下文不要搞一个无限长的句子扔进去。6.3 问答接口检索 生成问答部分的核心代码很简洁因为 Spring AI 把 RAG 流水线封装得很好RestController public class KnowledgeController { private final ChatClient chatClient; public KnowledgeController(ChatClient.Builder builder) { ChatMemory memory ChatMemory.builder().build(); this.chatClient builder .defaultSystem(你是会员政策助手只能根据提供的资料回答问题。如果资料中没有答案请直接说“资料中未提及”。) .build(); } PostMapping(/ask) public String ask(RequestBody String question) { return chatClient.prompt(question) .advisors(QuestionAnswerAdvisor.builder().build()) .call() .content(); } }这个接口启动后你就可以拿各种各样的会员问题去测了。问“铂金会员有什么折扣”模型会从向量库里检索到对应片段然后基于片段回答。问题的关键词和向量库里的内容差距越大检索效果越差所以 Prompt 写得清晰一点、提问具体一点结果会更稳定。6.4 实践的收获和下一步跑通这个 Demo你对“Java AI”的信心就建立起来了。你会发现整体思路仍然是传统的建工程、写配置、调接口、解析结果只是多了一个向量搜索步骤。Java 的功底全部都用得上。再往前走你可以尝试把这个接口改成流式输出让用户看到打字机效果。Spring AI 支持stream()方法Java 侧用Flux接收即可对熟悉 WebFlux 的人非常顺手。调整切片策略和检索逻辑比如用“滑动窗口”切片、检索后做重排序看对回答质量的影响。把向量库切换到生产级方案如 Milvus、Elasticsearch并加上文档更新、删除的流程。继续深入研究 Function Calling让助手能从查询接口实时拉取会员订单信息而不是只靠静态文档回答。我在实际项目里的习惯是每跑通一个 Demo就回头把概念层的原理补一遍。比如做完向量检索我会去搞明白余弦相似度是怎么算的做完流式输出我会去看看 SSE 协议是怎么分块的。这样你学到的东西就是有工程支撑的而不是空中楼阁。Java 工程师完全可以沿着这条路成为团队里最懂 AI 工程落地的那个人。