最近这两年，程序员应该很难完全避开一个问题：

AI 都已经能写代码了，我们还应该学什么？

说完全不焦虑，肯定不现实。

但我也不想把这个问题写成“程序员马上要被取代”的焦虑文。

从我自己的感受来看，AI 确实在改变开发方式。它可以帮我们写代码、解释报错、生成测试、整理文档。但在真实项目里，需求怎么拆、系统边界怎么定、数据怎么流转、异常场景怎么处理、线上风险怎么控制，这些依然需要工程师判断。

所以我现在更关心的不是：

AI 会不会取代程序员？

而是：

Java 程序员能不能把 AI 能力真正接入自己的业务系统？

这就是我准备系统学习 Spring AI 的原因。

为什么是 Spring AI？

很多 AI 应用开发资料会从 Python 生态开始，比如 LangChain、LlamaIndex。

这些框架当然很强，但对 Java 后端开发者来说，我们日常项目大多还是 Spring Boot、Spring Cloud、MyBatis、Redis、PostgreSQL、消息队列、微服务这一套技术栈。

如果只是为了接入 AI，就把整个技术栈切到 Python，很多团队并不现实。

Spring AI 的价值就在这里。

它把 AI 应用开发中常见的能力，用 Spring 的方式封装起来。

也就是说，我们可以继续使用熟悉的 Spring Boot 项目结构、配置文件、Bean 注入、Controller、Service 分层，只是在这个基础上，把 AI 能力加进去。

对 Java 程序员来说，这是一条比较自然的学习路径。

这个系列怎么学？

这次我不想只停留在“看文档、记概念、跑几个零散 Demo”的阶段。

因为这种学习方式有一个问题：当时好像懂了，但真正要做项目时，还是不知道从哪里下手。

所以这个系列会围绕一个完整的小项目展开：

基于 Spring AI 的企业知识库问答助手

每一篇只解决一个具体问题，每一篇都留下可运行的代码和测试结果。

最终这个项目会逐步具备这些能力：

• 普通聊天
• 流式输出
• 系统提示词
• 结构化返回
• 本地模型调用
• 文档读取
• 文档切分
• Embedding 向量化
• 向量数据库存储
• RAG 文档问答
• Tool Calling 工具调用
• 多轮对话记忆
• 简单前端页面

这样学的好处是，每一步都有上下文。

不是今天学 ChatClient，明天学 Embedding，后天又突然学 Tool Calling，而是始终围绕同一个项目往前走。

计划写哪些内容？

暂时规划如下，后面会根据实际学习过程调整。

每一篇文章不会追求“大而全”，而是做到“小而完整”。

我希望读者看完一篇，就能跟着完成一个明确的小功能。

技术选型

为了避免后面每一篇都重新纠结版本和组件，这里先定一个初始技术栈：

说明一下，Spring AI 版本更新比较快。正式写每一篇代码时，我会以当时官方文档里的稳定版本为准。

为什么选 PostgreSQL + pgvector？

主要是因为很多 Java 后端项目本来就会用 PostgreSQL。用 pgvector 可以少引入一个新的中间件，比较适合学习阶段验证。

这个系列适合谁？

这个系列主要写给三类人：

• 熟悉 Java 和 Spring Boot，但还没有系统做过 AI 应用的后端开发者
• 已经调过大模型 API，但不知道怎么把它工程化到 Java 项目里的开发者
• 想做企业知识库、智能客服、业务助手、内部问答系统的人

如果你完全没接触过 Spring Boot，可能需要先补一下 Controller、Service、配置文件、Maven 依赖这些基础。

如果你已经熟悉 Spring Boot，那这个系列应该可以直接跟。

写在最后

学 Spring AI 不能解决所有职业焦虑。

但至少可以让我们从“只是在旁边看 AI 变化”，变成“真正动手构建 AI 应用”。

这就是这个系列想做的事情。

不喊口号，不追热点。

从一个 Spring Boot 项目开始，一步一步把 Spring AI 学明白。

下一篇，我们正式创建项目。

目标很简单：

创建一个 Spring Boot + Spring AI 项目，并让它成功启动起来。