企业官网建设流程全解析

1. 一个框架停更引发的技术选型焦虑

前几天在技术群里看到有人转了一篇文章，标题大意是某个Java生态的AI框架停更了，底下评论区直接炸了锅。有人说“Java做AI本来就没戏”，有人说“赶紧转Python吧”，还有人翻出几年前“Java已死”的老梗重新炒了一遍。我当时正在用Java写一个RAG检索增强生成的服务端模块，看到这些讨论的第一反应是：停更一个框架，跟Java能不能做AI，这是两个完全不同的问题。

先把事情说清楚。Spring AI Alibaba这个项目，是Spring生态里针对AI能力集成的一个尝试，主要做的是把大模型调用、向量检索、对话记忆这些能力封装成Spring风格的Bean和Template，让Java开发者能用自己熟悉的方式接入AI能力。它停更了，意味着这个特定的封装层不再维护了，但不意味着Java语言本身失去了做AI应用的能力，更不意味着你手里的Java项目就得推倒重来。

这篇文章想聊的不是“Java还有没有希望”这种情绪化的命题，而是从一个实际在做Java AI应用开发的人的角度，把这件事拆开来看：一个框架停更到底影响了什么？Java在AI应用层的真实定位是什么？如果你正在用或者打算用Java做AI相关的服务端开发，接下来该怎么选型、怎么落地、怎么避坑。文章会涉及具体的替代方案、实操步骤、参数配置和排查经验，适合正在做企业级AI应用后端开发的Java工程师，也适合技术负责人做选型参考。

2. 框架停更到底意味着什么

2.1 停更影响的是封装层，不是底层能力

很多人把“框架停更”和“技术路线死亡”画等号，这个判断在AI应用开发这个领域尤其容易出错。原因很简单：Java做AI应用，从来不是靠某一个框架活着的。

你调用大模型的HTTP接口，用的是Java的HttpClient或者OkHttp，这跟框架没关系。你做向量检索，底层可能是Milvus、PgVector或者Elasticsearch，Java有对应的SDK，这跟框架也没关系。你做文档解析、文本分块、Prompt模板管理，这些都是普通的Java代码逻辑，更不依赖某个特定的AI框架。

Spring AI Alibaba做的事情，是把上面这些能力用Spring的风格串起来——自动配置、依赖注入、声明式调用。它停更了，你失去的是一层“胶水”，不是“发动机”。胶水可以换，发动机还在。

我自己的项目里，大模型调用走的是自己封装的Client，向量库用的是PgVector配合JDBC，对话记忆存在Redis里。这套东西没有任何一行代码依赖Spring AI Alibaba。所以看到停更消息的时候，我的第一反应是“哦”，而不是“完了”。

2.2 停更的常见原因与判断标准

一个开源项目停更，原因通常就那么几类：维护者精力不够、社区活跃度下降、上游依赖发生重大变化、商业公司战略调整。Spring AI Alibaba的情况，从外部观察来看，更多是生态定位和投入产出的问题——Spring官方有自己的Spring AI项目在推进，国内这个分支的差异化价值被压缩了。

这里给一个判断标准，帮你区分“需要紧张”和“不用紧张”：

Spring AI Alibaba属于第一类。它的底层——大模型API、向量数据库、Spring框架本身——都活得好好的。你真正需要担心的是：你项目里有没有深度绑定它的特有API？如果有，迁移成本有多大？如果没有，换一个封装层或者自己写一层，工作量可能比你想的小得多。

2.3 Java在AI应用层的真实定位

这里必须把一件事说透：Java在AI领域的定位，从来就不是“训练模型”，而是“承载AI能力的业务系统”。

训练模型、做实验、跑Notebook，这些场景Python是绝对优势，没必要争。但当一个AI能力要变成7x24小时运行的企业服务时，情况就变了。你需要的是：高并发处理、事务一致性、成熟的监控体系、稳定的线程池管理、完善的权限控制、跟现有业务系统的无缝集成。这些恰恰是Java生态积累了二十年的强项。

我接触过的几个实际落地的AI项目，前端是Python做的原型验证，后端服务全部是Java。原因很现实：业务系统是Java写的，订单、用户、权限、审计都在Java这边，AI能力要嵌入进去，用Java是最短路径。你不可能为了调一个大模型接口，把整个订单系统用Python重写一遍。

所以“Java还有希望吗”这个问题，问反了。应该问的是：在AI应用层，Java的哪些能力是Python替代不了的？答案是：工程化能力、生态成熟度、团队现有技能栈的复用。这三样东西，不会因为一个框架停更就消失。

3. Java AI应用开发的核心技术点拆解

3.1 大模型调用的Java实现方式

不管你用什么框架，调用大模型API的本质就是发HTTP请求。Java里做这件事，最稳妥的方式是用java.net.http.HttpClient（JDK 11+）或者OkHttp。下面是一个不依赖任何AI框架的调用示例：

import java.net.URI; import java.net.http.HttpClient; import java.net.http.HttpRequest; import java.net.http.HttpResponse; import java.time.Duration; public class LlmClient { private final HttpClient httpClient; private final String apiKey; private final String endpoint; public LlmClient(String apiKey, String endpoint) { this.apiKey = apiKey; this.endpoint = endpoint; this.httpClient = HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(10)) .build(); } public String chat(String prompt) throws Exception { String body = """ { "model": "your-model-name", "messages": [ {"role": "user", "content": "%s"} ], "temperature": 0.7 } """.formatted(prompt.replace("\"", "\\\"")); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(endpoint)) .header("Content-Type", "application/json") .header("Authorization", "Bearer " + apiKey) .timeout(Duration.ofSeconds(60)) .POST(HttpRequest.BodyPublishers.ofString(body)) .build(); HttpResponse<String> response = httpClient.send(request, HttpResponse.BodyHandlers.ofString()); return response.body(); } }

这段代码没有任何框架依赖，JDK自带的能力就够了。你可能会说“这也太原始了”，但正是这种原始，让你不会被任何框架绑架。在这个基础上，你可以自己加连接池、重试、熔断、日志，用你熟悉的任何Java工具。

注意：上面代码里的temperature参数控制输出的随机性。做事实性问答建议设0.1到0.3，做创意生成可以设0.7到0.9。这个参数不是框架提供的，是模型API本身的，换任何框架都一样。

3.2 向量检索与RAG的Java落地

RAG（检索增强生成）是目前企业级AI应用最主流的架构。它的核心流程是：把文档切块、向量化、存入向量库，查询时先检索相关块，再把检索结果拼进Prompt送给大模型。

Java做这件事，关键在向量库的选择。我实际用过的方案里，PgVector是最省心的——你本来就有PostgreSQL的话，加个扩展就行，不用引入新的中间件。下面是核心的建表和查询逻辑：

-- 启用向量扩展 CREATE EXTENSION IF NOT EXISTS vector; -- 建表，向量维度根据你的embedding模型定，常见的是1536或768 CREATE TABLE doc_chunks ( id BIGSERIAL PRIMARY KEY, content TEXT NOT NULL, embedding vector(1536), metadata JSONB, created_at TIMESTAMP DEFAULT NOW() ); -- 建索引，加速检索 CREATE INDEX ON doc_chunks USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100); -- 检索查询 SELECT content, 1 - (embedding <=> $1) AS similarity FROM doc_chunks ORDER BY embedding <=> $1 LIMIT 5;

Java这边用JDBC就能操作，不需要任何AI框架。$1是查询文本的向量表示，<=>是余弦距离操作符。lists = 100这个参数，经验值是数据量的平方根左右，10万条数据设300左右比较合适，太小检索慢，太大精度下降。

文档分块这块，我踩过的坑最多。按固定字符数切是最简单的，但效果一般。比较实用的策略是：按段落切，每块控制在300到500字，块之间保留50字左右的重叠。重叠是为了避免一个完整的语义被切断。这个逻辑用Java写就是一个普通的字符串处理，不需要框架。

3.3 对话记忆与上下文管理

多轮对话需要保存历史消息。最直接的做法是存Redis，key用会话ID，value是消息列表的JSON。Java里用Jedis或者Lettuce都行。

这里有个容易忽略的点：上下文不是越长越好。大模型的上下文窗口有限，而且历史消息越多，token消耗越大，响应越慢。我的做法是保留最近N轮对话，N根据业务定，一般5到10轮。超出的部分做摘要压缩，把摘要作为系统消息放在最前面。

public class ConversationMemory { private final JedisPool jedisPool; private static final int MAX_ROUNDS = 8; public void addMessage(String sessionId, String role, String content) { try (Jedis jedis = jedisPool.getResource()) { String key = "conv:" + sessionId; String msg = String.format("{\"role\":\"%s\",\"content\":\"%s\"}", role, content.replace("\"", "\\\"")); jedis.rpush(key, msg); // 保留最近MAX_ROUNDS*2条消息（一问一答算两条） jedis.ltrim(key, -MAX_ROUNDS * 2, -1); jedis.expire(key, 3600 * 24); } } public List<String> getHistory(String sessionId) { try (Jedis jedis = jedisPool.getResource()) { return jedis.lrange("conv:" + sessionId, 0, -1); } } }

ltrim那行是关键，它保证列表不会无限增长。expire设置24小时过期，避免冷会话占内存。这些都是普通的Redis操作，跟AI框架无关。

3.4 流式输出的Java处理

大模型流式输出（SSE）能显著提升用户体验。Java处理SSE，用HttpClient的BodyHandlers.ofLines()就能做到：

HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(endpoint)) .header("Accept", "text/event-stream") .POST(HttpRequest.BodyPublishers.ofString(body)) .build(); httpClient.sendAsync(request, HttpResponse.BodyHandlers.ofLines()) .thenAccept(response -> response.body() .filter(line -> line.startsWith("data: ")) .map(line -> line.substring(6)) .filter(data -> !"[DONE]".equals(data)) .forEach(data -> { // 解析JSON，提取delta内容，推送给前端 System.out.print(extractContent(data)); }));

这段代码用到了sendAsync和ofLines，是JDK 11+的标准能力。流式输出的难点不在Java这边，在于前端的SSE接收和服务端的背压处理。如果并发量大，建议在中间加一层消息队列做缓冲。

4. 替代方案选型与迁移实操

4.1 三条可行的技术路线

Spring AI Alibaba停更后，摆在面前的路其实有三条，每条都有各自的适用场景：

路线一：转向Spring AI官方项目。Spring官方在推自己的AI集成模块，API风格跟原来的Alibaba版本有相似之处，迁移成本相对可控。适合深度使用Spring生态、希望继续用声明式风格的团队。需要注意的是官方项目的版本迭代节奏，以及它对国内模型服务的支持程度。

路线二：自建轻量封装层。把大模型调用、向量检索、对话记忆这几个核心能力，用自己团队熟悉的模式封装成Service。工作量大概在3到5人天，换来的是完全可控、无外部依赖。适合对稳定性要求高、团队有一定架构能力的场景。

路线三：混合方案。核心链路自建，边缘能力用成熟的开源库。比如向量检索直接用PgVector的JDBC，文档解析用Apache Tika，Prompt管理自己写。适合大多数中小团队。

我自己的选择是路线二加路线三的组合。原因很直接：AI应用的核心链路其实不复杂，自建的成本远低于被框架绑架的风险。下面重点讲自建方案的关键步骤。

4.2 自建封装层的具体步骤

第一步，定义核心接口。不要一上来就写实现，先把契约定清楚：

public interface LlmService { String chat(String sessionId, String userMessage); void chatStream(String sessionId, String userMessage, Consumer<String> onToken); } public interface VectorService { void index(String docId, String content, Map<String, Object> metadata); List<SearchResult> search(String query, int topK); } public interface EmbeddingService { float[] embed(String text); List<float[]> embedBatch(List<String> texts); }

这三个接口覆盖了RAG应用的核心能力。接口定好之后，实现可以随时替换，今天用A方案，明天换B方案，上层业务代码不用动。

第二步，实现Embedding服务。Embedding就是把文本转成向量，调用的是模型服务商的embedding接口。这里要注意批量处理，单条调用太慢。一般服务商支持一次传几十条文本，批大小设16到32比较稳妥。

第三步，实现向量检索。用PgVector的话，核心就是前面那段SQL。Java这边用PreparedStatement传向量参数，注意向量的字符串格式是[0.1,0.2,0.3]这样。

第四步，串联RAG流程。查询时先embed查询文本，再检索topK个相关块，拼成Prompt，调用大模型。这个流程用普通的Service编排就行，不需要什么框架。

4.3 迁移过程中的参数对照

从框架迁移到自建，最容易出问题的是参数对照。原来框架里配置的那些参数，到了自建方案里对应什么，需要一个个理清楚：

提示：向量维度这个坑我踩过。换了embedding模型之后，维度从1536变成768，但表结构没改，插入直接报错。迁移时第一件事就是确认维度，然后决定是改表还是换模型。

4.4 什么情况下不建议自建

自建不是万能药。如果你的团队满足以下条件，建议还是用成熟框架：团队Java架构经验不足、项目周期极紧、只需要最基础的对话功能、没有专人维护基础设施。自建意味着你要自己处理连接池泄漏、重试风暴、向量库调优这些问题，没有一定经验容易翻车。

我的判断标准是：如果AI能力是你产品的核心差异化，自建；如果只是锦上添花的功能，用框架。核心的东西必须可控，边缘的东西可以妥协。

5. 实操中的常见问题与排查技巧

5.1 大模型调用超时与重试

超时是最高频的问题。表现是请求发出后长时间无响应，最后抛TimeoutException。原因通常有三类：网络问题、模型服务端排队、请求体太大。

排查顺序：先看请求体大小，超过10KB的Prompt要警惕；再看超时设置，读取超时建议60秒起步，复杂推理任务设120秒；最后看是不是并发太高被限流。

重试要谨慎。大模型调用不是幂等的场景下（比如已经产生了计费），盲目重试会造成重复扣费。我的做法是只对连接超时重试，读取超时和4xx错误不重试。重试次数最多2次，间隔用指数退避。

public String chatWithRetry(String prompt, int maxRetries) { int attempt = 0; while (attempt <= maxRetries) { try { return chat(prompt); } catch (ConnectException e) { attempt++; if (attempt > maxRetries) throw new RuntimeException("重试耗尽", e); try { Thread.sleep((long) Math.pow(2, attempt) * 1000); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); throw new RuntimeException("重试被中断", ie); } } catch (Exception e) { // 非连接类异常不重试 throw new RuntimeException("调用失败", e); } } throw new IllegalStateException("不应到达"); }

5.2 向量检索结果不相关的排查

RAG最常见的抱怨是“检索出来的东西跟问题不相关”。这个问题要分三层排查：

第一层，embedding质量。同一个语义的文本，embedding之后的余弦相似度应该在0.8以上。如果低于这个值，说明embedding模型不适合你的领域，考虑换模型或者做微调。

第二层，分块策略。块太大，一个块里混了多个主题，检索精度下降；块太小，语义不完整，检索召回率低。我的经验值是中文300到500字一块，英文200到400词一块。

第三层，相似度阈值。设太高，召回不足；设太低，噪声太多。建议先用0.7做基线，根据实际效果上下调整。可以做一个简单的评估：准备20个问题和对应的标准答案块，看检索结果里有多少是相关的，算出准确率再调参。

5.3 并发场景下的资源管理

AI应用的并发模型跟普通Web服务不太一样。大模型调用是长耗时操作，一个请求可能占用几秒到几十秒。如果用默认的Tomcat线程池，并发一上来线程就被占满了。

我的做法是把AI调用放到独立的线程池，跟Web请求线程隔离：

@Configuration public class AiExecutorConfig { @Bean("aiExecutor") public ThreadPoolExecutor aiExecutor() { return new ThreadPoolExecutor( 10, // 核心线程数 50, // 最大线程数 60L, TimeUnit.SECONDS, // 空闲回收时间 new LinkedBlockingQueue<>(200), // 队列容量 new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 ); } }

核心线程数按“平均QPS × 平均耗时”估算。比如QPS是5，平均耗时3秒，那核心线程至少15个。队列容量不要设太大，否则请求堆积，用户等太久。拒绝策略用CallerRuns，让调用方自己执行，起到背压作用。

5.4 常见问题速查表

注意：上面这些问题的排查，都不依赖任何AI框架。你需要的只是Java的调试能力和对AI调用链路的理解。框架能帮你省一些样板代码，但排查问题的能力是你自己的。

6. 我对Java做AI应用的一些实际体会

做了几个Java AI项目之后，我最大的体会是：这个领域的门槛不在语言，在工程。Python在AI领域的优势是生态和实验便利性，但到了生产环境，Java的工程能力反而是稀缺的。我见过太多Python原型跑得飞起、一上生产就各种问题的案例，也见过Java团队用最朴素的方式把AI服务做得稳稳当当。

框架停更这件事，放在这个背景下看，其实是个好事。它逼着你去理解底层到底发生了什么，而不是停留在“调个注解就完事”的层面。我自己的封装层写了大概800行代码，覆盖了调用、检索、记忆、流式输出，维护成本极低，而且完全可控。这800行代码的价值，比依赖一个随时可能停更的框架要高得多。

如果你正在纠结要不要继续用Java做AI，我的建议是：先问自己一个问题——你的AI能力是要嵌入现有Java业务系统，还是要做一个独立的AI产品？如果是前者，Java几乎是唯一合理的选择，框架停更只是换条路走的问题。如果是后者，那确实可以评估Python方案，但也要考虑团队技能栈和长期维护成本。

最后分享一个我一直在用的小技巧：把大模型调用、embedding、向量检索这三个能力做成独立的、可替换的模块，每个模块只暴露一个接口。这样无论底层用什么框架、什么服务商，上层业务代码永远不用改。这个原则让我在过去两年里换了三次底层实现，业务代码一行没动。框架会停更，服务商会变更，但好的架构设计能让你始终掌握主动权。