过去半年我陆陆续续面了二十多个前端候选人简历上清一色的后台管理系统、电商小程序、可视化大屏。我几乎每次都会追问一句“如果现在让你做一个 AI 问答应用前端怎么接管流式输出”能答出“用 SSE 自己解析再逐字渲染”的掰着指头都数得过来。这不是能力问题是信息差问题——大部分前端人对 AI 应用开发的认知还停在“调一下接口就完事”的层面。今天我就用一条自己实际趟过的路径来聊一个只会 React/Vue、没写过 Python、没训过模型的前端怎么用 Next.js LangChain.js以最低的学习成本和金钱成本做出能写进简历的 AI 应用然后真正往 AI 应用开发这个方向挤。顺便把那些简历上没法写、但面试一定会被追问的细节一并说清楚。1. 前端转 AI 应用开发选对赛道比选对框架更重要先说个反直觉的结论前端想进 AI 领域不需要去卷算法岗算法岗那套数学、训练、调参没个一年半载啃不下来而且岗位数量远少于应用开发。真正对前端友好、需求量大、门槛可控的方向是AI 应用开发——也就是把大模型的能力封装成产品聊天助手、文档问答、知识库、自动化工作流、Agent 工具这些都属于这个范畴。1.1 AI 应用开发的三种分工前端在哪一档我把 AI 应用开发粗略分成三层基础设施层训练模型、微调、部署推理服务。需要扎实的机器学习功底前端基本不用想。中间层做模型调用封装、Prompt 工程、RAG 检索链路、Agent 编排。这一层 Python 开发者有优势但并非不可跨越。应用层把模型能力变成用户可用的界面和交互——对话式 UI、流式打字机、文档上传解析、结果可视化、权限与状态管理。这一层前端有绝对主场优势。大部分 AI 产品最终拼的是体验而体验恰好是前端的看家本领。你不需要懂 Transformer 的 self-attention 怎么算你只需要知道怎么把模型吐出来的 token 流变成用户界面里顺滑的打字机效果。这个分工格局决定了前端转型的路径不是“学 Python 追算法”而是“用自己最熟的技术栈直接做 AI 产品”。1.2 已有的 CRUD 经验哪些能直接复用做 AI 应用不等于推倒重来。你之前写 CRUD 积累的能力至少有一半能平移过来接口设计与联调AI 应用的前端要跟模型服务打交道本质还是 HTTP 请求、鉴权、错误处理只是返回格式从 JSON 变成了流式文本。状态管理一个对话会话的 loading、error、历史记录、上下文维护跟你以前管理表单状态没有本质区别。文件上传与解析做知识库问答时上传 PDF、解析文本、分段存储这些活就是前端熟悉的文件处理场景。组件封装聊天窗口、流式输出、引用来源展示、Markdown 渲染这些都是前端组件化的老本行。真正需要新学的其实就三件事流式交互原理、向量化与检索、提示词设计。这三件事的学习曲线都不算陡峭两周时间可以拿下基础后面就是熟练度问题。2. Next.js 凭什么成为 AI 前端的事实标准如果只是想给 AI 应用做个壳用 Vite React 也完全能跑。那为什么我强烈建议直接用 Next.js因为 AI 应用有几个特殊需求恰好是 Next.js 的强项用传统 SPA 方案解决起来非常别扭。2.1 四个绕不开的技术点第一个是服务端 API 路由。AI 应用不能把模型服务的 API Key 暴露在浏览器端否则等于把钱包交给路人。传统 SPA 的做法是单独起一个 Node 服务或者云函数把接口包一层。Next.js 的 Route Handler 直接在应用内部解决了这个问题——前端页面和 API 住在同一个项目里部署时一起上线省掉一个服务也省掉一套鉴权和跨域处理。这对小团队和独立开发者来说省的不只是时间还有基础设施成本。第二个是流式渲染与流式输出。大模型生成文本是逐 token 吐出来的好的交互体验要求前端像打字机一样逐字展示。Next.js 的 App Router 对 ReadableStream 的支持很成熟配合 Vercel AI SDK 的useChat这类工具你几乎不用手动处理fetch的流解析逻辑组件内部已经帮你把data转过来了。我第一次用的时候愣了一下因为以前做 AI 聊天要自己写一堆getReader()和TextDecoder的样板代码现在全被封装掉了。第三个是服务端组件带来的数据加载优势。AI 应用往往需要初始上下文——比如用户信息、历史会话、知识库列表。在 Next.js 里这些数据可以在服务端直接读取不需要客户端发请求再加载一遍。首屏速度更快也不会有 loading 闪烁。第四个是边缘运行时。Next.js 的 Route Handler 可以直接跑在 Vercel 的 Edge Runtime 上也就是 CDN 节点上执行代码。对大模型调用来说请求从离用户最近的节点发出去首字节延迟会更低。而且 Edge Runtime 是按请求计费空闲时零成本这对个人项目非常友好。2.2 什么时候可以不选 Next.js如果你做的是一个纯客户端工具比如浏览器插件或者在 Electron 桌面应用里嵌 AI 功能那 Next.js 的优势就不明显。还有如果团队已经有成熟的 BFF 层Backend For Frontend且不愿多维护一套 Node 服务那也可以沿用现有架构前端继续用 SPA。判断标准很简单看你的 AI 应用是“以服务为中心”还是“以客户端为中心”。前者选 Next.js 很顺手后者可以再权衡。3. 从零实现一个可用的 RAG 文档问答助手理论说太多没用直接上项目。我建议每个想转型的前端第一个完整项目都做RAG 文档问答助手——上传几篇文档然后对文档内容提问模型基于文档内容回答。这类项目覆盖面广既有前端交互、又有后端调用、还有向量检索是简历上性价比最高的 AI 项目形态。3.1 最简架构先本地跑通再上基础设施很多教程一上来就让你用向量数据库、对象存储、任务队列看完就劝退了。实际做项目起步阶段完全可以更朴素一点。我给出一套本人验证过的低成本方案模块起步方案进阶方案前端框架Next.js App Router不变模型调用Vercel AI SDK 的 streamText不变可加 LangChain.js文档解析直接读纯文本/markdownpdf-parse mammoth 处理 PDF/Word文本切分按字符数切块用 LangChain.js 的 RecursiveCharacterTextSplitter按段落和语义切分向量化模型服务商的 Embedding API本地 BGE 模型免费向量存储本地 JSON 文件内存里算余弦相似度pgvector / Pinecone / Qdrant部署Vercel 免费额度Docker 云服务器起步阶段不需要数据库、不需要 Redis、不需要对象存储。把文档切块、向量化之后存进一个 JSON 文件查询时从 JSON 里读出向量用余弦相似度排序取 Top-K 拼进 Prompt。文档数量在几百块以内这套方案性能完全够用而且是零基础设施成本。3.2 核心代码文档入库流程下面是文档切块和向量化入库的代码。我用 TypeScript 写跑在 Next.js 的 Route Handler 里// app/api/knowledge/ingest/route.ts import { RecursiveCharacterTextSplitter } from langchain/text_splitter; import { embeddings } from /lib/embeddings; import { loadKnowledgeBase, saveKnowledgeBase } from /lib/kb-store; export async function POST(req: Request) { const { text, docId } await req.json(); // 1. 切分文本 const splitter new RecursiveCharacterTextSplitter({ chunkSize: 500, // 每块字符数 chunkOverlap: 50, // 相邻块重叠字符数避免语义被切断 }); const chunks await splitter.splitText(text); // 2. 逐块向量化 const vectors await embeddings.embedDocuments(chunks); // 3. 存入本地 JSON 存储 const kb await loadKnowledgeBase(); chunks.forEach((chunk, i) { kb.push({ docId, chunk, vector: vectors[i], }); }); await saveKnowledgeBase(kb); return Response.json({ count: chunks.length }); }这里面的关键参数是chunkSize和chunkOverlap。500 字符是中文场景下比较稳妥的起步值——太短则语义不完整太长则向量检索精度下降还容易超出模型的上下文窗口。chunkOverlap则是让块与块之间有重叠避免一个完整段落被拦腰切断后前后两半都检索不到完整信息。3.3 核心代码检索问答链路入库之后问答链路是这样用户提问 → 把问题向量化 → 在知识库里找最相似的 Top-K 块 → 拼进 Prompt → 调用模型 → 流式返回。// app/api/chat/route.ts import { streamText } from ai; import { openai } from ai-sdk/openai; // 或换成智谱/通义/DeepSeek 的适配器 import { embeddings } from /lib/embeddings; import { loadKnowledgeBase } from /lib/kb-store; function cosineSimilarity(a: number[], b: number[]) { const dot a.reduce((sum, val, i) sum val * b[i], 0); const normA Math.sqrt(a.reduce((sum, val) sum val * val, 0)); const normB Math.sqrt(b.reduce((sum, val) sum val * val, 0)); return dot / (normA * normB); } export async function POST(req: Request) { const { messages } await req.json(); const question messages[messages.length - 1].content; // 1. 检索相关文档块 const kb await loadKnowledgeBase(); const qVector await embeddings.embedQuery(question); const topK kb .map((item) ({ ...item, score: cosineSimilarity(qVector, item.vector), })) .sort((a, b) b.score - a.score) .slice(0, 4); // 2. 拼装 Prompt把检索结果作为上下文 const systemContext topK .map((item, i) 【文档片段${i 1}】\n${item.chunk}) .join(\n\n); const systemPrompt 你是一个文档问答助手。请仅根据以下文档片段回答用户问题如果文档中没有相关信息坦诚说明不知道。\n\n${systemContext}; // 3. 流式调用模型 const result streamText({ model: openai(gpt-4o-mini), system: systemPrompt, messages, }); return result.toDataStreamResponse(); }这一步充分体现了前端做 AI 应用的优势你懂数组操作懂排序懂字符串拼接就够实现一个 RAG 核心链路。所谓“检索增强生成”拆开来看就是“查资料 抄进 Prompt 让模型照着答”并不神秘。3.4 前端对话界面AI SDK 让流式交互走向零门槛Vercel AI SDK 的useChatHook 把流式交互的复杂度几乎全部吸收了。前端代码简洁到不像真的use client; import { useChat } from ai/react; export default function Chat() { const { messages, input, handleInputChange, handleSubmit, isLoading } useChat(); return ( div {messages.map((m) ( div key{m.id} strong{m.role user ? 我 : AI}/strong div{m.content}/div /div ))} form onSubmit{handleSubmit} input value{input} onChange{handleInputChange} placeholder输入你的问题... / button typesubmit disabled{isLoading} {isLoading ? 思考中... : 发送} /button /form /div ); }useChat内部会自动维护消息历史自动把请求发到/api/chat这个约定端点自动解析服务端返回的流式数据并增量更新messages。你不需要手写fetch不需要处理 ReadableStream不需要维护消息数组的更新逻辑。这就是为什么我说“低成本”——你 80% 的精力可以花在产品逻辑上而不是基建上。4. 什么时候才真正需要 LangChain.js我用 RAG 问答的例子展示了不用 LangChain.js 也能做 AI 应用。那为什么标题里还要强调 LangChain.js因为它解决的是更复杂场景的问题——当你的应用需要多个步骤、多个模型、多个工具协作时手写代码的维护成本会指数级上升。4.1 LangChain.js 解决的是脑力活而非体力活举个例子假设你做一个“会议纪要助手”用户上传录音转写文本你的应用需要先判断这场会议的类型周会、评审会、一对一然后根据类型选择不同的总结模板再提取待办事项最后可能还要把待办事项同步到一个数据库。如果用纯粹的 if/else 硬编码流程是死的每种会议类型写一套分支逻辑。可问题是会议类型的判断本身就不可控——模型给出的答案有概率性同一个输入今天可能是“周会”明天可能是“项目同步会”。这种模糊决策场景手写代码非常痛苦。LangChain.js 的价值就在于它把“让模型做决策、按决策执行动作”的模式抽象成了可配置的链Chain和代理Agent。你不需要写一堆分支判断只需要告诉模型有哪些工具可用、什么时候该用哪个模型自己会规划执行路径。4.2 一个快速上手的 Agent 示例让模型学会调用前端工具看了理论还是不过瘾我直接给你一个 LangChain.js 的 Agent 示例——场景是让 AI 能查询订单状态。以往这种功能需要后端提供接口、前端写死调用逻辑。用 Agent 后模型自己判断“用户想查询订单 → 调用工具 → 拿到结果 → 组织语言回答”。// app/api/agent/route.ts import { ChatOpenAI } from langchain/openai; import { createReactAgent } from langchain/langgraph/prebuilt; import { tool } from langchain/core/tools; import { z } from zod; // 定义一个查询订单的工具 const queryOrderTool tool( async ({ orderId }) { // 这里可以是数据库查询也可以是调用已有后端接口 const order await db.orders.findUnique({ where: { id: orderId } }); return JSON.stringify(order ?? { error: 订单不存在 }); }, { name: query_order, description: 根据订单ID查询订单状态订单ID格式为 ORD-2024-001, schema: z.object({ orderId: z.string().describe(订单ID), }), } ); export async function POST(req: Request) { const { messages } await req.json(); const userMessage messages[messages.length - 1].content; const model new ChatOpenAI({ model: gpt-4o-mini, temperature: 0, }); const agent createReactAgent({ llm: model, tools: [queryOrderTool], }); const result await agent.invoke({ messages: [{ role: user, content: userMessage }], }); return Response.json({ reply: result.messages[result.messages.length - 1].content, }); }createReactAgent是 LangChain.js 对 ReAct 模式Reason Act推理加行动的封装模型先理解用户的请求决定需要调用哪个工具触发工具执行拿到结果后整合成自然语言回复。工具的入参 schema 用 zod 定义LangChain 会自动把模型的输出校正成合法 JSON 传给工具函数。这比手写“意图识别 → 参数抽取 → 接口调用 → 回复生成”的四步流程要省太多事。4.3 少走弯路这些场景不要硬上 LangChain.js我也见过不少反例——刚学完 LangChain.js 就想着所有接口都包一层结果把简单问题复杂化。下面是我不建议用 LangChain.js 的场景只有一轮简单的对话比如一个翻译功能直接用 AI SDK 调模型就行不需要引入链式抽象。工具调用非常固定如果只有一条固定的 API 调用路径写普通代码反而更清晰、更好调试。紧急上线的小功能LangChain.js 更新频繁版本差异不小紧急需求要先求稳用熟悉的方式快速上线再考虑重构。LangChain.js 真正值回票价的时候是业务流程开始出现“分支判断”“多步协作”“状态依赖”的时候。在这之前手写是更合适的选择。判断标准很简单如果流程能用 if/else 描述清楚就别引入框架。5. 部署、成本与性能个人项目怎么花最少的钱上线做技术项目最怕两件事一是学不会二是用不起。模型调用是按 token 收费的部署服务器是按月收费的如果账没算清项目做到一半就被账单劝退了。我把我实际用的省钱方案和性能优化思路列出来。5.1 部署方案免费起步按需升级方案成本适用场景Vercel 免费版免费包含一定量的 Edge/Serverless 函数调用次数个人项目、Demo、作品集完全够用Vercel Pro按量付费20美元/月左右有稳定访问量后可以升级Docker 云服务器入门级 2C4G 大约每月几十块到一百多块需要香港/海外服务器时考虑可自行控制成本内网穿透 自托管几乎为零需要开发者有内网环境仅限自己开发调试不适合对外展示个人项目我强烈建议从 Vercel 免费版起步。Next.js 项目几乎是零配置部署git push到 GitHub 自动构建上线。等量上来了再迁移初期不需要把精力花在 DevOps 上。5.2 模型成本选择关键在够用模型选型是成本的大头。我按目前主流模型的实际表现给一个参考模型用途成本特征gpt-4o-mini日常对话、总结、RAG 问答便宜一张跑步图都不到个人项目首选gpt-4o / Claude 系列复杂推理、Agent 任务贵按场景稀释使用智谱 GLM / 通义千问 / DeepSeek国内用户访问延迟更低经常有免费额度中文适配好本地 BGE 系列模型Embedding 向量化完全免费但需要服务器资源我的经验是最重要的一句话不要用贵模型做简单任务。RAG 问答这种任务信息提取量不大gpt-4o-mini 足够只有遇到需要多步推理的复杂需求时才考虑切换到强模型。实际项目中可以通过“先快后慢”的方式控制成本——先用便宜模型处理失败或置信度不够时再用贵模型兜底。5.3 性能提速三板斧流式输出是第一优先级用户感知的响应速度流式首字比整体返回快得多。AI SDK 默认就是流式别去关掉它。向量检索提前做如果知识库不大可以把整个向量加载到内存里缓存避免每次请求都读 JSON 文件。几百条向量内存态检索只需几毫秒。缓存重复问题同一个问题短时间内重复提问可以直接返回缓存结果不消耗模型调用。Redis 成本高起步用内存 Map 就够了反正 Serverless 函数可能随时重建缓存只是优化不是保证。一个容易被忽略的小技巧把系统 Prompt 里不会变化的部分比如角色设定在代码里提前拼好不要把整段 Prompt 每次调用都重算一遍尤其是长文本场景小优化也能省 token。6. 这五个前端最容易踩的坑我全替你踩过了做 AI 应用的前端和做传统前端的调试思路完全不同。下面这几个坑我几乎每个都踩过有些还坑了我好几天。写出来帮你跳过。6.1 环境变量暴露API Key 写进客户端代码这是新手犯的最危险的错误。在 Next.js 里NEXT_PUBLIC_开头的环境变量会打进浏览器端 bundle。如果你把 OPENAI_API_KEY 命名成NEXT_PUBLIC_OPENAI_API_KEY那用户查看网页源码就能拿到你的 Key后果是别人拿你的 Key 疯狂调用你月底看到账单时欲哭无泪。正确做法是把 Key 放在服务端用的环境变量里不带NEXT_PUBLIC_前缀然后在 Route Handler 或 Server Action 中读取。这样浏览器端永远拿不到真实 Key。注意Vercel 的 .env.local 是服务端和客户端共享的命名时一定靠前缀区分。凡是服务端使用的变量一律不带NEXT_PUBLIC_前缀。6.2 流式返回在本地能跑部署后却是完整的 JSON这个坑特别隐蔽。本地开发时 Next.js 跑在 Node 环境中streamText返回的是一个实时流前端正常打字机效果。但如果你部署到 Vercel 时没配置对运行时函数被强制成普通 Node.js 运行或者网络中间层对响应做了缓冲流式响应就会被攒成完整的 JSON 一次性返回——界面表现就是从“打字机”变成“等很久然后整段蹦出来”。排查方法很简单用浏览器的 Network 面板看/api/chat的响应如果响应头里有Content-Type: text/plain; charsetutf-8且内容是分多次到达的说明流式正常如果一次性返回检查 Route Handler 里是否设置了export const runtime edge或者在 Vercel 上确认函数的运行时配置以及函数是否有日志输出操作因为 Edge Runtime 对 console.log 的支持也有坑。6.3 上下文窗口爆掉聊天记录无限增长很多前端做聊天界面时习惯把所有历史消息一股脑发给模型。聊到五十轮之后Prompt 越来越长模型开始报 context length exceeded 错误同时费用也在飞速上升。正确的做法是维护一个消息窗口——只保留最近 N 轮消息比如 10 轮加上系统 Prompt 和检索到的上下文片段。有人会担心丢了早期信息怎么办解决方案是让模型定期总结之前的长对话把摘要塞进系统 Prompt而不是把原始聊天记录全带上。这是 AI 应用工程里很核心的“上下文管理”思路。6.4 LangChain.js 版本差异教程代码跑不通LangChain.js 的更新速度非常快我写文章时和你看文章时的版本可能已经不一样了。比如早期版本的initializeAgentExecutorWithOptions到新版已经被createReactAgent取代接口变化很大。当你在网上抄了一段 LangChain 代码跑不通时先别怀疑自己大概率是版本问题。我建议的做法是新项目直接看官方文档的最新示例不要把旧教程的完整代码直接粘贴跑通一个功能后把依赖版本固定下来package.json 里锁定精确版本不要用 ^ 前缀避免哪天重新安装依赖后代码突然挂掉。6.5 把整个 PDF 塞给模型费用爆炸还答不对做文档问答时最忌讳的做法是“把整篇 PDF 转成文本然后全塞进 Prompt”。一是大模型输入长度有限二是成本线性上涨三是效果反而更差——模型在超长文本里找不到重点回答质量下降。正确做法是前面讲过的 RAG先切块检索出跟问题最相关的几块内容只把这几块拼进 Prompt。模型只需要在一个小范围内找答案准确率高得多。这个思想就是“检索增强生成”的核心价值也是你在面试中必须能讲清楚的点。7. 从会做到能面试简历和口头表达怎么包装做完了项目下一步就是把它变成面试加分项。很多人的问题不是没项目而是不会表达——简历里写“实现了基于 RAG 的文档问答系统”面试官问“为什么要用 RAG 而不是直接调模型”就愣住了。别慌下面给你一套可以直接套用的表达框架。7.1 简历上别写熟练使用大模型要写解决过什么问题HR 和面试官每天看大量简历“熟悉 LangChain”“熟练使用 OpenAI API”这种描述早就没有区分度了。有区分度的写法是突出你解决了什么实际问题、壳上有什么难点。我建议你参考这个模板扛起项目自研知识库问答系统支持上传 PDF/Word 文档并针对内容提问回答可溯源到原文段落。技术栈Next.js App Router Vercel AI SDK LangChain.js OpenAI Embedding。硬核细节一设计文本切分策略使用 RecursiveCharacterTextSplitter兼顾语义完整性和检索精度。硬核细节二实现基于本地 JSON 的轻量向量检索规避初期依赖外部数据库的成本单机千块文本检索耗时低于 50ms。硬核细节三通过上下文窗口管理控制每轮对话 token 成本在连续对话场景下成本降低约 40%。这里面的每个数字、每个方案你都要能展开讲两分钟。不要写你自己都讲不清楚的东西面试官一定会追问。7.2 面试最容易被追问的五个问题提前准备根据我自己的面试和被面试经验做 AI 应用的前端候选人大概率会被问到这些问题。提前准备好答案比临场发挥靠谱得多为什么要用服务端 API 路由而不是直接在客户端调模型核心答案API Key 安全、避免跨域、统一鉴权与限流。切块的 chunk_size 怎么确定太大会怎样太小会怎样核心答案太大则检索粒度粗、可能超出上下文限制太小则语义不完整、检索噪声大。需要根据文档类型和模型窗口实验调整。如果知识库检索不到答案你会怎么处理核心答案一是调整切分策略二是优化检索方式比如增加关键词过滤三是让模型在 Prompt 里学会“不知道就说不知道”避免强行编造。怎么做流式输出底层原理是什么核心答案SSEServer-Sent Events或 chunked transfer encoding服务端把模型 token 逐块推到客户端客户端用 ReadableStream 解析并增量渲染。你的 Agent 项目里模型选错工具怎么办核心答案低温和强 Prompt 约束能降低概率更进一步可以用“人工审核确认”机制工具执行前先把参数展示给用户确认。这些问题没有一个依赖数学推导全部是关于真实工程设计的理解。你只要真的把项目做下来这些问题基本都能答上。7.3 项目包装的边界感最后提醒一个容易被忽略的点别过度包装。最容易被面试官拆穿的两种说法一是写“精通 LLM 底层原理”结果一问 Transformer 就露馅二是写“实现了大规模分布式向量检索”实际就查了几百条 JSON 数据。宁可诚实写“基于轻量向量检索实现千级文档规模下的可用方案”再表达出你知道大规模场景该怎么迁移这比虚报强得多。面试官最看重的不是你会什么而是你有没有解决问题的思维方式。8. 下一步从文档问答走向真正的 AI Agent 产品做完 RAG 问答助手、聊完面试技巧最后再聊聊这个方向后续还能怎么延伸。RAG 问答只是 AI 应用开发的起点再往上走一步就是当下需求增长最快的 Agent 方向。8.1 两个最值得做的进阶方向对话式数据分析助手让用户用自然语言提问“这个月销售额比上个月涨了多少”系统自动写 SQL、查数据库、用图表库展示结果。这需要前端结合表格/图表渲染能力是很典型的前端优势项目。工作流自动化助手比如“每天早上 9 点抓取竞品价格生成对比报表发到群里”。这里需要定时任务、网络请求、结果推送前端可以结合 Notion API、飞书机器人等公共接口实现。这两个方向都不需要复杂的算法但对工程整合能力要求高恰好是前端转型的舒适区。8.2 用 AI 辅助提升开发效率做这些项目的时候我的切身体会是AI 编程工具是加速器不是替代品。我现在写 Next.js 项目时先用 Cursor 或 Copilot 快速搭出页面骨架再用 AI 帮我写重复性高的表单组件、CRUD 接口然后把主要精力集中在 AI 应用特有的部分——Prompt 设计、检索链路、流式交互调优。以前三天写完的功能现在一天真能完成。这里有个建议别迷信 AI 生成代码生成的代码一定要能看懂。尤其 AI SDK、LangChain 这些更新频繁的库AI 训练数据可能跟不上最新版本生成代码容易用的是旧 API。我的习惯是让 AI 先给我生成一版然后立刻对照官方文档核实 API 用法是否正确没问题再接进去。我一直跟身边想转型的朋友说这么一句话AI 不会取代前端但会用 AI 的前端会取代不用 AI 的前端。你会写 CRUD 只是具备了基本功你能把大模型的能力封装成产品才是这个阶段真正值钱的能力。从今天说的 RAG 问答开始做一个自己的项目跑通、部署、写进简历然后去面试场上把你能讲清楚的细节讲出来。这条路走下来你会发现自己已经不是那个只会写后台管理系统的前端了。