做前端最憋屈的是什么不是需求改來改去而是你花三年練出來的組件設(shè)計、交互手感、性能優(yōu)化在面試官眼里可能不如一個會寫CRUD的人值錢。這兩年圈子里天天喊前端已死我反倒覺得是某些前端自己把自己做成了頁面拼接工。2025年如果還只盯框架源碼和面試八股確實會錯過一個很實際的東西AI應(yīng)用開發(fā)。而且這件事不一定非得學(xué)Python。先說結(jié)論一個熟練的前端轉(zhuǎn)型做AI應(yīng)用開發(fā)比后端轉(zhuǎn)過來有天然優(yōu)勢。因為AI應(yīng)用層拼的根本不是算法而是場景設(shè)計、流程編排和交互體驗——這恰恰是前端的看家本領(lǐng)。而工具鏈上Next.js加LangChain.js已經(jīng)可以把AI應(yīng)用的開發(fā)成本壓得很低低到什么程度低到一個會React的人兩周就能做出一個能演示、能上線、能拿去面試的AI產(chǎn)品。這篇文章就把我從零搭建Next.js LangChain.js應(yīng)用的過程、踩過的坑、用下來的體感全部擺出來。內(nèi)容不是給AI工程師看的就是給前端同行看的。你會搞清楚這些技術(shù)各自在干什么、怎么串起來、為什么這條路低成本以及怎么靠這類項目把自己從CRUD選手里摘出來。1. 前端轉(zhuǎn)AI的窗口期為什么應(yīng)用層需要前端思維1.1 CRUD的終點是成本競爭AI應(yīng)用的終點是體驗競爭我給自己的定位一直是在業(yè)務(wù)里解決問題的前端。這幾年做了不少后臺管理系統(tǒng)表格、表單、權(quán)限、圖表一個月能重復(fù)造三個。這些東西做到后面完全沒有技術(shù)積累因為CRUD的核心問題是怎么讓開發(fā)更快、更便宜這拼的是工程化能力和人力成本拼不出個人溢價。當(dāng)每一家公司都能用現(xiàn)成的UI庫在中后臺項目里快速交付時你靠這點技能拿到的薪水上限就被釘死了。AI應(yīng)用不一樣。2025年的AI產(chǎn)品底層模型的能力已經(jīng)嚴重同質(zhì)化GPT和Claude、國內(nèi)各家大模型差的不是聰明程度而是誰把這些能力包裝成用戶愿意用的產(chǎn)品。一個AI應(yīng)用能不能留住用戶取決于那個對話界面是否順手、流式輸出是否順暢、思考過程展示是否直觀、錯誤處理是否讓人不焦慮。這些細節(jié)全部要靠前端來解決。舉個最直接的例子同一款RAG助手后端接口能力一樣A團隊做的聊天窗口全程轉(zhuǎn)圈B團隊做了逐字流式輸出加引用來源用戶的體感就是天壤之別。而轉(zhuǎn)圈還是流式這件事就是前端的技術(shù)活。所以我一直覺得AI應(yīng)用層的核心崗位缺口不是算法工程師而是懂AI能力邊界、能把模型輸出打磨成產(chǎn)品體驗的前端工程師。1.2 Next.js把全棧門檻壓到了前端已知范圍以前前端要做全棧得學(xué)一門后端語言Python的FastAPI、Node的Express再加上部署、鑒權(quán)、數(shù)據(jù)庫內(nèi)容一下就炸了。Next.js最聰明的地方是讓前端程序員用已經(jīng)掌握的React和JavaScript同一套代碼里直接寫后端邏輯。具體到AI應(yīng)用開發(fā)它的價值有三條API Route就是你的后端。在app/api/xxx/route.ts里寫一個函數(shù)導(dǎo)出POST方法就是一個接口。不用單獨起一個服務(wù)不用配CORS前端fetch同源請求連跨域問題都省了。前后端用一套TypeScript類型。LangChain.js返回的對象、你自定義的數(shù)據(jù)結(jié)構(gòu)前端直接用類型出錯在編譯期就暴露。部署鏈路極短。Vercel一鍵部署不需要買服務(wù)器配Nginx對前端特別友好。這些特性放在AI應(yīng)用里更關(guān)鍵因為AI應(yīng)用需要頻繁調(diào)整接口邏輯、拼消息格式、改提示詞如果前后端分開兩個項目改光聯(lián)調(diào)就累死。1.3 LangChain.js是膠水不是框架很多人一聽LangChain就發(fā)怵以為又是什么重量級框架。我想先把它在項目里的角色說清楚它就是個膠水幫你把AI應(yīng)用里的常見環(huán)節(jié)——連模型、組提示詞、調(diào)函數(shù)、管歷史、做輸出解析——串成一條流水線。它本質(zhì)上是一堆封裝好的工具函數(shù)你拆開看每個都不復(fù)雜。LangChain.js還有一層價值是模型無關(guān)。今天你接OpenAI明天你想換通義千問、換DeepSeek、換國內(nèi)的模型只要改一行配置指向?qū)Ψ降腁PI地址代碼基本不用動。這也是我在真實項目里越來越依賴它的原因——大模型這行變化太快今天便宜好用的模型明天可能就變了你不能把應(yīng)用鎖死在某一家上。對于前端來說LangChain.js最大的意義是它也是TypeScript生態(tài)。我們不用切語言、不用學(xué)Python那套解釋器和虛擬環(huán)境npm install完就干活這就是低成本三個字最實在的地方。2. 從零搭建Next.js LangChain.js的環(huán)境與項目結(jié)構(gòu)2.1 Node版本與包安裝的兼容性實際動手之前先說環(huán)境很多人的第一關(guān)不是代碼是依賴裝不上。我的建議Node.js版本至少18.17以上20 LTS更穩(wěn)妥。Next.js 14、LangChain.js在Node 18下都能跑但你要是想用Next.js 15推薦Node 20。包管理器可以用npm也可以上pnpm。我的經(jīng)驗是pnpm安裝速度快占磁盤小但在某些CI環(huán)境下yarn兼容性更好。個人項目隨意團隊項目統(tǒng)一就行。裝依賴時有個容易踩的坑LangChain生態(tài)的包名非常碎langchain是核心庫模型接入要按廠商裝各自的包比如langchain/openai、langchain/anthropic工具庫還需要langchain/core。很多人一把梭裝langchain就以為全有了結(jié)果跑起來找不到模塊。標(biāo)準操作是先裝核心再按你實際用的模型裝對應(yīng)的接入包npm install langchain langchain/core langchain/openai如果你后面要寫工具調(diào)用、結(jié)構(gòu)化輸出大概率還會用到zod做參數(shù)校驗這個也裝上npm install zod2.2 用App Router組織AI接口初始化項目用官方腳手架就可以npx create-next-applatest ai-frontend-project創(chuàng)建時TypeScript選Yes、ESLint選Yes、App Router選Yes。Tailwind選不選看個人我建議選上后面寫聊天界面不用再配樣式工具。項目結(jié)構(gòu)我的習(xí)慣是這樣的app/ page.tsx # 聊天交互頁 api/ chat/ route.ts # AI對話接口 lib/ model.ts # 模型實例的集中配置 prompts.ts # 提示詞模板 tools.ts # 工具函數(shù)定義app/api/chat/route.ts是Next.js的API Route導(dǎo)出的函數(shù)名對應(yīng)HTTP方法// app/api/chat/route.ts import { NextResponse } from next/server; export async function POST(request: Request) { const body await request.json(); // 這里后續(xù)接LangChain.js return NextResponse.json({ message: ok }); }我最開始犯過一個錯在page.tsx里直接調(diào)用模型SDK。瀏覽器里調(diào)用大模型接口不僅會暴露API Key而且會撞上服務(wù)商的跨域限制。所以記住一條鐵律所有模型調(diào)用必須放在API Route里前端只和API Route通信。2.3 環(huán)境變量與密鑰管理模型API Key放在項目根目錄的.env.localOPENAI_API_KEYsk-xxxx OPENAI_BASE_URLhttps://...這個文件默認被.gitignore忽略不會提交到GitHub。但你得留個心眼如果你用create-next-app初始化項目默認的.gitignore是包含.env*的別手賤去改它。讀環(huán)境變量的方式是process.env.OPENAI_API_KEY注意Next.js里變量名以NEXT_PUBLIC_開頭會暴露到瀏覽器API Key一定別加這個前綴。服務(wù)端代碼API Route、Server Component里可以用任意環(huán)境變量。這點我見過很多新手搞混一旦把Key打包進了前端代碼網(wǎng)站一上線別人看源碼就能扒走。3. 理解LangChain.js三件套模型、提示詞、工具調(diào)用3.1 ChatModel所有交互的第一入口在LangChain.js里一切從模型實例開始。集中在一個文件里管理方便換模型// lib/model.ts import { ChatOpenAI } from langchain/openai; export const chatModel new ChatOpenAI({ model: gpt-4o-mini, temperature: 0.7, apiKey: process.env.OPENAI_API_KEY, baseURL: process.env.OPENAI_BASE_URL, });ChatOpenAI這個類封裝了一個對話模型的能力。你不需要自己拼HTTP請求、處理鑒權(quán)、管重試只需要喂給它消息數(shù)組格式就是{ role: user | assistant | system, content: string }做過聊天功能的都熟?；A(chǔ)調(diào)用方式有這么幾種// 最簡單的一次問答 const response await chatModel.invoke(給我講個程序員笑話); console.log(response.content); // 多輪對話 const messages [ { role: system, content: 你是一個旅游規(guī)劃助手 }, { role: user, content: 推薦一個成都三天的行程 }, ]; const reply await chatModel.invoke(messages);invoke返回完整的回復(fù)結(jié)果適合不需要展示中間過程的場景。但它有一個缺點等模型全部生成完才返回耗時可能好幾秒用戶看著一點反饋沒有體驗很差。所以真實聊天應(yīng)用要用流式這個到第4節(jié)詳細講。3.2 Prompt模板別在代碼里拼字符串很多人寫Prompt就是字符串拼接比如寫你是一個擅長${topic}的助手。項目小的時候無所謂一旦提示詞超過20行拼接維護就是噩夢。LangChain.js提供PromptTemplate用模板變量的方式組織提示詞// lib/prompts.ts import { PromptTemplate } from langchain/core/prompts; const systemTemplate PromptTemplate.fromTemplate( 你是一個{profession}專家助手。 你的風(fēng)格要求{style} 請基于以下知識回答問題如果不知道就明確說不知道{context} ); const prompt await systemTemplate.format({ profession: 前端工程化, style: 簡潔直接先說結(jié)論再給理由, context: 用戶的問題是關(guān)于構(gòu)建工具的, });用模板的好處是提示詞的結(jié)構(gòu)和業(yè)務(wù)代碼解耦。你調(diào)System Prompt時不用動代碼邏輯改模板文件就行。更進一步你可以把提示詞版本號也寫進模板里做A/B測試的時候特別有用。3.3 工具調(diào)用讓模型操作你的代碼工具調(diào)用Tool Calling是LangChain.js里最讓前端覺得爽的能力。模型本身不執(zhí)行代碼但它能根據(jù)用戶需求輸出一個結(jié)構(gòu)化指令告訴你我需要調(diào)用某函數(shù)參數(shù)是什么。這就是AI Agent的基礎(chǔ)。比如你做一個法律問答機器人用戶問今年勞動法關(guān)于加班費怎么算你可以讓模型先調(diào)用你的getLegalRegulation()函數(shù)拿到真實的法律條文再基于條文回答。這樣模型不會憑空編造法條。LangChain.js里定義工具的標(biāo)準做法// lib/tools.ts import { tool } from langchain/core/tools; import { z } from zod; const getWeather tool( async ({ city }) { // 這里寫真實的天氣查詢邏輯 return 北京的天氣是晴溫度25度; }, { name: get_weather, description: 查詢指定城市的實時天氣, schema: z.object({ city: z.string().describe(城市名如北京、上海), }), } );然后綁定到模型上const modelWithTools chatModel.bindTools([getWeather]); const res await modelWithTools.invoke(北京今天天氣咋樣); // 模型的輸出里會帶上tool_calls字段里面是函數(shù)名和參數(shù)的JSON console.log(res.tool_calls);你拿到tool_calls后在自己的代碼里執(zhí)行對應(yīng)的函數(shù)再把結(jié)果返回給模型模型才能基于真實數(shù)據(jù)生成最終回復(fù)。第一次跑通這個鏈路時我是真的有點興奮——原來讓AI動手干活就這么簡單。前端開發(fā)這不就成了AI應(yīng)用的話事人嗎4. 親手做一個流式問答應(yīng)用4.1 API Route里的流式實現(xiàn)理論講完直接上實戰(zhàn)。我做一個最簡單的聊天接口前端發(fā)來消息數(shù)組后端調(diào)用模型流式返回前端逐字渲染。首先改造app/api/chat/route.tsimport { chatModel } from /lib/model; export const runtime nodejs; export const dynamic force-dynamic; export async function POST(request: Request) { const { messages } await request.json(); // 通過stream方法拿到模型輸出的異步迭代器 const stream await chatModel.stream(messages); // 包裝成Web ReadableStream const readableStream new ReadableStream({ async start(controller) { for await (const chunk of stream) { const content chunk.content; if (typeof content string content.length 0) { controller.enqueue(new TextEncoder().encode(content)); } } controller.close(); }, }); return new Response(readableStream, { headers: { Content-Type: text/plain; charsetutf-8, Transfer-Encoding: chunked, }, }); }這里有幾個關(guān)鍵點必須說明export const runtime nodejs流式調(diào)用依賴Node的IO能力別寫成edge。我之前為了省啟動時間換過Edge Runtime結(jié)果模型流的兼容性一堆問題后來老實退回Node。export const dynamic force-dynamic告訴Next.js這個路由不要做靜態(tài)優(yōu)化否則打包時可能被嘗試預(yù)執(zhí)行導(dǎo)致報錯。chunk.content的類型有可能不是字符串。我用typeof content string做了保護因為某些模型的chunk內(nèi)容是數(shù)組格式多模態(tài)。聊天文本場景按字符串處理就夠了。TextEncoder把字符串轉(zhuǎn)成Uint8Array是為了符合Web Stream的規(guī)范。如果用NextResponse包裝流有時反而會因為JSON序列化搞亂格式直接用原生Response最干凈。4.2 前端的流式接收與渲染后端返回的是流前端用fetch配合ReadableStream讀取。頁面組件代碼use client; import { useState } from react; export default function ChatPage() { const [input, setInput] useState(); const [answer, setAnswer] useState(); async function handleSend() { setAnswer(); const res await fetch(/api/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ messages: [{ role: user, content: input }], }), }); const reader res.body!.getReader(); const decoder new TextDecoder(); while (true) { const { done, value } await reader.read(); if (done) break; const text decoder.decode(value, { stream: true }); setAnswer((prev) prev text); } } return ( div textarea value{input} onChange{(e) setInput(e.target.value)} / button onClick{handleSend}發(fā)送/button div{answer}/div /div ); }這段代碼的核心在reader.read()循環(huán)。每讀取一段就用TextDecoder解碼一次然后增量追加到狀態(tài)里。注意decoder.decode(value, { stream: true })這個stream: true參數(shù)它表示當(dāng)前數(shù)據(jù)塊可能只是多字節(jié)字符的一部分讓解碼器內(nèi)部緩存處理否則中文可能偶爾出現(xiàn)亂碼。這是流式渲染中文的細節(jié)。用setAnswer頻繁觸發(fā)React重渲染性能上有點浪費。如果流式塊很小很頻繁可以改用ref直接操作DOM或者用useReducer批量更新。我自己的做法是模型流式輸出的頻率其實沒你想象的那么高setAnswer這種方式在普通項目里完全夠用先跑通再優(yōu)化。4.3 三個流式輸出的坑寫流式問答時我踩過的坑這里直接列出來省得你再趟一遍?？右徊渴鸬絍ercel后流式失效瀏覽器一直轉(zhuǎn)圈直到超時。原因是Vercel的Serverless函數(shù)默認有最大執(zhí)行時間限制免費套餐是10秒且早期的版本對流式響應(yīng)支持不完善。解決方法是使用Vercel的官方標(biāo)識export const maxDuration 60把函數(shù)執(zhí)行時間拉長到60秒。如果你是自己買服務(wù)器部署限制就不那么緊但也要確認反向代理配置了X-Accel-Buffering: no響應(yīng)頭否則Nginx會先緩沖完再發(fā)給瀏覽器用戶感覺就不是流式而是等待后再一次性彈出?？佣﨨ext.js開發(fā)模式下熱更新時模型實例被重復(fù)創(chuàng)建。代碼改動后熱更新會重新執(zhí)行模塊級代碼new ChatOpenAI()每次都重新走一次鑒權(quán)握手慢不說有時還會把連接數(shù)打滿。這個倒不是大問題生產(chǎn)環(huán)境不存在但開發(fā)時調(diào)試接口會莫名慢半拍。我的習(xí)慣是在模塊里先判斷是否已有實例用全局緩存包一層const globalForModel globalThis as unknown as { chatModel?: ChatOpenAI }; export const chatModel globalForModel.chatModel ?? new ChatOpenAI({...}); globalForModel.chatModel chatModel;坑三前端只拿到一半內(nèi)容就中斷。這個一般不是LangChain的問題而是你直接把res.body給了某個JSON解析工具或用了res.json()去解析流式響應(yīng)。記住流式響應(yīng)的Content-Type是text/plain或text/event-stream不是application/json前端必須用getReader()循環(huán)讀取。5. 從Demo到可上線記憶、緩存與成本控制5.1 多輪記憶的輕量實現(xiàn)按第4節(jié)的寫法每次請求只把當(dāng)下這一條用戶消息傳給模型模型是沒有上一輪上下文的。你要做一個真正能用的聊天機器人至少得讓模型記住最近幾輪對話。網(wǎng)上很多教程講LangChain里的Memory模塊但LangChain.js 0.2以后老的BufferMemory、ConversationBufferWindowMemory被逐步移除了官方現(xiàn)在推薦的是LangGraph里的MemorySaver或者干脆自己維護消息列表。我自己用過一段LangGraph覺得是有學(xué)習(xí)成本的用不上低成本這句話。所以我推薦最務(wù)實的方式前端把歷史消息數(shù)組一直帶著后端原樣轉(zhuǎn)發(fā)給模型。具體做法是在前端維護一個messages數(shù)組每次發(fā)新消息前先追加用戶消息連同之前的所有消息一起POST給后端const messages [ { role: system, content: systemPrompt }, ...history, // 之前的所有問答 { role: user, content: input }, ];后端Route里把這一整包消息直接傳給chatModel.stream(messages)就行。模型天然支持多輪對話關(guān)鍵是歷史問答帶上這個動作。有一點要提醒模型上下文窗口有限無限堆歷史會把Token數(shù)撐爆。簡單的處理是只保留最近10輪對話再老的消息截斷掉?；蛘咦鰝€摘要——每20輪對話就請模型把前面的內(nèi)容濃縮一段放進System Prompt。第二種方式效果好但代碼量多項目初期用截斷策略就夠。5.2 用緩存省掉重復(fù)調(diào)用AI應(yīng)用的賬單是按Token算的同一個問題被用戶刷新兩遍你就得付兩遍錢。所以我上線前做了一個極簡的緩存層用用戶消息內(nèi)容做Key把模型的回復(fù)存到內(nèi)存或Redis里。下次來了一模一樣的問題直接命中緩存返回不調(diào)用模型。這個緩存的粒度要看場景。聊天類應(yīng)用問題帶點隨機性緩存命中率不高但如果你做了AI客服、文檔問答這類大量重復(fù)問題的場景緩存能省掉一半以上的模型調(diào)用錢。實現(xiàn)方式很簡單寫一個帶緩存的Stream調(diào)用const cache new Mapstring, string(); export async function getCachedStream(messages: any[]) { const key JSON.stringify(messages); if (cache.has(key)) { return cache.get(key)!; // 以純文本返回 } const stream await chatModel.stream(messages); // 注意流讀一次就沒了所以邊讀邊緩存邊返回 ... }這里有個小麻煩你返回的是流同一份緩存內(nèi)容不能被兩個客戶端同時消費。簡單處理是先把模型完整回復(fù)緩存成字符串然后需要流式的話就從字符串重新制造一個流。犧牲一點首字延遲換來的是代碼簡單。5.3 粗算一筆Token賬成本估算這事很多前端一開始沒概念。我按目前常用的模型來算一筆賬方便心里有數(shù)。大模型的計費單位是Token不是字數(shù)。簡單估算經(jīng)驗英文一個單詞大約1.3個Token中文一個字大約1到2個Token口語化文字偏高假設(shè)用戶提一個問題約200字系統(tǒng)提示詞約500字歷史對話5輪共約2000字加起來一次請求消耗的輸入Token大約3000到4000 Token。模型的回復(fù)按800字算輸出Token約1200到1600。以目前GPT-4o-mini的公開價格為參考輸入0.15美元/百萬Token輸出0.6美元/百萬Token一次問答的成本大概是輸入: 3500/1000000 * 0.15 ≈ 0.000525美元 輸出: 1400/1000000 * 0.6 ≈ 0.00084美元 單次合計 ≈ 0.0014美元 ≈ 1分錢人民幣一萬次問答就是上百塊人民幣。如果換成國內(nèi)更便宜的模型成本能再砍一個量級。說實話個人項目和中小應(yīng)用的模型成本真沒你想的那么可怕真正花錢的是你開發(fā)時反復(fù)調(diào)試、反復(fù)調(diào)用燒掉的Token。所以調(diào)試的時候我習(xí)慣用temperature 0并且開日志記錄每次調(diào)用的Token數(shù)避免大模型在測試階段悄悄燒錢。6. 前端進AI賽道的進一步打算6.1 兩個星期足夠做什么經(jīng)常有人問我零基礎(chǔ)要學(xué)多久才能做AI應(yīng)用。我的答案很直接如果你已經(jīng)會Next.js或React兩個星期就夠了。我的路線建議第一周把LangChain.js文檔里的Quick Start過三遍核心就是模型調(diào)用、提示詞模板、工具調(diào)用三件事。不用研究Agent、記憶、Graph這些進階話題先聚焦一個能回答問題的流式接口。第二周做一個帶場景的真實應(yīng)用。我建議做RAG檢索增強生成方向因為它是目前企業(yè)需求最大的AI場景。具體來說就是上傳一個PDF文檔把內(nèi)容切塊存入向量數(shù)據(jù)庫用戶提問時先做向量檢索把相關(guān)片段塞進提示詞再讓模型基于片段回答。Next.js生態(tài)里upstash/vector、vercel/postgres這些包都能快速接上數(shù)據(jù)庫選一個托管服務(wù)不用自己運維。兩周下來你手里就有兩個能上線的項目一個流式聊天助手一個文檔問答機器人。這兩個項目足夠應(yīng)付大部分AI應(yīng)用開發(fā)崗位的面試了。6.2 作品集和面試怎么講面試講AI項目最大的誤區(qū)是只講我用了什么。面試官想聽的是你怎么定義問題、怎么拆解流程、怎么處理邊界。我給你一個思路按這個邏輯講項目含金量會明顯不一樣從需求出發(fā)用戶的核心痛點是什么比如文檔太長沒人讀或客服回復(fù)慢方案選型為什么用Next.js全棧而非前后端分離為什么用LangChain.js而非直接調(diào)SDK實現(xiàn)路徑說清楚你的消息流轉(zhuǎn)全鏈路從用戶輸入、到預(yù)處理、到模型調(diào)用、到工具調(diào)用、再回到用戶。難點和取舍比如流式輸出怎么做的、上下文怎么管理的、Token成本怎么控制的、模型遇到亂答怎么兜底。這個結(jié)構(gòu)不是為了裝而是AI應(yīng)用項目確實容易一跑通就完了你得主動展示你做過工程化思考。面試官只要一聽你能講清楚模型輸出不可靠時你的產(chǎn)品怎么兜底立刻就會把你和只會調(diào)API的人區(qū)分開。6.3 前端做AI項目的獨家優(yōu)勢最后說點掏心窩的話。我見過不少后端出身的人寫AI應(yīng)用接口設(shè)計、并發(fā)處理都很強但最常翻車的是兩件事第一聊天界面做得像調(diào)試工具用戶根本不想用第二流式輸出的體驗處理不到位前端動不動白屏卡頓。反過來前端做AI項目的優(yōu)勢恰恰體現(xiàn)這些地方咱們天生對這個界面好不好看、交互順不順手敏感而且前端工程化的積累能直接遷移到AI應(yīng)用的前端復(fù)雜度管理上。AI應(yīng)用的用戶界面會比傳統(tǒng)后臺復(fù)雜得多——對話流、流式文本、工具調(diào)用進度、引用來源展示、流式渲染的性能優(yōu)化這些都是前端的主場。所以別覺得AI兩個字有多高不可攀底層模型是別人訓(xùn)練的算法是別人研究的但最終給到用戶手里的產(chǎn)品是我們這個工種造的。這條路現(xiàn)在還在窗口期再過幾年各路人員擠進來門檻一定會抬高。趁現(xiàn)在用Next.js和LangChain.js把一個能跑的AI產(chǎn)品做出來比焦慮地刷面試題有用得多。\u003c/en\u003e