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