1. 停更公告一出來很多Java人的第一反應(yīng)前幾天社區(qū)里傳得沸沸揚(yáng)揚(yáng)的一件事就是Spring AI Alibaba這個項目被標(biāo)記為停止維護(hù)了。說實話我第一眼看到這個消息的時候心里也咯噔了一下畢竟這個項目承載了很多Java開發(fā)者對AI時代的期待。在它剛開源那陣子大家覺得Java終于有一個像樣的AI開發(fā)框架了能對接大模型、能做Agent、能搞RAG好像Java在AI領(lǐng)域終于要支棱起來了。結(jié)果停更的消息一出來討論區(qū)里的氛圍就變得很微妙。有人直接說“Java這下徹底沒戲了”也有人翻出歷史說Java在AI領(lǐng)域從來都是落后分子現(xiàn)在連官方背書的項目都不維護(hù)了更說明問題。還有一種聲音比較冷靜說“Spring AI Alibaba本身只是某個大廠開源的中間件停更并不代表整個Java生態(tài)死亡關(guān)鍵看替代品”。我屬于最后一種但我也理解前面那兩種心情。因為這幾年Java開發(fā)者確實憋屈過。眼看著Python那邊從語言到框架一整套AI工具鏈TensorFlow、PyTorch、LangChain、LlamaIndex全是用Python寫的。訓(xùn)練模型做實驗不用說連調(diào)大模型的API都要先查Python的示例代碼Java版要么沒有要么落后好幾個版本。很多Java團(tuán)隊做AI項目最后都變成了“Java做后臺Python寫AI腳本中間掛HTTP服務(wù)”這種怪異的拆法。所以Spring AI Alibaba的停更表面上是一個項目的生命周期問題實際上是點燃了Java人心中積壓已久的焦慮。這個焦慮不是今天才有的但這次是真的被放到了臺面上。2. 為什么Java的AI生態(tài)總是“慢半拍”要搞清楚Java在AI領(lǐng)域還有沒有希望得先弄明白Java為什么在這輪大模型浪潮里存在感這么弱。這不是一句“Python更好用”就能糊弄過去的背后有幾個很實在的原因。2.1 歷史包袱和領(lǐng)域分工的錯位Java本身是為企業(yè)級應(yīng)用而生它的核心優(yōu)勢在于穩(wěn)定、跨平臺、類型安全、生態(tài)成熟適合構(gòu)建大規(guī)模分布式系統(tǒng)。而AI或者說機(jī)器學(xué)習(xí)領(lǐng)域從一開始就生長在一個實驗驅(qū)動的文化里。研究人員需要快速迭代、即時驗證想法Python解釋執(zhí)行、動態(tài)類型、膠水語言的優(yōu)勢簡直是為這個場景量身定做的。這不是哪個語言更優(yōu)越的問題是分工不同。就像廚師和面點師一個管熱菜一個管主食你不能說面點師不會爆炒就是有問題。Java在服務(wù)端、中間件、大數(shù)據(jù)處理這些領(lǐng)域依舊是絕對主力。別的不說Spark、Flink這些大數(shù)據(jù)計算框架底層都是JVM系它們也承擔(dān)了大量機(jī)器學(xué)習(xí)工作流里的數(shù)據(jù)處理部分。但問題在于大模型時代前沿的研究和工具鏈幾乎全是在Python社區(qū)先跑通的Java再想追始終差著一個“先發(fā)時間差”。2.2 JVM本身的“重”與AI場景的“輕”另外JVM的學(xué)習(xí)曲線和啟動成本也是讓不少AI團(tuán)隊望而卻步的原因。寫Python的開發(fā)者用Jupyter Notebook拉個Notebook就能跑實驗寫Java的要配Classpath、Maven/Gradle依賴、處理一堆容器配置。不是說不能做而是前期摩擦成本太高。尤其在模型推理階段Python雖然性能不是最強(qiáng)的但跟PyTorch、Hugging Face這些庫是無縫銜接的Java這邊想加載一個模型得想辦法繞道ONNX或者用DJL總感覺中間隔了一層。大模型時代還有一個特殊現(xiàn)象很多創(chuàng)新發(fā)生在開源模型和API的調(diào)用層面。這一層本身就是極其輕量的無非是把Prompt組裝好發(fā)個HTTP請求拿到流式響應(yīng)做一個對話管理。這種場景下語言本身的“心智負(fù)擔(dān)”就顯得很關(guān)鍵。Python用幾行代碼就能完成的演示Java要寫一個類、定義DTO、弄好依賴注入體驗差距自然很明顯。不過這只是在“立刻編寫小demo”的層面。如果要做嚴(yán)肅的企業(yè)級AI服務(wù)穩(wěn)定性、并發(fā)、運(yùn)維、監(jiān)控、灰度發(fā)布Java反而又有了用武之地。這就是當(dāng)前局面的矛盾之處輕量開發(fā)不如Python重量級落地又不見得一定輸。2.3 大廠開源項目的節(jié)奏問題我們再回頭看看Spring AI Alibaba本身。它其實是某云廠商在Spring AI基礎(chǔ)上做的一套增強(qiáng)組件把云上的模型接入、RAG實現(xiàn)、Agent框架都做了整合。這類項目通常綁定大廠自家的云服務(wù)和商業(yè)利益如果內(nèi)部戰(zhàn)略調(diào)整、投入產(chǎn)出比不高或者跟集團(tuán)的產(chǎn)品方向沖突被裁撤是再正常不過的事情。我做過幾年開源項目維護(hù)實在太理解這種事。開源項目最大的風(fēng)險往往不是技術(shù)做不出來而是背后的商業(yè)組織變主意。今天想搶占AI賽道明天覺得ROI不行就砍掉了。Spring AI Alibaba不是第一個倒下的也絕不是最后一個。所以收到這個壞消息時我第一反應(yīng)不是“Java完了”而是“哦又一個大廠戰(zhàn)略上的棄子意料之外卻是情理之中”。但停更歸停更代碼還在那它跟OpenAI、阿里云的模型網(wǎng)關(guān)的對接邏輯還是可以拿來學(xué)的甚至你完全可以Fork一份自己維護(hù)。開源的意義本來就在這里項目停了不表示它的思想死了。3. 停更不代表沒有希望Java側(cè)還能打的牌聊完了焦慮和原因該進(jìn)入正題了。Java在AI領(lǐng)域到底還有沒有牌可打我的答案是有而且比我之前想象的多。咱們一張一張來看。3.1 官方Spring AI不是還活著而且活得挺好先看Spring官方的Spring AI。這個項目和Spring AI Alibaba不是一回事它是Spring生態(tài)下的正規(guī)軍目前還在積極迭代目標(biāo)是成為Spring生態(tài)里的AI開發(fā)標(biāo)準(zhǔn)。很多人一看到Alibaba停更就誤以為Spring AI也沒了這是個很大的誤區(qū)。Spring AI做的事情是把大模型接入抽象成類似Spring Data的風(fēng)格讓你通過簡單的配置和注解就能調(diào)用不同廠商的大模型并且提供了一套用于RAG的嵌入模型、向量存儲抽象以及用于工具調(diào)用的API。它的角色更像一個“AI版JDBC”你不需要關(guān)心底層對接的是OpenAI還是Qwen百煉或通義千問統(tǒng)一走一套接口。我最近在項目里用Spring AI對接一個國產(chǎn)大模型配置完依賴之后核心代碼只寫了不到二十行。StreamingChatModel的流式接口做得特別舒服返回一個Flux往WebFlux里一接前端能直接看到打字機(jī)效果。這種體驗已經(jīng)不比Python那邊差了。當(dāng)然Spring AI也不是沒有問題。它的抽象層有時候過于“框架化”你想做一點非常規(guī)的Prompt操作時會覺得被繞來繞去。而且文檔更新特別快版本兼容性容易踩雷比如當(dāng)時我用的版本和Spring Boot 3.3之間的依賴注入方式有變化查了不少issue才解決。但無論如何它在活躍維護(hù)只要你愿意花時間去適應(yīng)它的設(shè)計Java做AI應(yīng)用的復(fù)雜度完全可以降下來。3.2 LangChain4j更貼近AI原生的Java庫如果說Spring AI是一板一眼的“Spring風(fēng)格”AI框架那LangChain4j更像是把LangChain那套理念移植到了Java世界。它支持對話模型、嵌入模型、文本分塊、RAG、記憶窗口、Agent、工具調(diào)用幾乎覆蓋了LangChain的所有核心概念。LangChain4j最討喜的地方是它不像Spring AI那樣綁定Spring容器。你可以把它用在Spring Boot里也可以用在無法使用Spring上下文的輕量級Java服務(wù)里或者直接在純Java命令行工具里跑。API設(shè)計上也更貼近AI概念比如ChatMemory、AiServices這些類用起來就像在操作一個普通Java對象不覺得自己是在跟一堆抽象規(guī)范較勁。我自己用LangChain4j寫過一個材料歸檔助手把PDF轉(zhuǎn)成文本、分塊、向量化、存入本地向量庫然后再接對話模型做問答。整個鏈路跑通只花了一個周末。而且文檔里的中文資料雖然不算多但代碼示例很清晰抄作業(yè)難度不大。如果你的目標(biāo)是快速做一個AI功能不太想被Spring全家桶的配置拖累LangChain4j目前算是Java領(lǐng)域里最靠譜的選擇之一。3.3 底層硬核路線DJL和ONNX Runtime聊完了應(yīng)用框架再往底層看一眼。Java其實也不是沒有直接跑模型的途徑推薦兩個方向。一個是亞馬遜開源的DJLDeep Java Library它的設(shè)計愿景就是讓Java開發(fā)者用原生Java寫深度學(xué)習(xí)模型推理和訓(xùn)練。DJL支持在JVM上加載PyTorch、TensorFlow、MXNet等格式的模型底層自動通過合適的Native引擎來執(zhí)行。雖然訓(xùn)練這塊跟Python還是有差距但做推理部署綽綽有余。另一個是ONNX Runtime的Java綁定。ONNX是一種開放的模型交換格式pytorch訓(xùn)練出來的模型可以導(dǎo)出成onnx文件然后Java直接加載運(yùn)行。我在邊緣設(shè)備上試過一個BERT中文分類模型導(dǎo)出成onnx后打包成Spring Boot服務(wù)單機(jī)QPS能達(dá)到一千多內(nèi)存占用居然比Python的Flask服務(wù)還穩(wěn)定。如果你需要高性能、低延遲的模型推理這條路是可以走通的。這種方案的缺點是屬于“自己拼積木”沒有像LangChain那套開箱即用的開發(fā)體驗。但你獲得的自由度非常高不受框架的思維限制。對于核心AI能力要求高、又必須用Java技術(shù)棧統(tǒng)一維護(hù)的團(tuán)隊來說DJL加ONNX的組合是一個很扎實的備選方案。3.4 云廠商SDK與大模型網(wǎng)關(guān)還有一個容易被忽視的選項就是各大云廠商提供的Java SDK。說實話現(xiàn)在幾乎所有國內(nèi)主流云廠商的模型服務(wù)平臺都提供Java SDK用起來非常簡單就是封裝好的HTTP客戶端支持同步、異步和流式調(diào)用。有些團(tuán)隊會覺得既然我用Java調(diào)用模型API直接用okhttp調(diào)不就行了為什么還要用SDK但官方SDK的價值在于它會幫你處理好鑒權(quán)、重試、限流、模型名稱映射這些麻煩事。而且如果你用了某個云廠商的整個人工智能平臺的增值能力比如模型評估、Agent運(yùn)行時那SDK就是不可缺失的。我自己現(xiàn)在還接了好幾個項目都是直接用云廠商SDK對接大模型壓根沒用上層框架。好處是可控性強(qiáng)改動面向API層升級不影響業(yè)務(wù)代碼。壞處是你得自己寫一些公共邏輯比如異常處理、上下文拼接、Token計數(shù)、流式中的事件解析。這些邏輯也不算復(fù)雜就是需要細(xì)心如果團(tuán)隊人數(shù)不多我更傾向于用框架來降低重復(fù)勞動。3.5 千萬別忘了Java自身的龐大基座除了這些直接的AI工具外Java還有一個隱性優(yōu)勢它的存量生態(tài)極其龐大。幾乎每家公司都有Java或JVM系的后端服務(wù)。如果能讓AI能力像數(shù)據(jù)庫一樣被Java服務(wù)集成那傳播速度和落地效率將非?？捎^。這也就是Spring AI和LangChain4j這類框架最被看好的原因它們不需要你寫單獨(dú)的Python服務(wù)不用做跨語言網(wǎng)絡(luò)通信直接在現(xiàn)有業(yè)務(wù)代碼旁邊加幾個類就能讓系統(tǒng)具備AI能力。比如給客服系統(tǒng)增加一個知識庫問答助手用Java接好大模型和向量數(shù)據(jù)庫后直接把一個全新的Service類注入到原有的Spring Context中就完成了智能接入。這種融合式演進(jìn)才是Java在AI時代最核心的競爭邏輯。4. 我自己的實操經(jīng)驗用Java做一個AI功能需要跨過哪些坎上面說了很多理論上的牌面但真刀真槍干活的時候還是會遇到一些坑。我分享一下最近一個新的實踐——用Java寫一個私域知識庫的問答機(jī)器人看看整個鏈路是怎么落地的也算給各位一點參考。4.1 整體架構(gòu)先畫個最簡單的圖這個功能本身不復(fù)雜用戶在客服系統(tǒng)里提一個問題系統(tǒng)需要從公司內(nèi)部的FAQ文檔里找到相關(guān)段落拼進(jìn)Prompt然后丟給大模型生成回答。最簡情況下只需要三個組件一個全文檢索或向量檢索模塊、一個Prompt組裝模塊、一個模型調(diào)用模塊。我用LangChain4j來組織這一切。文檔存在PostgreSQL里向量存在本地的一個輕量級向量庫中模型調(diào)用接入的是某個云廠商的大模型API。整個服務(wù)是一個Spring Boot應(yīng)用核心類就兩個一個是文檔索引Service一個是問答Service。前者負(fù)責(zé)把原始文檔切片和向量化后者負(fù)責(zé)接收用戶問題、檢索相關(guān)向量、組裝Prompt、流式返回結(jié)果。4.2 依賴引入和配置引入依賴很簡單LangChain4j提供了針對不同模型廠商的獨(dú)立模塊我用的是社區(qū)版本加廠商模塊。在pom.xml里我只需要加三四個依賴比如langchain4j-core、langchain4j、langchain4j-open-ai用于兼容大部分OpenAI協(xié)議接口的模型網(wǎng)關(guān)以及一個嵌入模型的依賴。注意版本號一定要匹配否則啟動時會出現(xiàn)類找不到或者方法簽名不一致的問題。配置文件里主要是設(shè)置模型網(wǎng)關(guān)的Base URL、API Key、模型名稱以及向量庫的一些參數(shù)。不要在這里用敏感詞或真實密鑰建議從環(huán)境變量讀取防止泄露。雖然沒有把密鑰硬編碼這件事說爛了但我見過太多人圖省事直接寫在application.yml里然后提交倉庫的案例實在不推薦。4.3 構(gòu)建一個簡單的文檔索引流程索引流程可以分成四步讀文本、切塊、向量化、存庫。我測試時用了自己部門寫的操作手冊Docx文件先用一個解析工具把內(nèi)容轉(zhuǎn)成純文本然后調(diào)用文本分塊器每500個字符一段、重疊50個字符這樣避免語義被截斷。接著把每一段交給嵌入模型轉(zhuǎn)成向量數(shù)組存入向量存儲。這里有個容易踩的坑中英文混排的文本如果按固定字符長度切分很容易把中文詞句從中間切斷。我后來改用英文按詞切分、中文按標(biāo)點邊界優(yōu)先的方法效果好了不少。LangChain4j內(nèi)置了一個DocumentSplitter可以自定義拆分邏輯感覺比自己去寫正則更可靠。4.4 問答流程檢索段落的數(shù)量是個平衡問題問答Service的核心代碼大概長這樣public FluxString answer(String userQuestion) { // 1. 向量化用戶問題 Embedding questionEmbedding embeddingModel.embed(userQuestion).content(); // 2. 在存儲中查找最相似的段落 ListDocument docs vectorStore.findRelevant(questionEmbedding, 4); // 3. 組裝Prompt Prompt prompt promptBuilder(docs, userQuestion); // 4. 調(diào)用大模型流式返回 return chatModel.stream(prompt.toUserMessage()); }其實就是一個四步走但每一步都得打磨。最值得琢磨的是“檢索多少段”。我第一次直接把相關(guān)段落數(shù)設(shè)成10結(jié)果模型回答又臭又長還反復(fù)引用不相關(guān)的內(nèi)容。后來調(diào)成4回答質(zhì)量和速度都好了很多。這個東西沒有固定標(biāo)準(zhǔn)得根據(jù)你的文檔庫平均長度和問題類型測出來完全是一個經(jīng)驗活兒。還有一個細(xì)節(jié)把段落帶入Prompt時最好給每個段落一個編號然后讓模型在回答中引用對應(yīng)編號。這樣用戶可以看到這個回答是根據(jù)哪些文檔生成的可信度會高很多。LangChain4j的Prompt模板很好用支持占位符和條件控制可以不寫大量的字符串拼接。4.5 流式輸出與前端對接大模型回答通常比較慢一次性等它完整體會很影響用戶體驗。我選擇使用流式響應(yīng)后端返回Flux 控制器是Server-Sent Events代碼大概是這樣GetMapping(value /answer, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxString answer(RequestParam String q) { return qaService.answer(q) .map(content - data: content.replace(\n, ) \n\n); }前端用EventSource就能直接接不需要WebSocket也不需要用輪詢。這樣做的好處是用戶可以很快看到首字出現(xiàn)體感上比等待5秒才看到完整回答強(qiáng)得多。Java在流式處理方面本來就強(qiáng)這里反而能體現(xiàn)出JVM在并發(fā)和背壓上的功底。不過也碰到一個小坑如果模型流式輸出不穩(wěn)定偶爾會斷流。我在本地測試時發(fā)現(xiàn)某些Prompt會導(dǎo)致服務(wù)端返回網(wǎng)絡(luò)異常后來增加了一個重試機(jī)制只對“連接重置”和“超時”這類異常生效不會因為對方模型內(nèi)容判斷等原因盲目重試。重試時要注意上一次流式響應(yīng)已經(jīng)發(fā)送了一部分內(nèi)容不能直接重復(fù)拼接給用戶否則會看到斷裂的文本。解決方法是把重試放在最底層不讓部分token輸出到上層緩存只有完全成功才返回給前端。這個設(shè)計花了我一個下午算是很值得記住的經(jīng)驗。4.6 性能觀察和優(yōu)化這個功能上線后我看了下監(jiān)控平均響應(yīng)延遲在3秒左右前端首字出現(xiàn)在0.8秒內(nèi)。并發(fā)200的時候服務(wù)負(fù)載還能扛住遠(yuǎn)程過程調(diào)用線程池也控制得不錯。Java在這個場景下并沒有明顯劣勢。如果還要繼續(xù)優(yōu)化可以考慮緩存用戶問題向量減少一次剛建模型請求同時限制單用戶并發(fā)請求數(shù)量防止惡意調(diào)用。另外在回答內(nèi)容后加一個“AI生成僅供參考”的提示雖然不是技術(shù)活兒但在產(chǎn)品層面非常必要。5. 常見問題與避坑建議我把這段時間看到、聽到以及自己踩過的問題整理一下方便還在觀望的同事做個參考。5.1 到底要不要轉(zhuǎn)Python這是很多人問的第一個問題。我的觀點是如果你是學(xué)生或者未來規(guī)劃還模糊那學(xué)Python沒問題它確實更容易接近AI前沿。但如果你已經(jīng)是一個有多年經(jīng)驗的Java后端工程師完全不必因為一個框架停更就推倒重來。Java在企業(yè)服務(wù)、中間件、大數(shù)據(jù)領(lǐng)域的地位依舊穩(wěn)固AI只是業(yè)務(wù)系統(tǒng)里的一種新能力。你可以不理解模型的內(nèi)部數(shù)學(xué)原理但你完全可以用Java把AI服務(wù)穩(wěn)定地跑起來。更好的策略是“以Java為生以Python為工具”。你需要學(xué)一點Python不是為了轉(zhuǎn)行而是為了讀懂海量的AI代碼示例。大模型生態(tài)里最好的開源項目基本都是Python寫的研究型代碼你把這些代碼翻譯成Java設(shè)計或者提取核心邏輯用在Java服務(wù)里才能真正做到為我所用。5.2 老項目要不要從Spring AI Alibaba遷移出去這個要看你對停更的定義如果你只是需要一個“能跑、能對接大模型”的框架那停更前的代碼和文檔已經(jīng)足夠用你完全可以先不動。但如果你是在做新產(chǎn)品或者希望將來跟上社區(qū)最新的東西那遷移到Spring AI或LangChain4j是更穩(wěn)妥的選擇。遷移的時候我建議分步驟來。第一步把模型調(diào)用層抽出來不依賴任何具體框架的類。第二步把RAG相關(guān)的操作也抽象成自己的接口底層實現(xiàn)隨便切換。這樣不管以后底層用什么框架改動都限定在一個比較小的范圍內(nèi)。這也是老生常談的解耦但要真正執(zhí)行到底你得有意識地控制對第三方框架類型的依賴傳播。我見過太多項目一開始圖方便讓業(yè)務(wù)類直接繼承框架的基類到后面升級框架時簡直是一場災(zāi)難。5.3 用Java做AI是不是總得等模型輸出很慢不是。慢不慢大多取決于你選用的模型和網(wǎng)絡(luò)而不是語言。Java對響應(yīng)式編程的支持成熟結(jié)合WebFlux天然適合流式場景。Python的異步也可以用但有過生產(chǎn)環(huán)境經(jīng)驗的人都知道JVM的調(diào)度和穩(wěn)定性在高壓力下是更讓人放心的。我實測過同樣的熱服務(wù)Java版響應(yīng)時間和Python版差不多但內(nèi)存和CPU峰值更平穩(wěn)。如果你是在內(nèi)部跑上百個任務(wù)并發(fā)調(diào)用模型Java的優(yōu)勢會更明顯。相反如果只是一次性試驗?zāi)怯肞ython快速驗證更要緊。選擇技術(shù)和語言從來不是單維度的事。5.4 向量數(shù)據(jù)庫怎么選在Java生態(tài)里向量存儲的客戶端支持是個經(jīng)常被吐槽的點。有些向量數(shù)據(jù)庫官方的Java SDK都很簡陋甚至還是RESTful接口的二次封裝。我的建議是先選那些你跟業(yè)務(wù)現(xiàn)有技術(shù)棧更近的方案。比如你技術(shù)棧本來就有Elasticsearch那就用ES的密集向量檢索功能Java客戶端很成熟如果你想要輕量級本地方案LangChain4j支持的內(nèi)存向量存儲加上文件持久化就夠用了。不要為了炫技引入一個沒人用過的專用向量數(shù)據(jù)庫最后運(yùn)維和調(diào)優(yōu)全砸在自己手里。我用過一個不是很熱門的專用向量庫官方Java客戶端里對過濾條件的參數(shù)命名跟其他語言版本都不一樣又缺文檔浪費(fèi)了不少時間。能用成熟方案解決的問題就別去挑戰(zhàn)邊際門檻。5.5 模型網(wǎng)關(guān)API怎么選國內(nèi)主流的模型服務(wù)基本都支持OpenAI兼容模式。這意味著你在Java里只要裝一個OpenAI的客戶端把Base URL改成對應(yīng)平臺的地址再配上Key就能直接調(diào)用。這個方法特別省事可以說適配性最廣。但要注意不同廠商對“OpenAI兼容”的實現(xiàn)程度不一樣。有些平臺只兼容了最簡單的chat completion但不支持流式、Function calling或embedding接口。我上周測試某家平臺時流式響應(yīng)能通但返回的事件格式多了一個字段導(dǎo)致解析報錯。遇到這種情況要么找廠商要完整的兼容文檔要么直接用他們的Java SDK別在兼容層上死磕。6. 最后說點個人感受Spring AI Alibaba停更這件事從情緒上確實會影響到一批Java開發(fā)者。但回過神來想一想Java在AI時代的角色更像是一個“大型系統(tǒng)整合者”而不是“算法實驗者”。大模型從底層到應(yīng)用層的鏈路很長模型能力、數(shù)據(jù)工程、業(yè)務(wù)場景、服務(wù)穩(wěn)定性缺一不可。Python拿走了模型訓(xùn)練和最貼合算法的部分Java完全可以用在模型服務(wù)化、數(shù)據(jù)管道、業(yè)務(wù)編排、在線推理這些環(huán)節(jié)拿到自己的陣地。我平時也會在幾個技術(shù)社群里潛水發(fā)現(xiàn)真正把Java AI項目做起來的團(tuán)隊很少會糾結(jié)“Java是不是和二流語言”“Python是不是天下第一”這種問題。他們關(guān)注的是手頭的業(yè)務(wù)需要什么能力然后選擇合適的框架去落地。如果那個框架停更了換個框架繼續(xù)做。這其實才是開發(fā)者面對生態(tài)變化最健康的心態(tài)。如果你當(dāng)下手頭正在做Spring Boot項目又想快速加一個AI聊天助手可以先去官網(wǎng)翻一下Spring AI的quickstart。你會發(fā)現(xiàn)寫Java也能很絲滑地對接大模型。Java的希望在不在不取決于某一個開源項目的存活狀態(tài)而取決于我們這些寫Java的人愿不愿意跨出舒適區(qū)去擁抱新的變化。我反正是信了。