开头先说我一个比较个人的判断过去两年很多人一聊 AI 就默认是 Python 工程师的事Java 开发者要么在观望要么在心里打鼓。但 2025 年再看这个局面我反而觉得JavaAI 才是那个比人人转 Python更值得押注的组合。不是说 Python 不行而是 AI 真正大规模赚钱的地方已经从训练模型转移到了用模型改造业务系统而业务系统里最多的存量代码、最稳的中间件生态、最难替代的企业级架构经验全在 Java 这边。这篇文章不打算劝你放弃 Java 去从头学算法也不打算只灌鸡汤。我会结合我自己做 AI 应用开发的实际经验把三件事讲透为什么这个组合成立、Java 开发者怎么最快把 AI 能力变成自己的增量、以及 2025 年押注 AI 时应该怎么避坑。适合正在做 Java 后端、准备跳槽或正在焦虑技术路线是不是走错了的朋友参考。1. AI 这波真正的大蛋糕其实在 Java 手里1.1 模型是基建应用才是利润而应用的骨头是 Java 啃下来的先说一个可能反直觉的事实2024 年到 2025 年国内外的 AI 项目里真正赚钱的很少是做大模型的那批更多是**用大模型改造现有业务流程**的那批。模型训练烧钱、推理成本高、迭代风险大绝大多数公司碰不起。但把大模型接进客服系统、订单系统、审批流、知识库、代码仓库这些场景的 ROI 是能被 CIO 算清楚的。而这些系统的底座是什么绝大多数是企业里跑了好多年的 Java 服务。Spring Boot、Dubbo、Kafka、Redis、MySQL、Elasticsearch这些 Java 生态的基础设施早就铺满了各行各业。AI 要落地不是从天而降一个新系统而是往老系统里插一根智能管道。谁能不伤筋动骨地把这根管道插进去谁就拿着定价权。我见过不少团队算法工程师把模型调出来了最后卡在怎么和内部系统打通上。模型再聪明叫不动业务接口、拿不到权限、进不了工单流就是摆设。Java 工程师在这时候的价值恰恰是那套被一些人嘲笑的增删改查中间件高可用能力。所谓 AI加号后面的业务系统才是 Java 人最熟悉的主场。1.2 模型 API 化让 Java 接入门槛直接断崖式下降两三年前如果你想在 Java 里跑个像样的 NLP 模型要么接 Python 服务做跨语言调用要么用 DJL 这类库把模型硬塞进 JVM麻烦且别扭。但现在不一样了。主流大模型基本都以 OpenAI 兼容的 HTTP 接口对外提供服务Java 工程就是一个 RestTemplate 或者 WebClient 的事。这意味着什么意味着 Java 工程师不需要懂反向传播不需要会 PyTorch只需要会处理 JSON、管好超时、做好重试、设计好 Prompt就能做出一个可用的 AI 功能。模型推理的复杂度全部被 API 封装掉了Java 负责的依然是它最擅长的事稳定地编排、可靠地集成、可控地部署。我在实际项目里早期接大模型就是简单的 POST 请求后面统一封装了一层几百行 Java 代码就能把三家厂商的模型接口收敛成内部统一的 ChatService。后面要换模型、做降级、加缓存全都在这一层解决。这事放在几年前无法想象但 2025 年它就是标配。1.3 Spring AI 和 LangChain4j 的出现把最后一块短板补上了之前 Java 开发者接入 AI 总有一个尴尬没有官方的 SDK社区轮子又不太行。ChatGPT 火了那么久Java 这边一直缺一个像 Python 的 LangChain 那样顺手的东西。2024 年之后这个局面彻底变了两个项目必须提Spring AISpring 官方出品的 AI 框架熟悉 Spring Boot 的人几乎零成本上手。它把 ChatModel、EmbeddingModel、VectorStore、RAG、Agent 这些概念全部抽象成了 Spring 风格的组件。LangChain4jLangChain 理念在 Java 世界的完整移植早期就支持了 ChatMemory、结构化输出、工具调用迭代非常快。这两个框架的意义不在于功能有多炫而在于它们标志着 AI 能力已经被 Java 生态正式接纳为标准业务组件。就像当年 MyBatis、Spring Data Redis 出现一样一旦一个东西被封装成 Spring 风格的 BeanJava 工程师的批量生产力就真正被释放了。我现在的做法很简单项目中引入 Spring AI配置一个 ApiKey 和模型端点然后Service里注入ChatModelAI 就以 Java 工程师最熟悉的方式变成了一个可以 mock、可以替换、可以加切面的普通组件。押注 JavaAI本质上押注的是企业级 AI 应用开发会逐渐 Java 化这个趋势。2. 押注 AI 的第一课先把 AI 编程用出复利2.1 核心不是让 AI 写代码而是让 AI 在约束里写代码聊完宏观趋势说点马上能上手的。Java 开发者拥抱 AI第一步往往不是做 AI 应用而是用 AI 工具武装自己的日常开发。但我在团队里看到两种截然不同的用法一种是把代码往对话框里一贴让 AI 生成完事另一种是把需求、约束、验收标准写给 AI让它在明确的边界里产出可落地的代码。前者图一时爽后者才有复利。2025 年的 AI 编程工具GitHub Copilot、通义灵码、Cursor 等单看生成能力已经足够强但没有约束的 AI 生成的 Java 代码最大的问题不是跑不通而是不像一个老手写的。它经常省略参数校验、忽略事务边界、不处理空指针、随便抛出异常这些恰恰是企业级 Java 开发的命门。AI 不是不够聪明是它不知道你们项目的潜规则。所以我会花很多时间在喂约束上把团队规范、项目上下文、依赖版本、代码风格这些信息写进 Prompt 或工具的规则文件里。让 AI 在轨道内跑它产生的代码才称得上可用。这一步做扎实了后面所有 AI 应用开发都会顺很多。2.2 一个我反复用的 Java 编码提示词模板直接给一套我实践了大半年的模板用 Copilot 和通义灵码都试过效果明显好于帮我写个 xxx这种模糊指令。模板分四层角色你是在大型 Java 企业级项目中工作了 15 年的高级工程师熟悉 Spring Boot 3、MySQL、Redis、消息队列 严格遵循阿里巴巴 Java 开发手册规范。 任务实现 [具体功能]要求 1. 使用 [Spring Boot 3 / MyBatis Plus / 具体版本] 2. 参数必须做 [空值校验/格式校验]错误时抛出带错误码的业务异常 3. 数据库操作放在 Service 层事务边界清晰禁止在 Controller 写业务逻辑 4. 关键链路添加日志日志必须包含 traceId 5. 生成代码后额外列出你做出的关键假设和潜在的坑。注意最后一条这是我觉得最有价值的部分。AI 列出的关键假设能逼它暴露含糊的地方比如我假设 userId 一定存在我假设并发量低于 X——这些假设正是 Java 开发者最需要 Review 的东西。等于让 AI 从一个闷头写码的工人变成了一个先交方案的顾问。2.3 让 AI 当 Code Reviewer比让它当码农更有价值真正让我对 AI 编程改观的不是生成而是Code Review。以前人肉 Review 有遗漏很多时候是惯性思维看自己写的代码总觉得没有问题。但 AI 没有这个包袱给它一个明确的标准它能老老实实地把代码逐行挑一遍。我常用的做法是把 PRPull Request的 diff 发给 AI配上我们团队的检查清单包括是否有未关闭的 IO 流或连接泄露是否有并发修改同一个字段的隐患是否有在循环里发 HTTP 请求的写法是否能通过索引优化 SQL是否有事务失效的坑比如同类内部调用、私有方法加事务。实测下来AI 真能抓到一些老手都会漏的问题尤其是并发边界和空指针路径。把它当成评审会议上那个不说话则已、一说话就挑毛病的同事效率会高很多。当然 AI 的建议也不是全对最终判断还得靠人但它把查找问题的半径缩小了一大圈。3. 一个 Java 工程师搭 AI 应用的完整路径从 API 到 Agent3.1 起步选型Spring Boot Spring AI pgvector前面都是铺垫现在进入最核心的部分一个 Java 后端工程师从零搭一个真正能跑的 AI 应用路径是什么我以最近给一个内部团队做的知识库问答机器人为例把完整技术栈和关键代码都拆给你们。先看选型我没有一上来就上重向量数据库因为杀鸡不用牛刀组件选型理由应用框架Spring Boot 3.3.xJava 工程师最熟悉环境零负担AI 接入Spring AI官方支持抽象清晰便于换模型向量存储PostgreSQL pgvector复用已有数据库托管简单单机够用模型通义千问 / Qwen 或 OpenAI 兼容接口国内访问稳定API 成本可控文档处理Apache POI Tika能解析 Word、PDF、MarkdownPOI 是 Java 老牌库这个组合最大的优势是不用引入一套全新的存储系统。PostgreSQL 大概率本来就在你的基建清单里装上 pgvector 插件就能当向量库用和业务数据放在一起也好管理。真到了单表向量数据上千万需要水平扩展的规模再迁到专门的向量库里也不迟。3.2 第一步把大模型封装成你自己的智能服务先给 pom 里加依赖Spring AI 的版本号以你使用的版本为准dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-openai-spring-boot-starter/artifactId version1.0.0/version /dependency然后在application.yml里配置模型端点spring: ai: openai: base-url: https://你的模型网关地址/v1 api-key: ${MODEL_API_KEY} chat: options: model: qwen-plus temperature: 0.7接着定义一个统一的聊天服务接口Service public class AiChatService { private final ChatModel chatModel; public AiChatService(ChatModel chatModel) { this.chatModel chatModel; } public String chat(String userMessage) { String prompt 你是一个企业内部的智能助手回答问题时必须 1. 只基于给定的背景资料回答不要编造 2. 如果背景资料不足明确说资料库中没有相关信息 3. 使用简洁、专业的中文回答。 用户问题%s .formatted(userMessage); return chatModel.call(prompt); } }这一步做完你就拥有了一个被 Spring 容器管理的聊天能力。后续加缓存、加日志、加限流都在这一个类里扩展不会散布到其他地方。这层封装是 Java 做 AI 应用的老本行也是最容易被忽略但最不能省的部分。3.3 第二步搭一套最小可用的 RAG 知识库API 聊天只是玩具要解决AI 对业务事实一本正经胡说八道的问题必须用 RAG检索增强生成。思路就是把公司文档切成小块、向量化、存起来用户提问时先把问题向量化去库里捞最相关的几块文本拼进 Prompt 再交给大模型回答。先创建向量表用 PostgreSQL 的 pgvector 插件CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE knowledge_chunk ( id BIGSERIAL PRIMARY KEY, content TEXT NOT NULL, embedding VECTOR(1024), source VARCHAR(255) );Java 侧的完整处理链路如下Service public class RagService { private final EmbeddingModel embeddingModel; private final ChatModel chatModel; private final JdbcTemplate jdbcTemplate; public String answer(String question) { // 1. 用户问题向量化 float[] questionVector embeddingModel.embed(question); String vectorLiteral toPostgresVector(questionVector); // 2. 在知识库中检索最相似的 5 个文本块 String sql SELECT content FROM knowledge_chunk ORDER BY embedding ?::vector LIMIT 5 ; ListString contexts jdbcTemplate.queryForList(sql, String.class, vectorLiteral); // 3. 拼进 Prompt让模型基于上下文回答 String prompt buildPrompt(question, contexts); return chatModel.call(prompt); } }这里我用的是余弦距离运算符pgvector 里排序性能在百万级以内都没问题。至于文档切块我的经验是按语义段落切每块 500 到 800 字切得太碎会丢掉上下文切得太长会稀释相关度。文档解析那步我用的是 Apache POI 配合 TikaPOI 在 Java 里处理 Word 图表场景很成熟Tika 负责识别 PDF 和各种杂类格式。很多新人在这一步会卡在 PDF 转文本后格式混乱我的办法是只保留标题结构和正文段落剔除页眉页脚否则检索效果会明显下降。3.4 第三步让 AI 学会调用你的业务接口Agent 初体验RAG 解决AI 会说话的问题Agent 解决AI 会办事的问题。2025 年热词里的AI Agent落到 Java 工程里本质就是让模型输出一个结构化调用意图系统按意图去调函数。Spring AI 对工具调用function calling的支持很优雅。你只需要把一个普通的 Java Bean 方法声明为一个工具Component public class OrderTools { Tool(description 根据订单号查询订单状态) public String getOrderStatus(String orderId) { // 这里可以调用真实的订单查询服务 return orderService.queryStatus(orderId); } }然后把这个工具注入到 ChatModel 的调用上下文中模型会自动判断用户想查订单状态应该调用 getOrderStatus 函数。你在代码里完全不用自己解析什么函数名Spring AI 把模型输出的 function call 转成了对 Bean 方法的反射调用。这一步是 JavaAI 产生化学反应的地方。因为 Java 生态里有太多已经写好的业务服务过去要人肉去点按钮、写脚本现在全都能暴露成 AI 的工具。我做过一个内部工单助手把查状态、改优先级、指派处理人、发通知这四件事暴露成工具AI 就能按用户一句自然语言把整条流程串起来。开发量不大但业务体感上的冲击不小。3.5 这块实践里最容易翻车的三个地方这段实操总结是重点因为坑真的是踩出来的。第一个坑是超时控制。大模型接口响应慢是常态尤其接了工具调用后模型可能为了确认参数和你来回两三次一个请求的端到端耗时能到十几秒。Java 默认的 HTTP 超时肯定不够必须给 WebClient 或 RestTemplate 单独调大超时时间同时接口还要考虑返回值异步化不能把用户请求一直占着。我现在一律用的是 CompletableFuture 异步 前端轮询或 SSE 推送。第二个坑是模型上下文里的脏数据。如果你把整个文档原文都塞给模型它会引用一堆不该引用的内容。一定要在 Prompt 层做制度约束同时用切块检索做物理隔离。我见过不少团队兴致勃勃接了大模型结果回答里出现了文档里的机密 IP都是从把整个文档全塞进去开始的。第三个坑是对话记忆怎么存。ChatModel 本身不帮你存历史多轮对话时需要你自己维护 message 列表。我建议存在 Redis 里并设置合理的过期时间不要无脑全存否则上下文越来越长成本越来越高。通常保留最近十轮到二十轮就足够。4. 别再死磕八股文AI 时代的 Java 面试与职业路线4.1 面试风向变了面试官开始问你用 AI 做过什么了最近帮几个朋友看了机会也问了一圈做技术面试官的同行一个很真实的变化是2025 年的 Java 面试AI 已经从加分项变成了必问题。以前是了解 AI 优先现在开始问你给我讲讲你怎么用 AI 的你在项目里接过大模型吗遇到模型输出 JSON 格式乱了怎么办。有意思的是传统八股文并没有完全失效AQS、JVM 调优、并发编程这些依然是基础盘但纯背八股文的竞争力在快速衰减。以前一个java 八股文背得熟的候选人能唬住面试官现在面试官见多识广反而欣赏那种能用 AI 把交付速度提起来、还知道 AI 会翻车在哪的人。所以我的建议很直白别再花大把时间背那些永远用不上的冷门八股细节了把时间拿出来做一个真正的 AI 集成 Demo哪怕只是把公司某个内部文档做成 RAG 问答。简历上写熟练使用 Spring AI 接大模型、搭 RAG、做了工具调用比写十行精通词都管用。4.2 未来两三年更值钱的三种复合能力基于我对市场岗位的观察JavaAI 这条线上未来两三年有几种复合能力最容易溢价大模型工程化能力不是调 API 的 hello world而是能处理限流、降级、缓存、重试、敏感词过滤、数据脱敏、成本控制。企业现在缺的就是能把模型稳定嵌进生产链路的人。热词里的ai应用开发ai测试开发背后都是这类需求。领域数据与 RAG 的结合能力知道怎么解析业务文档、清洗数据、设计切块策略、评估检索效果。知识库做得好不好直接决定 AI 应用的上限而这个是纯工程问题非常吃 Java 基本功。Agent 的流程编排能力知道哪些业务动作可以暴露成工具、怎么设计工具参数、怎么兜底失败情况。这块刚起步但需求增长很快。现在会的人不多谁先趟出经验谁占位置。还要单独提一句ai辅助在垂直领域的应用比如专利辅助、文案生成这些。这不是让你去抢写作的饭碗而是让你意识到离业务场景越近、越能解决具体问题的 AI 功能越不容易被取代。Java 工程师天然贴近业务系统这是做 AI 落地的护城河别把它丢了。5. 关于押注我想说点实在的最后聊点不像技术文章的真心话。互联网那波红利本质是把传统业务搬上网AI这波红利本质是把业务中的智能判断自动化。两次浪潮的底层逻辑很像但有一个巨大区别互联网比拼的是流量和模式创新AI比拼的是数据和工程深度。而后者的核心玩家恰恰是企业里最懂工程的人。我自己的体会是过去这些年掌握的 Java 技能没有一样白学。Spring 的事务管理让我在 AI 写数据入库时敢保证一致性JVM 排障能力让我在处理大模型流式响应内存飙升时能快速定位多线程与异步编程让我在做 Agent 并发调度时不慌。AI 没有取代 Java 工程师它只是把 Java 工程师的杠杆变长了。说几个现在就可以动手的建议不分先后把日常开发中的 AI 编程规范固化下来形成团队的 PR Review 清单拿一个两周能做完的内部小需求做一次完整的 RAG 落地不要停留在 demo把你最熟悉的一个业务接口暴露成大模型工具体验一下 Agent 的工程链路在简历里新增一块AI 应用开发实践写清楚你解决了什么问题踩过哪个坑。这些事看起来不大但坚持一年和身边还在观望的同行就会拉开明显差距。我个人始终觉得2025 年不是一个要不要学 AI的问题而是一个用什么姿势学 AI的问题。对 Java 开发者来说最好的姿势不是丢掉本行去追风而是站在自己最硬的工程地基上把 AI 嫁接上去。这个组合我押了而且长期看不会输。
2025 Java+AI开发实战：从AI编程到RAG与Agent落地
开头先说我一个比较个人的判断过去两年很多人一聊 AI 就默认是 Python 工程师的事Java 开发者要么在观望要么在心里打鼓。但 2025 年再看这个局面我反而觉得JavaAI 才是那个比人人转 Python更值得押注的组合。不是说 Python 不行而是 AI 真正大规模赚钱的地方已经从训练模型转移到了用模型改造业务系统而业务系统里最多的存量代码、最稳的中间件生态、最难替代的企业级架构经验全在 Java 这边。这篇文章不打算劝你放弃 Java 去从头学算法也不打算只灌鸡汤。我会结合我自己做 AI 应用开发的实际经验把三件事讲透为什么这个组合成立、Java 开发者怎么最快把 AI 能力变成自己的增量、以及 2025 年押注 AI 时应该怎么避坑。适合正在做 Java 后端、准备跳槽或正在焦虑技术路线是不是走错了的朋友参考。1. AI 这波真正的大蛋糕其实在 Java 手里1.1 模型是基建应用才是利润而应用的骨头是 Java 啃下来的先说一个可能反直觉的事实2024 年到 2025 年国内外的 AI 项目里真正赚钱的很少是做大模型的那批更多是**用大模型改造现有业务流程**的那批。模型训练烧钱、推理成本高、迭代风险大绝大多数公司碰不起。但把大模型接进客服系统、订单系统、审批流、知识库、代码仓库这些场景的 ROI 是能被 CIO 算清楚的。而这些系统的底座是什么绝大多数是企业里跑了好多年的 Java 服务。Spring Boot、Dubbo、Kafka、Redis、MySQL、Elasticsearch这些 Java 生态的基础设施早就铺满了各行各业。AI 要落地不是从天而降一个新系统而是往老系统里插一根智能管道。谁能不伤筋动骨地把这根管道插进去谁就拿着定价权。我见过不少团队算法工程师把模型调出来了最后卡在怎么和内部系统打通上。模型再聪明叫不动业务接口、拿不到权限、进不了工单流就是摆设。Java 工程师在这时候的价值恰恰是那套被一些人嘲笑的增删改查中间件高可用能力。所谓 AI加号后面的业务系统才是 Java 人最熟悉的主场。1.2 模型 API 化让 Java 接入门槛直接断崖式下降两三年前如果你想在 Java 里跑个像样的 NLP 模型要么接 Python 服务做跨语言调用要么用 DJL 这类库把模型硬塞进 JVM麻烦且别扭。但现在不一样了。主流大模型基本都以 OpenAI 兼容的 HTTP 接口对外提供服务Java 工程就是一个 RestTemplate 或者 WebClient 的事。这意味着什么意味着 Java 工程师不需要懂反向传播不需要会 PyTorch只需要会处理 JSON、管好超时、做好重试、设计好 Prompt就能做出一个可用的 AI 功能。模型推理的复杂度全部被 API 封装掉了Java 负责的依然是它最擅长的事稳定地编排、可靠地集成、可控地部署。我在实际项目里早期接大模型就是简单的 POST 请求后面统一封装了一层几百行 Java 代码就能把三家厂商的模型接口收敛成内部统一的 ChatService。后面要换模型、做降级、加缓存全都在这一层解决。这事放在几年前无法想象但 2025 年它就是标配。1.3 Spring AI 和 LangChain4j 的出现把最后一块短板补上了之前 Java 开发者接入 AI 总有一个尴尬没有官方的 SDK社区轮子又不太行。ChatGPT 火了那么久Java 这边一直缺一个像 Python 的 LangChain 那样顺手的东西。2024 年之后这个局面彻底变了两个项目必须提Spring AISpring 官方出品的 AI 框架熟悉 Spring Boot 的人几乎零成本上手。它把 ChatModel、EmbeddingModel、VectorStore、RAG、Agent 这些概念全部抽象成了 Spring 风格的组件。LangChain4jLangChain 理念在 Java 世界的完整移植早期就支持了 ChatMemory、结构化输出、工具调用迭代非常快。这两个框架的意义不在于功能有多炫而在于它们标志着 AI 能力已经被 Java 生态正式接纳为标准业务组件。就像当年 MyBatis、Spring Data Redis 出现一样一旦一个东西被封装成 Spring 风格的 BeanJava 工程师的批量生产力就真正被释放了。我现在的做法很简单项目中引入 Spring AI配置一个 ApiKey 和模型端点然后Service里注入ChatModelAI 就以 Java 工程师最熟悉的方式变成了一个可以 mock、可以替换、可以加切面的普通组件。押注 JavaAI本质上押注的是企业级 AI 应用开发会逐渐 Java 化这个趋势。2. 押注 AI 的第一课先把 AI 编程用出复利2.1 核心不是让 AI 写代码而是让 AI 在约束里写代码聊完宏观趋势说点马上能上手的。Java 开发者拥抱 AI第一步往往不是做 AI 应用而是用 AI 工具武装自己的日常开发。但我在团队里看到两种截然不同的用法一种是把代码往对话框里一贴让 AI 生成完事另一种是把需求、约束、验收标准写给 AI让它在明确的边界里产出可落地的代码。前者图一时爽后者才有复利。2025 年的 AI 编程工具GitHub Copilot、通义灵码、Cursor 等单看生成能力已经足够强但没有约束的 AI 生成的 Java 代码最大的问题不是跑不通而是不像一个老手写的。它经常省略参数校验、忽略事务边界、不处理空指针、随便抛出异常这些恰恰是企业级 Java 开发的命门。AI 不是不够聪明是它不知道你们项目的潜规则。所以我会花很多时间在喂约束上把团队规范、项目上下文、依赖版本、代码风格这些信息写进 Prompt 或工具的规则文件里。让 AI 在轨道内跑它产生的代码才称得上可用。这一步做扎实了后面所有 AI 应用开发都会顺很多。2.2 一个我反复用的 Java 编码提示词模板直接给一套我实践了大半年的模板用 Copilot 和通义灵码都试过效果明显好于帮我写个 xxx这种模糊指令。模板分四层角色你是在大型 Java 企业级项目中工作了 15 年的高级工程师熟悉 Spring Boot 3、MySQL、Redis、消息队列 严格遵循阿里巴巴 Java 开发手册规范。 任务实现 [具体功能]要求 1. 使用 [Spring Boot 3 / MyBatis Plus / 具体版本] 2. 参数必须做 [空值校验/格式校验]错误时抛出带错误码的业务异常 3. 数据库操作放在 Service 层事务边界清晰禁止在 Controller 写业务逻辑 4. 关键链路添加日志日志必须包含 traceId 5. 生成代码后额外列出你做出的关键假设和潜在的坑。注意最后一条这是我觉得最有价值的部分。AI 列出的关键假设能逼它暴露含糊的地方比如我假设 userId 一定存在我假设并发量低于 X——这些假设正是 Java 开发者最需要 Review 的东西。等于让 AI 从一个闷头写码的工人变成了一个先交方案的顾问。2.3 让 AI 当 Code Reviewer比让它当码农更有价值真正让我对 AI 编程改观的不是生成而是Code Review。以前人肉 Review 有遗漏很多时候是惯性思维看自己写的代码总觉得没有问题。但 AI 没有这个包袱给它一个明确的标准它能老老实实地把代码逐行挑一遍。我常用的做法是把 PRPull Request的 diff 发给 AI配上我们团队的检查清单包括是否有未关闭的 IO 流或连接泄露是否有并发修改同一个字段的隐患是否有在循环里发 HTTP 请求的写法是否能通过索引优化 SQL是否有事务失效的坑比如同类内部调用、私有方法加事务。实测下来AI 真能抓到一些老手都会漏的问题尤其是并发边界和空指针路径。把它当成评审会议上那个不说话则已、一说话就挑毛病的同事效率会高很多。当然 AI 的建议也不是全对最终判断还得靠人但它把查找问题的半径缩小了一大圈。3. 一个 Java 工程师搭 AI 应用的完整路径从 API 到 Agent3.1 起步选型Spring Boot Spring AI pgvector前面都是铺垫现在进入最核心的部分一个 Java 后端工程师从零搭一个真正能跑的 AI 应用路径是什么我以最近给一个内部团队做的知识库问答机器人为例把完整技术栈和关键代码都拆给你们。先看选型我没有一上来就上重向量数据库因为杀鸡不用牛刀组件选型理由应用框架Spring Boot 3.3.xJava 工程师最熟悉环境零负担AI 接入Spring AI官方支持抽象清晰便于换模型向量存储PostgreSQL pgvector复用已有数据库托管简单单机够用模型通义千问 / Qwen 或 OpenAI 兼容接口国内访问稳定API 成本可控文档处理Apache POI Tika能解析 Word、PDF、MarkdownPOI 是 Java 老牌库这个组合最大的优势是不用引入一套全新的存储系统。PostgreSQL 大概率本来就在你的基建清单里装上 pgvector 插件就能当向量库用和业务数据放在一起也好管理。真到了单表向量数据上千万需要水平扩展的规模再迁到专门的向量库里也不迟。3.2 第一步把大模型封装成你自己的智能服务先给 pom 里加依赖Spring AI 的版本号以你使用的版本为准dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-openai-spring-boot-starter/artifactId version1.0.0/version /dependency然后在application.yml里配置模型端点spring: ai: openai: base-url: https://你的模型网关地址/v1 api-key: ${MODEL_API_KEY} chat: options: model: qwen-plus temperature: 0.7接着定义一个统一的聊天服务接口Service public class AiChatService { private final ChatModel chatModel; public AiChatService(ChatModel chatModel) { this.chatModel chatModel; } public String chat(String userMessage) { String prompt 你是一个企业内部的智能助手回答问题时必须 1. 只基于给定的背景资料回答不要编造 2. 如果背景资料不足明确说资料库中没有相关信息 3. 使用简洁、专业的中文回答。 用户问题%s .formatted(userMessage); return chatModel.call(prompt); } }这一步做完你就拥有了一个被 Spring 容器管理的聊天能力。后续加缓存、加日志、加限流都在这一个类里扩展不会散布到其他地方。这层封装是 Java 做 AI 应用的老本行也是最容易被忽略但最不能省的部分。3.3 第二步搭一套最小可用的 RAG 知识库API 聊天只是玩具要解决AI 对业务事实一本正经胡说八道的问题必须用 RAG检索增强生成。思路就是把公司文档切成小块、向量化、存起来用户提问时先把问题向量化去库里捞最相关的几块文本拼进 Prompt 再交给大模型回答。先创建向量表用 PostgreSQL 的 pgvector 插件CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE knowledge_chunk ( id BIGSERIAL PRIMARY KEY, content TEXT NOT NULL, embedding VECTOR(1024), source VARCHAR(255) );Java 侧的完整处理链路如下Service public class RagService { private final EmbeddingModel embeddingModel; private final ChatModel chatModel; private final JdbcTemplate jdbcTemplate; public String answer(String question) { // 1. 用户问题向量化 float[] questionVector embeddingModel.embed(question); String vectorLiteral toPostgresVector(questionVector); // 2. 在知识库中检索最相似的 5 个文本块 String sql SELECT content FROM knowledge_chunk ORDER BY embedding ?::vector LIMIT 5 ; ListString contexts jdbcTemplate.queryForList(sql, String.class, vectorLiteral); // 3. 拼进 Prompt让模型基于上下文回答 String prompt buildPrompt(question, contexts); return chatModel.call(prompt); } }这里我用的是余弦距离运算符pgvector 里排序性能在百万级以内都没问题。至于文档切块我的经验是按语义段落切每块 500 到 800 字切得太碎会丢掉上下文切得太长会稀释相关度。文档解析那步我用的是 Apache POI 配合 TikaPOI 在 Java 里处理 Word 图表场景很成熟Tika 负责识别 PDF 和各种杂类格式。很多新人在这一步会卡在 PDF 转文本后格式混乱我的办法是只保留标题结构和正文段落剔除页眉页脚否则检索效果会明显下降。3.4 第三步让 AI 学会调用你的业务接口Agent 初体验RAG 解决AI 会说话的问题Agent 解决AI 会办事的问题。2025 年热词里的AI Agent落到 Java 工程里本质就是让模型输出一个结构化调用意图系统按意图去调函数。Spring AI 对工具调用function calling的支持很优雅。你只需要把一个普通的 Java Bean 方法声明为一个工具Component public class OrderTools { Tool(description 根据订单号查询订单状态) public String getOrderStatus(String orderId) { // 这里可以调用真实的订单查询服务 return orderService.queryStatus(orderId); } }然后把这个工具注入到 ChatModel 的调用上下文中模型会自动判断用户想查订单状态应该调用 getOrderStatus 函数。你在代码里完全不用自己解析什么函数名Spring AI 把模型输出的 function call 转成了对 Bean 方法的反射调用。这一步是 JavaAI 产生化学反应的地方。因为 Java 生态里有太多已经写好的业务服务过去要人肉去点按钮、写脚本现在全都能暴露成 AI 的工具。我做过一个内部工单助手把查状态、改优先级、指派处理人、发通知这四件事暴露成工具AI 就能按用户一句自然语言把整条流程串起来。开发量不大但业务体感上的冲击不小。3.5 这块实践里最容易翻车的三个地方这段实操总结是重点因为坑真的是踩出来的。第一个坑是超时控制。大模型接口响应慢是常态尤其接了工具调用后模型可能为了确认参数和你来回两三次一个请求的端到端耗时能到十几秒。Java 默认的 HTTP 超时肯定不够必须给 WebClient 或 RestTemplate 单独调大超时时间同时接口还要考虑返回值异步化不能把用户请求一直占着。我现在一律用的是 CompletableFuture 异步 前端轮询或 SSE 推送。第二个坑是模型上下文里的脏数据。如果你把整个文档原文都塞给模型它会引用一堆不该引用的内容。一定要在 Prompt 层做制度约束同时用切块检索做物理隔离。我见过不少团队兴致勃勃接了大模型结果回答里出现了文档里的机密 IP都是从把整个文档全塞进去开始的。第三个坑是对话记忆怎么存。ChatModel 本身不帮你存历史多轮对话时需要你自己维护 message 列表。我建议存在 Redis 里并设置合理的过期时间不要无脑全存否则上下文越来越长成本越来越高。通常保留最近十轮到二十轮就足够。4. 别再死磕八股文AI 时代的 Java 面试与职业路线4.1 面试风向变了面试官开始问你用 AI 做过什么了最近帮几个朋友看了机会也问了一圈做技术面试官的同行一个很真实的变化是2025 年的 Java 面试AI 已经从加分项变成了必问题。以前是了解 AI 优先现在开始问你给我讲讲你怎么用 AI 的你在项目里接过大模型吗遇到模型输出 JSON 格式乱了怎么办。有意思的是传统八股文并没有完全失效AQS、JVM 调优、并发编程这些依然是基础盘但纯背八股文的竞争力在快速衰减。以前一个java 八股文背得熟的候选人能唬住面试官现在面试官见多识广反而欣赏那种能用 AI 把交付速度提起来、还知道 AI 会翻车在哪的人。所以我的建议很直白别再花大把时间背那些永远用不上的冷门八股细节了把时间拿出来做一个真正的 AI 集成 Demo哪怕只是把公司某个内部文档做成 RAG 问答。简历上写熟练使用 Spring AI 接大模型、搭 RAG、做了工具调用比写十行精通词都管用。4.2 未来两三年更值钱的三种复合能力基于我对市场岗位的观察JavaAI 这条线上未来两三年有几种复合能力最容易溢价大模型工程化能力不是调 API 的 hello world而是能处理限流、降级、缓存、重试、敏感词过滤、数据脱敏、成本控制。企业现在缺的就是能把模型稳定嵌进生产链路的人。热词里的ai应用开发ai测试开发背后都是这类需求。领域数据与 RAG 的结合能力知道怎么解析业务文档、清洗数据、设计切块策略、评估检索效果。知识库做得好不好直接决定 AI 应用的上限而这个是纯工程问题非常吃 Java 基本功。Agent 的流程编排能力知道哪些业务动作可以暴露成工具、怎么设计工具参数、怎么兜底失败情况。这块刚起步但需求增长很快。现在会的人不多谁先趟出经验谁占位置。还要单独提一句ai辅助在垂直领域的应用比如专利辅助、文案生成这些。这不是让你去抢写作的饭碗而是让你意识到离业务场景越近、越能解决具体问题的 AI 功能越不容易被取代。Java 工程师天然贴近业务系统这是做 AI 落地的护城河别把它丢了。5. 关于押注我想说点实在的最后聊点不像技术文章的真心话。互联网那波红利本质是把传统业务搬上网AI这波红利本质是把业务中的智能判断自动化。两次浪潮的底层逻辑很像但有一个巨大区别互联网比拼的是流量和模式创新AI比拼的是数据和工程深度。而后者的核心玩家恰恰是企业里最懂工程的人。我自己的体会是过去这些年掌握的 Java 技能没有一样白学。Spring 的事务管理让我在 AI 写数据入库时敢保证一致性JVM 排障能力让我在处理大模型流式响应内存飙升时能快速定位多线程与异步编程让我在做 Agent 并发调度时不慌。AI 没有取代 Java 工程师它只是把 Java 工程师的杠杆变长了。说几个现在就可以动手的建议不分先后把日常开发中的 AI 编程规范固化下来形成团队的 PR Review 清单拿一个两周能做完的内部小需求做一次完整的 RAG 落地不要停留在 demo把你最熟悉的一个业务接口暴露成大模型工具体验一下 Agent 的工程链路在简历里新增一块AI 应用开发实践写清楚你解决了什么问题踩过哪个坑。这些事看起来不大但坚持一年和身边还在观望的同行就会拉开明显差距。我个人始终觉得2025 年不是一个要不要学 AI的问题而是一个用什么姿势学 AI的问题。对 Java 开发者来说最好的姿势不是丢掉本行去追风而是站在自己最硬的工程地基上把 AI 嫁接上去。这个组合我押了而且长期看不会输。
