企业官网建设流程全解析

最近社区里被一个问题刷屏了：Spring AI Alibaba 停更了，Java 还有希望吗？

先给结论：有希望，而且希望比很多人想象的都大。但我要先把话说明白——“Spring AI Alibaba 停更”这件事是真的，可它跟我们讨论的“Java 能不能做 AI”根本就是两码事。很多同学把“某个框架没维护”直接等于“这条技术路线走不下去了”，这中间漏掉了太多关键信息。

这篇文章我不想灌鸡汤，就干三件事：把这个项目停更的真实原因扒清楚，把 Java 在 AI 落地链路里的位置摆正，再给一套你现在就能上手复现的技术方案。后面还会把我在本地跑通 Spring AI 官方主项目 + Ollama 做知识库问答的完整过程放出来，包括遇到的坑和排查方法。看完你大概会明白：Java 做 AI 不是没戏，只是需要换一套思维方式和选型路径。

1. 先看真相：Spring AI Alibaba 的“停更”意味着什么

1.1 这个项目到底是什么来头

很多新手容易搞混 Spring AI 和 Spring AI Alibaba，我先把这层关系理清楚。

Spring AI 是 Spring 官方出的 AI 应用开发框架，目标是把主流大模型厂商的调用接口抽象成一套统一 API，让开发者写一套代码，就能接这家模型或者那家模型。它更像是一个“适配层”，解决的是 Java 后端接入大模型时的重复劳动问题。

Spring AI Alibaba 则是一个面向国内模型生态的适配项目，主要补的是阿里系模型（如通义千问等）与 Spring AI 的对接空缺，同时引入了一些国内开发者在落地时更习惯的组件。它出现的那段时间，中文圈推荐度非常高，原因很简单——当时 Spring AI 官方主项目对国内模型的适配还不够顺手，很多教程宁可直接用这个中文友好的项目。

换句话说，它可以理解成“本地化适配分支”，不是 Spring AI 本身，更不是 Java 生态的全部。这个定位很重要，后面所有讨论都建立在这层认知上。

1.2 “停更”背后的真实状态

我特意去翻了项目的更新记录和社区讨论。老实说，这个项目的活跃度在过去一年多确实明显下滑：版本迭代基本停滞，代码提交频率大幅下降，issue 里不少提问得不到及时回应，release 记录也停在了一个早期的版本。用“事实上的停更”来形容并不冤枉它。

但停更的原因，并不是“这条路走不通”，更不是“Java 写 AI 是错的”。它更像是开源项目里很常见的一种状态：

• 项目发起方把人力投入撤回了，团队重排优先级；
• 国内模型厂商各自推出了自己的官方 SDK，直接减少了社区对这个适配层的依赖；
• Spring AI 官方主项目自身在快速迭代，逐渐补上了很多原本只有这个项目才有的能力。

这种情况在开源社区太常见了。一个项目只要核心维护者不再投入，它就会慢慢“冷却”。哪怕代码仍然可以正常编译、正常使用，只要没人迭代，短期看就等于停更。但大家要分清：项目冷却 ≠ 技术底座废了，更不等于这个语言生态没希望。

1.3 把“框架焦虑”和“语言焦虑”拆开

之所以要把这层关系单独拎出来写一节，是因为我在评论区看到太多被标题带偏的言论。有人说“Java 完蛋了”，有人说“赶紧转行学 Python 吧”，这些结论都过度简化了。

打个比方，你常用的一个翻译插件下架了，不代表你学的英语就没用了，更不代表所有英语翻译工具都消失了。Spring AI Alibaba 停更，只代表这个“适配组件”本身需要更多社区支持，或者你的项目应该切换接入方式；它绝不代表 Java 后端没有 AI 开发能力。Spring 官方主项目 Spring AI 到现在依然保持着稳定的发布节奏，新的版本功能越来越多，社区讨论也一直很活跃。

所以我的态度很明确：既然你对 Java AI 开发有真实需求，与其纠结“哪个仓库不更新了”，不如花时间把官方主项目吃透，或者直接用云厂商 SDK 接入。这些路不但没有消失，反而是越来越宽了。

2. 认清现实：Java 在 AI 时代没被淘汰，只是换了个工种

2.1 大模型开发的两条赛道，别站错位置

恨多人一想到“AI 开发”，脑海里自动浮现的是训练大模型、调参、跑显卡集群。这种极客式的理解当然没有错，但它只是 AI 产业的一部分。我们把大模型开发分成两条赛道来看：

• 赛道一：模型研发。也就是预训练、微调、对齐、推理优化这些偏研究、偏算法的方向。在这个赛道，Python 确实有巨大优势，生态工具链都是现成的，数据科学家也习惯用它。
• 赛道二：应用落地。也就是把已经训练好的模型，接入到真实的业务系统里，让用户能通过 API、聊天框、业务按钮真正用起来。这个赛道考验的技术点完全不同：接口整合、鉴权、流式输出、并发控制、数据接入、稳定性保障。

Java 在企业级后端干了这么多年，积累的大量能力恰好落在赛道二里。你想想看，一个普通企业要让 AI 赋能现有业务流程，他需要的是什么？是一个大模型？不一定。他需要的是把现有的客户数据、订单数据、知识库文档喂给模型，同时保证现有的业务系统不崩、权限不漏、响应及时。这正是 Java 后端最常见的老本行。

用生活化的类比解释：训练大模型就像造发动机，Python 在这件事上是专业选手；但把发动机装进整车、配上油箱、刹车、仪表盘，让它能安全地跑在公路上，这是汽车工程师的事。Java 就是那个干了十几年汽车集成的工程师。你说发动机换代了，汽车工程师就没饭吃了？恰恰相反，每次有新型发动机出来，会换装、会调校的工程师反而更抢手。

2.2 AI 应用落地链路里，Java 能拿下的关键环节

我再列一下实际项目里跟大模型对接时绕不开的工程问题，你看看这些是不是 Java 的强项：

• API 网关与权限控制：大模型接口要有网关转发、密钥管理、按用户限流，这是 Java 最常见的中间件场景；
• 流式输出与响应编排：模型回答是一段一段吐出来的，要用 SSE 或 WebSocket 推到前端，Java 的响应式编程和虚拟线程在这里非常顺手；
• 任务编排与状态管理：多轮对话、多工具调用、复杂 Agent 流程里的状态保存和回滚，后端工程化是强项；
• RAG 知识库链路：文档解析、切片、向量化、检索、重排，这整条管道本质上是一套数据加工流程，Java 完全能hold住；
• 可观测性：链路追踪、指标采集、日志归集，这些本来就是 Java 应用平台最成熟的部分。

所以答案是：Java 不是在 AI 浪潮里出局了，而是从聚光灯下的“算法码头”转向了更靠后的“工程码头”。这里没有多少人写高深的研究论文，但每天支撑着大量真实业务的上线。

2.3 一个容易忽略的优势：存量系统衔接

还有一件事，很多初学者压根意识不到——大多数企业里现存的业务系统就是 Java 写的。你让公司把核心客户系统推倒重做，换一门语言去接 AI，成本高到难以想象。更合理的路径是，用 Java 在现有系统里加一层“AI 接入服务”，让老系统快速拥有新能力。

我之前帮一个朋友调过类似场景（这里就叫模拟项目X吧）：一个不太新的内部运维系统，需要接一个问答机器人来回答文档里常见问题。真正的核心难点根本不是调模型接口，而是要把散落在一堆旧格式文档里的知识清洗、切片、入库，还要保证老系统的工单权限在问答里不起冲突。这些工作里面，模型只是一个黑盒，周边十件事每一件都是 Java 的老战场。所以你看，框架停更真的不该动摇你扎根这个语言的信心。

3. Java 开发者的 AI 技术选型参考

3.1 四条主流接入路线

放下“有没有希望”这种宏观焦虑，落到具体项目里，Java 开发者面前其实有非常清晰的选型路径。我根据自己的实践，把最常见的四类方案整理成了一张对比表：

这张表怎么看？我给几条经验：

• 如果你的项目本身就是 Spring Boot，想快速把聊天接口跑通、让前后端联调起来，Spring AI 官方主项目是最省心的。你不必因为 Spring AI Alibaba 停下来就绕开官方主线。
• 如果业务里有复杂的 Agent 编排、多步工具调用、丰富的会话内存管理，LangChain4j的抽象更灵活，但它的文档更新节奏没有那么稳，需要你对源码做一定的追踪。
• 如果公司已经选定某家云平台的模型，直接用官方 SDK最稳，只是要注意厂商绑定问题，将来换模型的工作量会更大。
• 如果是私有化部署、数据不出内网的场景，Ollama + Java 客户端是很好的组合，后面我会给出一个具体可跑的例子。

3.2 向量库选型不能拍脑袋

RAG 落地一定绕不开向量数据库。很多新手一上来就选大牌，结果数据和预算都撑不住。这里我给一个简单的决策逻辑：

• 单机 Demo / 快速验证：用 SimpleVectorStore 就够了，那是 Spring AI 内置的内存向量库，零运维成本；
• 中小规模数据（几万条以内）：用 Redis 的向量检索模块或 Elasticsearch 的向量能力，充分利用已有中间件；
• 大规模数据（百万级向量）：上 Milvus 这类专业向量数据库，或者用云厂商的向量检索服务。

另外提醒一句：向量库一旦上线，embedding 模型就不要再轻易换了。换来换去导致向量维度不一致、语义空间变了，旧索引全部失效，这个坑我踩过，后面着重讲。

3.3 本地模型选型的现实考量

本地推理方案里，模型选型比框架更影响体验。如果只是跑通流程，用 3B 左右的小模型就足够了；如果要追求中文质量，可以往 7B 到 14B 的模型走，但得先确认显卡和内存扛不扛得住。

embedding 模型方面，中文场景我建议优先用 bge-m3 这一类对中文支持比较好的向量模型。对比过英文为主的模型，中文的语义检索效果差距很明显，尤其在搜索企业内部中文文档的时候。

4. 实操：用 Spring AI + Ollama 跑一个带知识库的本地问答服务

说了那么多选型，不亲手跑一遍始终是纸上谈兵。这一节我给出一个完整可复现的 Demo：本地部署 Ollama，用 Spring AI 官方主项目接入，把一份测试文档变成可以被检索的知识库，最终做成一个简单的 RAG 问答接口。

4.1 环境准备：JDK、Maven、Ollama

我的本地环境是：

• JDK 17+
• Maven 3.9+
• Ollama（本地模型运行工具，下载后一条命令就能拉起模型）
• Spring Boot 3.4 左右 + Spring AI 1.0 M 系列

先装 Ollama。装好后在命令行拉两个模型：一个聊天模型，一个 embedding 模型。我用的是：

ollama pull qwen2.5:3b ollama pull bge-m3

这里稍微解释一下为什么要两个模型。在 RAG 链路里，embedding 模型负责把文档切片变成向量存起来，聊天模型负责根据用户的提问生成回答。两者职能不同，不能混用。

提示：如果你的机器内存小于 16G，建议用更小的模型，比如 qwen2.5:1.5b。模型跑起来后内存占用会明显上升，别等 OOM 了再回头调。

4.2 创建工程与依赖配置

新建一个 Spring Boot 工程，在pom.xml里加 Spring AI 相关依赖。这里非常关键：Spring AI 的版本迭代比较快，不同版本之间的配置项经常有变化，不要盲抄老博客。我用的 BOM 管理版本，这样能最大程度避免依赖冲突。

<dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-bom</artifactId> <version>1.0.0-M6</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-ollama-spring-boot-starter</artifactId> </dependency> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-vector-store-simple</artifactId> </dependency> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-tika-document-reader</artifactId> </dependency> </dependencies>

spring-ai-tika-document-reader用来解析 PDF、Word、Markdown 等文档，Demo 阶段有它非常省事。

4.3 配置 application.yml

Spring AI 对接 Ollama 的配置集中在application.yml里，核心就三块：Ollama 服务地址、聊天模型名、embedding 模型名。

server: port: 8080 spring: ai: ollama: base-url: http://localhost:11434 chat: options: model: qwen2.5:3b temperature: 0.7 embedding: options: model: bge-m3

这份配置的含义是用默认的 Ollama 服务地址，聊天走qwen2.5:3b，向量化走bge-m3。这些配置项在官方文档里都有对应说明，但不同小版本的命名可能略有差异，所以还是那句话，以你实际引入的版本源码为准。

4.4 核心代码实现

我的代码分成三部分：向量库初始化、知识库写入、问答接口。

向量库存放切好的文档向量。Demo 阶段用 SimpleVectorStore，它在内存里跑，重启后数据就没了。要想持久化，后面可以换成 Redis 或其它向量库。

@Configuration public class RAGConfig { @Bean public SimpleVectorStore simpleVectorStore(EmbeddingModel embeddingModel) { return SimpleVectorStore.builder(embeddingModel).build(); } @Bean public ChatClient chatClient(ChatClient.Builder builder) { return builder.build(); } }

接着写一个服务类，读取文档、切片、写入向量库。切片的逻辑可以先用最简单的方式：按固定长度切，每段之间留一些重叠。这个 Demo 里我直接按段落切，更贴近实际场景。

@Service public class KnowledgeService { private final SimpleVectorStore vectorStore; private final EmbeddingModel embeddingModel; public KnowledgeService(SimpleVectorStore vectorStore, EmbeddingModel embeddingModel) { this.vectorStore = vectorStore; this.embeddingModel = embeddingModel; } public void load(String filePath) throws IOException { DocumentReader reader = new TikaDocumentReader(new FileSystemResource(filePath)); List<Document> documents = reader.get(); List<Document> splitDocs = documents.stream() .flatMap(doc -> splitByParagraph(doc).stream()) .toList(); List<Document> documentsWithEmbeddings = this.embeddingModel.embed( splitDocs, EmbeddingOptions.EMPTY, null); vectorStore.add(documentsWithEmbeddings); } private List<Document> splitByParagraph(Document doc) { String[] paragraphs = doc.getText().split("\\n\\s*\\n"); return Arrays.stream(paragraphs) .filter(p -> p.trim().length() > 20) .map(p -> Document.builder().text(p.trim()).build()) .toList(); } }

上面这段代码里，embed这个方法最容易忽略：它负责把每个文档切片的文本转成向量，并回写到 Document 对象里，这样vectorStore.add才能存到正确的向量。不少人在这一步漏掉，导致检索时报“文本没有 embedding”的错误。

再写问答接口。RAG 的原理很简单：用户提问后，先去向量库里检索跟问题最相关的几个切片，把它们拼进 Prompt 里，再把整个 Prompt 发给大模型。

@Service public class ChatService { private final ChatClient chatClient; private final SimpleVectorStore vectorStore; public ChatService(ChatClient chatClient, SimpleVectorStore vectorStore) { this.chatClient = chatClient; this.vectorStore = vectorStore; } public String ask(String question) { String prompt = createPrompt(question); return chatClient.prompt(prompt).call().content(); } private String createPrompt(String question) { List<Document> similarDocs = vectorStore.similaritySearch( SearchRequest.builder(question).withTopK(3).build() ); String context = similarDocs.stream() .map(Document::getText) .collect(Collectors.joining("\n\n---\n\n")); return """ 请基于以下参考资料回答用户问题。 如果资料中没有相关内容，请明确表示不知道。 参考资料： %s 用户问题： %s """.formatted(context, question); } }

最后加一个简单的 Controller 暴露接口：

@RestController public class ChatController { private final ChatService chatService; private final KnowledgeService knowledgeService; public ChatController(ChatService chatService, KnowledgeService knowledgeService) { this.chatService = chatService; this.knowledgeService = knowledgeService; } @PostMapping("/load") public String load(@RequestParam String path) throws IOException { knowledgeService.load(path); return "loaded"; } @PostMapping("/ask") public String ask(@RequestParam String question) { return chatService.ask(question); } }

4.5 跑起来验证效果

启动服务后，先在本地准备一份测试文档，比如一个 Markdown 文件，里面写几个只有该文档才有的冷门知识点。然后按顺序调用两个接口：

curl -X POST "http://localhost:8080/load?path=/tmp/test.md" curl -X POST "http://localhost:8080/ask?question=这个系统的默认超时时间是多少？"

重点看回答内容。如果知识库里没有相关内容，模型大概率会给你编一个答案；而接入了 RAG 后，它应该能从文档切片中检索到对应段落，并给出有出处的回答。这个对照实验比看一百篇文章都更能让你理解 RAG 的价值。

我当时跑通这个 Demo 的时候还顺手测了一件事：改文档内容后不重新加载，看看模型会不会检索到旧数据。答案是会的，因为旧向量还留在内存里。这提醒我，真实项目里知识库的更新机制必须单独设计，否则系统就是个“只会读旧知识的笨机器人”。

5. 实战排查：这 8 个问题我踩过，别走老路

Demo 能一次跑通是运气，跑不通才是常态。这一节我把我遇到的问题整理成速查表，再挑三个典型详细展开。

5.1 问题速查表

5.2 最容易翻车的三个点

先说维度不匹配。我在初学的时候，第一次用的 embedding 模型叫nomic-embed-text，后来换成了 bge-m3，结果发现向量维度变了，旧索引查不到，内存向量库里全是脏数据。这个坑的教训是：向量数据库不是换了模型就能无缝迁移的，生产环境一定要在设计之初就确定好 embedding 模型，升级要走数据重建流程。

第二个容易翻车的点是文档切片质量问题。切得太碎，每段信息不完整，检索出来上下文不连贯；切得太粗，单段超长，embedding 的效果急剧下降。我后来用“按段落切 + 控制长度上限 + 相邻段落补 20 字重叠”的策略，准确率才明显上来。技巧听起来简单，但很多人就是不愿花这十分钟调，宁可去买更贵的模型。

第三个是生产化问题。SimpleVectorStore 在 Demo 里非常棒，但真实业务里数据量一上来，内存直接吃紧，而且服务一重启知识全丢。我在某个模拟项目里换成了 Redis 的向量检索模块后，内存和重启问题同时解决了。所以我的建议是：项目一开始就可以把向量库抽象成接口，别把 Demo 里的内存实现当成最终方案。

5.3 给想直接上生产的同学加餐

除了排查问题，我再说一个真实项目里比模型更影响上线的环节：超时和重试。

大模型接口调用普遍比普通 HTTP 接口慢，动辄几秒到几十秒。如果直接用默认的 HTTP 配置，很容易遇到超时。我当时解决的方式非常简单，给 RestClient 设置了连接超时和读取超时，读取超时给了 60 秒。不要小看这个配置，很多人上线后才发现生产环境的慢响应跟模型没半点关系，纯粹是客户端等不起。另外，对模型接口做重试也要格外小心，因为大模型接口不是幂等的，用户可能已经收到了一半回答，你再重试一次就会重复生成。这种场景更适合做“断点续传”或“用户主动重试”，而不是盲目自动重试。

还有一点，SSE 流式输出在企业场景里是非常容易被忽略的刚需。如果用户界面需要打字机效果，后端必须用流式响应，把模型输出的 event 不停推给前端。Spring AI 对 SSE 的支持很成熟，但前端的 EventSource 和后端的响应格式必须测试对齐，不然前端收到的数据总是少了最后一行。

用几句真实体会收尾

这篇文章从 Spring AI Alibaba 停更聊开，到最后变成了一份 Java AI 落地的实操笔记。说到底，我的想法很简单：不要把“某个框架停更”当成职业危机，也不要把“语言热度”当成技术准绳。Java 在 AI 时代的价值，不在于追着热点跑，而在于它足够稳，能把模型能力真正变成业务流程的一部分——稳，本身就是一种很难替代的优势。

补充一个我近期的体会：从 Spring AI 官方主项目新增的 Function Calling 和消息记忆机制入手，可以试着把一个内部系统逐步升级成多 Agent 应用。这个过程里你会接触到工具调用、状态管理、并发编排这些硬核问题，而它们恰好是 Java 后端的老本行。走完这一步，你对“Java 还能不能做 AI”这个问题，就不再需要任何人的答案了。