先交代一个背景我以前也是天天跟 Table、Form、Modal 打交道的普通前端CRUD 写到最后肌肉记忆比脑子还快。真正让我决定换方向的是去年下半年我发现团队里同样改一行组件样式会接大模型接口的同事绩效和话语权完全不一样。后来我花了大概三周用 Next.js 加 LangChain.js 把公司一个内部知识库问答系统做了出来才意识到前端转 AI 应用开发根本没有想象中那么高的门槛。这篇文章就把我的完整思路、选型理由、核心代码和踩坑记录全部分享出来给还在犹豫要不要迈出这一步的前端同学一个真实参考。1. 前端做AI先转变的是思维方式而不是技术很多前端一听 AI 开发下意识觉得要补 Python、要懂算法、要会训练模型然后就被劝退了。这个认知需要先纠正一下我们进入的赛道叫 AI 应用开发不是 AI 基础研究。绝大多数公司的真实需求是把现成的大模型能力接进业务系统让用户能通过聊天、搜索、自动生成等方式使用 AI。这里面涉及的工程问题恰恰是前端最擅长的领域。1.1 CRUD和AI应用的本质差别传统 CRUD 的逻辑是确定性的用户点保存后端把数据写进数据库再查出来渲染。所有流程都是提前定义好的前端的工作是把后端给的接口数据呈现出来处理各种状态和异常。做得再熟练本质上是“翻译”工作。AI 应用的逻辑是非确定性的用户输入一句话系统要决定怎么理解它要判断需不需要检索知识库要把上下文拼装成一段提示词再把大模型输出的内容流式渲染到页面上。这里面每一步都可能因为输入不同而产生不同的结果而且模型输出还会出错、会编造、会超时。这个转变对前端来说反而友好。因为 AI 应用的核心不是算法而是交互设计、状态管理、异步流程、数据展示和反馈机制。用户在对话框里打了一句话前端要即时显示 loading 状态要支持流式输出要能处理中断要保存历史记录这些都是前端本来就在做的事情。1.2 前端的认知优势我自己的体会是前端转 AI 应用开发有三个别人抢不走的优势。第一前端最了解用户。一个 AI 功能做得再好如果入口难找、输出太慢、没有 loading 反馈用户照样骂。前端天然站在用户体验第一线知道什么交互是顺手的什么提示语是用户能看懂的。第二前端擅长处理异步和 UI 状态。大模型接口基本都是异步返回流式输出过程中还要做打字机效果、增量渲染这些用 React 的 hook 机制写起来非常顺手反倒是很多后端同事一碰到实时流和 UI 状态就头疼。第三前端手里有完整的组件库和可视化能力。AI 生成的结果需要人审阅、需要导出、需要多轮对话管理前端可以快速搭出完整的工作台产品让 AI 能力真正变成能交付的业务系统。2. 为什么要选Next.jsLangChain.js这套组合技术选型是我最开始纠结的事。市面上 Python 的 AI 框架生态确实好LangChain 的 Python 版本资料也最多但当时我评估了一下自己的情况React 写了六七年TypeScript 已经成肌肉记忆再看 Python 的异步语法和包管理虽然能看懂但谈不上熟练。最后我选定了 Next.js 加 LangChain.js 的组合核心理由有三个。2.1 为什么不是Python后端助手先声明我不是说 Python 不好。LangChain Python 版的社区案例确实多大部分模型供应商的 SDK 也是 Python 优先。但如果你的目标是在两周内做出一个能演示、能上线的 AI 应用而不是钻研深度学习算法那么用 JavaScript 全家桶是更务实的路径。原因很简单一份代码同时覆盖前端页面、接口路由和 AI 调用逻辑。Next.js 的 Route Handler 可以直接写服务端代码不需要单独起一个 Node 服务也不需要配 Nginx 转发。LangChain.js 在 npm 上有完整的包封装了模型调用、Prompt 模板、文档加载、向量存储这些常用的能力和 Python 版的接口设计几乎一一对应。前端只学一套 TypeScript就能把整个 AI 应用的前后端全部写完维护成本低团队内部也容易接手。2.2 LangChain.js到底帮你省了哪些事LangChain.js 不是 AI 框架里最轻量的但它帮你解决的问题非常集中对新手最友好。第一个是模型供应商的切换。公司的 AI 项目前期可能用 OpenAI后期因为成本和合规要换成国内模型LangChain 的调用层做了统一封装换模型时只需要改配置业务代码基本不用动。第二个是 Prompt 模板管理。凡是在业务里写死提示词的做法最后都会后悔因为产品经理一定会让你改。LangChain 的 PromptTemplate 可以把提示词中的变量抽出来把整个模板当作可配置项这个思路和前端把配置项抽离组件的思路完全一致。第三个是 RAG 流程的开箱即用。所谓 RAG就是让大模型在回答问题时先从你自己的知识库里检索相关内容再结合检索结果生成答案。LangChain 提供了一整套文档加载、文本切分、向量化、检索的组件虽然每一环都还有其他专业工具可以做但对于业务型 AI 应用来说LangChain 的集成方案已经足够可靠。3. 从零搭AI应用项目骨架与核心API确认技术方向后我给自己定了一个目标用三天做出一个最小可用的对话式知识库问答应用。下面是我实际操作时的完整流程包含每个环节的关键代码和当时的思考。3.1 初始化Next.js并接入LangChain.js我使用的是 create-next-app 创建项目App Router 模式TypeScript 开启ESLint 开启。这里有个容易忽略的细节安装完 LangChain 相关依赖后最好在项目根目录建一个.env.local文件把模型 API Key 和模型名称都放在环境变量里方便以后切换供应商。npm install langchain langchain/openai我当时的模型配置是这样写的import { ChatOpenAI } from langchain/openai; const model new ChatOpenAI({ apiKey: process.env.OPENAI_API_KEY, model: gpt-4o-mini, temperature: 0.3, });选 gpt-4o-mini 的理由是成本低、响应快做内部工具和 MVP 验证最适合。如果你的业务面向国内用户可以换成国内大模型平台的 OpenAI 兼容接口只需要把 baseURL 和模型名改掉就行。3.2 核心链路从用户输入到大模型返回整个 AI 应用的链路并不神秘拆开来看就四步接收用户输入、组装上下文、调用模型、流式返回结果。在 Next.js 的 Route Handler 里我实现了一个最基础的对话接口。// app/api/chat/route.ts import { NextRequest } from next/server; export async function POST(req: NextRequest) { const { messages, question } await req.json(); const contextText await retrieveContext(question); const prompt 你是企业内部知识库助手请严格根据以下资料回答用户问题。 如果资料中没有相关信息请明确回答“资料库中暂未找到相关内容”。 资料 ${contextText} 对话历史 ${messages .map((m: any) ${m.role}: ${m.content}) .join(\n)} 用户问题${question} ; const stream await model.stream(prompt); return new Response(stream, { headers: { Content-Type: text/plain; charsetutf-8, }, }); }前端页面调用这个接口时用fetch读取响应流实时拼接内容。const res await fetch(/api/chat, { method: POST, body: JSON.stringify({ messages, question }), }); const reader res.body?.getReader(); const decoder new TextDecoder(); while (true) { const { done, value } await reader.read(); if (done) break; text decoder.decode(value); setAnswer(text); }这个模式跑通后你就已经拥有了一个实时对话 AI 应用的主干后续的所有功能比如多轮对话、知识库、引用来源、历史记录都是在这个主干上长出来的。4. 一个RAG对话应用的关键代码复盘如果只是做个聊天机器人那用 LangChain.js 就有点大材小用了。真正让它产生业务价值的是 RAG也就是把公司自己的文档变成 AI 的参考依据。这一节我会把完整的 RAG 实现过程复盘一遍包括踩过的坑。4.1 文档切分与向量化的坑RAG 的第一步是把文档切成小块转成向量存到向量数据库。我当时用的方案是读取 PDF 或 Markdown 文件按固定长度切分然后调用 Embedding 模型生成向量最后存入内存向量库。LangChain 的MemoryVectorStore适合开发阶段快速验证不需要额外部署数据库。import { RecursiveCharacterTextSplitter } from langchain/text_splitter; import { MemoryVectorStore } from langchain/vectorstores/memory; import { OpenAIEmbeddings } from langchain/openai; const text await readFile(docs/manual.md, utf-8); const splitter new RecursiveCharacterTextSplitter({ chunkSize: 500, chunkOverlap: 100, }); const docs await splitter.createDocuments([text]); const vectorStore await MemoryVectorStore.fromDocuments( docs, new OpenAIEmbeddings() );切分参数这里我踩过比较大的坑。一开始我用了 chunkSize 等于 2000结果很多检索内容语义不完整回答质量很差。后来把大小调到 500重叠 100效果才稳定下来。原理也好理解切分块越大单个块里的杂讯越多向量化之后的语义容易被稀释切分块太小又会导致上下文信息不足。500 到 800 之间是我在多份文档上实测比较稳的区间但具体数值还需要根据文档类型调整。4.2 上下文拼接与流式输出检索完成之后更关键的步骤是把检索到的内容拼进 Prompt。这里的核心原则是不要让模型觉得资料可有可无也不要让资料喧宾夺主。我当时封装了一个retrieveContext函数每次用户提问时先做向量检索取 top 4 个最相关的文档片段拼成一段上下文。async function retrieveContext(question: string) { const results await vectorStore.similaritySearch(question, 4); return results.map((doc) doc.pageContent).join(\n\n); }这里面还要注意引用的来源。我在每个文档片段里保留了原始文件的路径和页码拼 Prompt 时模型会自己判断哪段资料对应哪个来源最后回答里附上引用列表。这一步在企业内部工具里非常重要因为业务人员不只想知道答案还要能追到原始文档去核实。流式输出方面实际开发时要注意把模型返回流直接转发给浏览器时中文编码和浏览器兼容性基本没问题但响应头最好加上Cache-Control: no-cache避免一些代理服务器把流缓存住导致前端一直等。5. 部署、成本与真实开发避坑功能开发完只是第一步部署上线后才会遇到更多实际问题。我根据自己的部署经历整理几个新手最容易踩的坑。5.1 部署Next.js到Serverless的注意事项Next.js 应用可以部署到 Vercel、Netlify 或者国内的云厂商 Serverless 平台。部署本身没什么难度但你需要注意一个关键指标Serverless 平台的函数超时时间。我一开始部署在 Vercel Hobby 计划上免费额度下函数超时限制是 10 秒。大模型的流式输出如果网络不稳定或者检索的文档较多很容易超过这个时间。后来我做了两件事一是把检索逻辑做瘦身控制单次请求的文档数量二是把超时设置调到合理范围同时前端做好超时提示和重试机制。另外一个容易被忽略的点是环境变量。.env.local只存在于本地部署到 Serverless 平台之后需要在平台的后台管理界面重新配置同名的环境变量。我因为漏配了模型 API Key线上接口一直报 401排查了整整一个下午。5.2 Token成本控制Token 是 AI 应用最主要的成本而且它不像服务器费用那样直观是跟着用户输入走的。我观察到很多团队的 AI 应用上线后成本失控基本都是这个原因。我的控制思路有三层。第一层是限制上下文长度每轮对话最多携带最近 6 条历史消息更早的消息直接丢弃避免 Prompt 变得越来越长。第二层是做问题重写和检索去重用户问的相似问题先做向量匹配如果已有相同语义的缓存答案直接返回不再调用模型。第三层是选用便宜的模型做简单任务比如意图识别、关键词提取这种小任务用 mini 模型真正生成长文本时才用大模型。const MAX_HISTORY 6; const recentMessages messages.slice(-MAX_HISTORY); const prompt await promptTemplate.format({ contextText, history: recentMessages .map((m) ${m.role}: ${m.content}) .join(\n), question, });这样处理后我那个知识库问答应用每月的 Token 成本大概控制在几十元以内内部几十个人日常使用完全够用。6. 卷AI的正确姿势前端经验的隐藏红利最后聊聊大家最关心的前端转 AI 应用开发怎么做才能更快拿到更好的机会。这里我不讲空话只说我自己验证过有效的方法。6.1 如何展示作品集面试 AI 应用开发岗位时你不需要准备算法题或数学推导但你必须有一个线上可访问的完整项目。这个项目不需要多复杂但一定要体现三项能力大模型接入、RAG 流程、流式交互体验。我当时把我做的知识库问答系统部署上线后专门写了一个 demo 页面上传了三份公开的技术文档作为测试资料访客可以直接对话提问。面试时我不需要讲太多概念直接打开网址让面试官自己试用然后用十分钟讲清楚系统的架构和数据流动。这个说服力比任何简历上的“熟悉 LangChain”都强。面试官能看到你会做产品、能处理流式渲染、懂提示词工程这些都是前端转 AI 最有力的加分项。6.2 面试的关键词前端面试 AI 应用开发面试官真正会问的问题我总结下来基本是这几类RAG 的工作流程是什么文档切分参数怎么调怎么处理大模型幻觉怎么保证回答基于知识库对话上下文管理怎么做Token 成本怎么控制流式输出怎么实现前端如何做中止和重试模型切换怎么做多模型怎么统一管理检索不到相关内容时系统该如何降级这些问题的答案都不是靠背八股文能解决的它们全部来自实际项目的积累。你自己把项目跑一遍这些问题就会变成你身体里的经验。我是真觉得前端转 AI 应用开发是当下性价比最高的路径因为它不需要你从零学高数不需要你啃论文只需要你把已有的工程化能力和交互设计能力平移到 AI 应用的场景里。代码层面那层窗户纸捅破之后你会发现底层还是你熟悉的 TypeScript、React 和 HTTP 协议只是业务逻辑从“读写数据库”变成了“组装上下文、调用模型、渲染流”。把第一个 AI 应用亲手做出来之后你看到的世界就会完全不同。
