企业官网建设流程全解析

最近被问得最多的一个问题，不是“Next.js 15比14好在哪”，而是“前端还能卷多久”。说句实在话，前端技术本身这两年的迭代不算夸张，真正让人焦虑的是市场对人的要求变了。一个React开发者如果常年泡在管理后台、电商H5、数据报表这类项目里，确实会越做越疲惫——CRUD写三年，本质上就是把同一套增删改查换着皮肤再做一遍。

但我在2024年底到2025年接触了一批做AI应用落地的团队之后，发现一个很明确的信号：AI应用爆发，缺的不是算法工程师，而是能把模型能力“产品化”的人。而这类人，恰好有相当一部分应该来自前端群体。原因不复杂：大模型的能力需要通过界面、交互、工作流变成用户能感知的价值，这恰恰是前端的主场。文章这个标题说“低成本”，我的理解是两层意思：一是前端已有的React基础可以几乎无损迁移到AI应用开发上，二是用Nex.js和LangChain.js这两个工具组合，一个人就能撑起一个AI应用从原型到上线的全流程。

这篇文章不谈虚的，从赛道逻辑、技术选型、最小可用架构到核心代码实现，再到我实际踩过的生产级坑，按一个真实项目的推进顺序拆给你看。适合有React或Next.js基础、想往AI应用方向延伸的前端开发者，也适合团队里需要快速验证一个AI产品原型的全栈同学。

1. 先看清风向：前端工程师的下一波红利在AI应用层

1.1 CRUD内卷的本质是供需错配

很多前端抱怨内卷，说到底是同一个技能栈的人在争夺同一批岗位。当市面上的React/Vue开发者供给远远超过管理后台和营销页的需求量时，公司自然会抬高门槛——八股文越问越偏、面试题越出越怪、薪资预期一再压低。这不是技术问题，是供需问题。

但另一边的供需情况完全反过来了。我接触的不少创业团队和中小公司，他们想做AI客服、AI知识库、AI内容生成工具、垂直行业的AI助手，但团队里没人知道怎么把大模型接进产品里。招一个专职的AI工程师，成本高、周期长，而且很多场景根本不需要从零训练模型，需要的是做工程集成、交互设计和流程编排的人。这种岗位，前端完全接得住。

1.2 AI应用开发正在变成“前端友好”的新增量

大模型应用开发有一个很微妙的变化：模型能力通过API就能调用，不需要本地部署；Prompt工程和工具调用正在成为一门“可学习的技能”，而不只是算法团队的专利；应用形态以对话、内容生成、知识问答为主，天然的交互载体就是网页和应用界面。

换句话说，AI应用的前端，不再是传统意义上“展示数据的壳”，它本身就是产品的核心体验。一个AI写作工具，用户感知到的价值一半来自模型能力，另一半来自编辑器交互、流式打字机效果、历史会话管理、 Prompt参数调节面板——这些全是前端能发挥的地方。

我见过一个做跨境电商客服问答工具的团队，三个人，没有一个算法背景，全套用Next.js加LangChain.js实现，把商品知识库丢给模型，再接上实时库存查询工具，上线两个月就签下了十几个中小商户。这种案例现在越来越多。

1.3 前端知识在AI应用里的真实价值

有些前端觉得自己不懂Python、不懂模型训练，就天然离AI很远。这其实是把AI应用开发和AI模型训练混为一谈了。在绝大多数业务场景里，你不需要动模型权重，你需要的是：

• 把用户的输入整理成模型能理解的上下文结构；
• 在恰当的时候唤起外部工具（查数据库、调接口、搜知识库）；
• 把模型输出的流式内容、结构化数据，优雅地渲染给用户；
• 管理多轮对话的上下文窗口，控制成本；
• 设计让用户理解模型行为的界面反馈机制。

这五件事，哪一件不是前端擅长的？尤其最后一件，绝大多数非前端背景的开发者根本做不好。很多AI产品死掉，不是模型不够强，是产品交互让用户完全摸不着头脑——对话中断了不知道原因，模型在思考却没有视觉反馈，工具报错直接甩一段JSON给用户。这些都是前端能救回来的东西。

2. 为什么偏偏是Next.js和LangChain.js这个组合

2.1 Next.js在AI应用场景里的几个原生优势

选Next.js不是因为它时髦，而是因为它把AI应用需要的几个能力都提前备好了。

第一是API路由能力。传统的React项目是纯前端，要调第三方AI接口还得单独搞一个Node后端做代理、存密钥，部署起来要管两个服务。Next.js的Route Handlers可以直接在应用内部开一个接口，前端页面上发请求调自己的“后端接口”，敏感信息留在服务端，部署成一个统一的应用。对个人开发者和中小团队来说，运维成本省了一大截。

第二是流式渲染和流式响应的配合。AI对话产品几乎全部需要流式输出，也就是模型边生成边吐出文字，用户看到的是打字机效果，而不是白屏等十秒。Next.js的Edge Runtime对ReadableStream的支持很干净，配合服务端组件和客户端组件，实现流式推送比在传统Node服务器上折腾容易得多。

第三是Server Actions和增量静态生成的组合拳。AI应用不是只有聊天，还有大量内容展示场景：生成的文档需要SEO、知识库文章需要静态化、数据看板需要预渲染。Next.js在同一个项目里把这些都解决掉了，不用在多个框架之间迁来迁去。

第四是生态兼容性。React Server Components、Server Actions这些新特性出来的时候，AI工具链的JS版本几乎同步就跟进了。LangChain.js、Vercel AI SDK这些库的文档里，默认示例就是Next.js项目。用Next.js意味着你踩坑时能找到最多的参考案例。

2.2 LangChain.js到底解决了什么问题

LangChain.js是一个面向JavaScript/TypeScript生态的大语言模型应用编排框架。你可以把它理解成“AI应用的胶水层”：它把不同模型提供方（OpenAI、Anthropic、Google以及各类国产模型）、向量数据库、工具调用、Agent逻辑、记忆管理，统一封装成一套相对一致的接口。

没有LangChain.js的时候，你要实现一个带工具调用的Agent，需要自己处理模型返回的tool_call结构、自己拼接多轮对话的消息数组、自己实现Agent循环、自己管理会话历史、自己处理工具执行结果的回填。这一套逻辑链路，正常写下来至少要几百行，而且每个模型提供方的返回格式还有细微差别，换来换去就要重写。

用LangChain.js，这些都有相对标准的抽象：

• 模型统一由ChatModel接口封装，切换模型服务商主要改配置，不用改业务代码；
• 工具调用通过@langchain/core/tools提供的tool()方法，几行代码就能把任意一个普通函数暴露给模型；
• Agent循环在@langchain/langgraph里有预构建的createReactAgent，记忆管理、工具调用、多轮对话的复杂逻辑都被收敛起来了；
• Prompt模板、结构化输出、流式调用都有对应的封装。

一句话概括：LangChain.js的价值不是让代码变得“有AI味”，而是把AI应用开发中大量重复、容易出错的编排工作固化成了标准组件，让你把精力花在产品和场景上。

2.3 JS路线和Python路线怎么选

很多前端犹豫要不要转AI，是先被“Python”这三个字吓退了。这里我直接把两条路线的适用场景摊开看。

结论很直白：如果你的目标是做面向用户的产品和商业化落地，JS/TS路线完全够用。只有当你需要做模型微调、大规模数据预处理、跑评测脚本这类靠后的工作，Python才真正变成刚需。而这类工作，本来就不是前端转型的首选方向。

2.4 其他方案为什么不选

有人会问，直接用模型官方的SDK不行吗？当然可以，做一个简单的问答Demo完全没问题。但一旦需求变复杂——模型要联网搜索、要查数据库、要调用内部API、要理解多轮上下文——你就要开始手写大量胶水代码。LangChain.js的价值正是在这个复杂度分水岭上体现出来的。

也有人会问，Vercel AI SDK不是更简单吗？确实，AI SDK在流式渲染和前端Hooks上体验很棒，我建议你去看一眼。但它的定位更偏“接入层”，Agent编排、工具管理、记忆持久化这些能力需要你自己去搭。LangChain.js则给你提供了更高层的抽象。实际项目里两者不冲突，先用LangChain.js把Agent逻辑编排好，前端接入流式输出时再结合AI SDK的useChat这类Hook，体验很舒服。

还有人会坚持用纯Node.js手写所有逻辑，理由是“不想依赖框架”。这个选择适合学习，不适合做产品。Agent编排里有大量边界情况，比如工具调用结果格式错误时的重试、上下文超长时的截断策略、模型返回异常时的降级处理，框架都帮你打磨过了，裸手写至少要额外踩一个月的坑。

3. 从CRUD思维切换到模型编排思维：AI应用的最小架构

3.1 核心转变：从“操作数据”到“编排模型”

做惯了CRUD的人，第一次写AI应用时常犯一个错：还是用传统后端那种“请求-处理-响应”的定式思维，把模型调用当成一个普通API来调，等结果全部返回之后再做页面渲染。

这个思路在简单场景下能跑通，但完全发挥不出大模型的能力。AI应用的核心在于“编排”——你不再只是处理用户提交的数据，而是要设计一套让模型去理解目标、拆分任务、选择工具、执行动作并返回结果的链路。你的代码价值，很大程度体现在“如何引导模型做出正确决策”上。

举个例子。一个简单的AI日程助手，用户说“帮我约下周一下午三点和客户张总的会”。传统方式是你去解析文本字段，填到表单里。模型编排的方式是：你把这句话连同当前日期、用户的日程上下文传给模型，让模型决定该调用哪个工具、参数是什么，然后你的代码去执行这个工具调用，再把执行结果交给模型生成面向用户的自然语言回复。这时候模型像个“决策中枢”，你的代码则负责提供决策所需的工具。

3.2 一个可落地的三层架构拆解

基于Next.js和LangChain.js的AI应用，我习惯拆成三层：交互层、接口层、编排层。

交互层是React组件，负责用户输入采集、流式文本渲染、对话历史展示、工具执行状态的视觉反馈。这一层用前端开发的经验就能做得很好，关键点是“把模型的思考过程可视化”，下面会细说。

接口层是Next.js的Route Handlers，也就是app/api目录下那些route.ts文件。它们接收前端请求，校验参数，加载环境变量里的密钥，调用编排层的逻辑，再把流式结果以text/event-stream推回前端。接口层的存在是为了安全隔离，绝不把API密钥暴露给浏览器。

编排层是LangChain.js和LangGraph发挥作用的地方：构造Prompt模板、初始化模型、定义工具集、创建Agent、管理会话记忆。这一层是AI应用和后端接口最不一样的地方，也是核心价值所在。

以我常用的经验来看，一个最小但完整的AI应用，代码组织大致是：

app/ page.tsx # 对话界面 api/ chat/ route.ts # 流式接口 lib/ agent.ts # Agent配置与创建 tools/ search.ts # 自定义工具：搜索 weather.ts # 自定义工具：查天气 database.ts # 自定义工具：查业务数据 memory.ts # 会话记忆管理

3.3 为什么AI应用必须走流式输出

传统接口是“攒齐了再发”，AI应用如果也这么做，用户会盯着一个空白页面等上好几秒甚至十几秒——大模型的生成速度还没快到让人无感。流式输出的核心价值不是技术炫技，而是产品体验：用户看到文字一个字一个字出现，会觉得系统“活了”，等待焦虑被大幅稀释。

实现流式输出，服务端要用model.stream()拿到一个异步迭代器，把模型生成的内容分块塞进ReadableStream；前端则通过fetch读响应体，或者用AI SDK的useChat钩子自动处理。这里有个容易踩的坑：如果前端只复制走了Response.json()，流就断了。后面实战部分我会给出完整代码。

3.4 记住记忆、工具、提示词这三个杠杆

用LangChain.js做AI应用，理解三个核心概念基本就上手了。

记忆是让Agent在多轮对话中“有上下文”。大模型本身是无状态的，每次调用你都要把之前的对话内容重新传给模型，问题是怎么传、传多少。LangChain.js里可以用MemorySaver做内存态记忆，也可以把历史消息持久化到Redis或数据库里，下次继续用。这里的坑是上下文窗口有限，不能无限往里面塞历史，需要做摘要或裁剪。

工具是让Agent从“只会说”进化到“能办事”的钥匙。通过tool()包装一个普通函数，再加上一段描述和参数Schema，Agent就能在需要的时候调用它。比如你给Agent一个get_weather工具，用户问“北京天气怎么样”，Agent就会自动发出一个tool_call请求，执行结果回填后生成最终回复。

提示词是让Agent“行为可控”的杠杆。SystemMessage里一段好的指令，比调半天参数都管用。比如你告诉Agent“你不确定的事情要直接说不知道，不要编造”，就能大幅降低幻觉概率。这个在LangChain.js里是一个恒定的SystemMessage，通常放在对话消息数组的第一位。

4. 前端把AI接进产品：从接口到Agent的最小闭环

4.1 搭建项目骨架与依赖安装

我建议直接用Next.js 15的App Router模式建一个新项目。命令很简单：

npx create-next-app@latest ai-app --typescript --tailwind --eslint --app

安装依赖时，核心就三个包：

npm install @langchain/openai @langchain/core @langchain/langgraph

有人会疑惑为什么要装三个包。@langchain/openai负责模型连接——它不仅支持OpenAI官方，也支持兼容OpenAI协议的其他模型服务，配置不同的baseUrl和apiKey就能切换；@langchain/core提供了消息、工具、Prompt这类基础类型；@langchain/langgraph则是Agent编排引擎，提供MemorySaver、createReactAgent这些高层接口。

4.2 第一步：让一个接口能接住LLM的回复

先写一个最简单的对话接口。它接收前端传过来的消息数组，转成LangChain的消息对象，调用模型，返回完整结果。这一步打通了整个链路的起点。

// app/api/chat/route.ts import { NextRequest } from "next/server"; import { ChatOpenAI } from "@langchain/openai"; import { HumanMessage, SystemMessage, AIMessage } from "@langchain/core/messages"; export async function POST(req: NextRequest) { const { messages } = await req.json(); const model = new ChatOpenAI({ model: process.env.MODEL_NAME || "gpt-4o-mini", apiKey: process.env.OPENAI_API_KEY, baseUrl: process.env.OPENAI_BASE_URL, temperature: 0.7 }); const systemMessage = new SystemMessage( "你是一名资深全栈工程师，擅长前端开发和AI应用架构，用简洁专业的方式回答问题。" ); const history = messages.map((m: any) => m.role === "user" ? new HumanMessage(m.content) : new AIMessage(m.content) ); const response = await model.invoke([systemMessage, ...history]); return Response.json({ content: response.content }); }

这里有一个关键点：所有密钥必须放在环境变量里，通过.env.local注入，绝不能硬编码到代码里。Next.js默认会把NEXT_PUBLIC_开头的变量暴露给浏览器，所以密钥变量一定不要加这个前缀。

4.3 第二步：改成流式输出

改造成流式其实只动两个地方。服务端用model.stream()替代model.invoke()，把每个chunk的内容通过ReadableStream推给前端。这一步能直观感受到AI应用的体验分水岭。

// app/api/chat/route.ts（流式版本） import { NextRequest } from "next/server"; import { ChatOpenAI } from "@langchain/openai"; import { HumanMessage, SystemMessage } from "@langchain/core/messages"; export async function POST(req: NextRequest) { const { messages } = await req.json(); const model = new ChatOpenAI({ model: process.env.MODEL_NAME || "gpt-4o-mini", apiKey: process.env.OPENAI_API_KEY, baseUrl: process.env.OPENAI_BASE_URL, }); const stream = await model.stream([ new SystemMessage("你是一名资深全栈工程师，请用简洁专业的方式回答问题。"), ...messages.map((m: any) => m.role === "user" ? new HumanMessage(m.content) : new HumanMessage(m.content) ) ]); const encoder = new TextEncoder(); const readable = new ReadableStream({ async start(controller) { for await (const chunk of stream) { controller.enqueue(encoder.encode(JSON.stringify({ content: chunk.content }))); } controller.close(); } }); return new Response(readable, { headers: { "Content-Type": "text/event-stream" } }); }

前端用fetch读流时，要注意一点：response.body.getReader()拿到的流需要逐块解码。如果嫌麻烦，直接把流式逻辑封装成一个自定义Hook，或者用AI SDK的useChat，它连消息状态管理、流式渲染都帮你做完了。

4.4 第三步：给Agent装上“手和脚”

对话接口只能问答，只有工具调用才能让Agent解决实际问题。这里以一个查天气工具为例，演示LangChain.js的工具定义与Agent拼接。

// lib/tools/weather.ts import { tool } from "@langchain/core/tools"; import { z } from "zod"; export const getWeather = tool( async ({ city }) => { // 这里替换成真实天气API // 注意：工具执行结果是一段文本，LangChain会把它回填给模型 return `${city}当前天气：晴，气温26℃，东南风2级`; }, { name: "get_weather", description: "查询指定城市的实时天气情况。当用户询问天气时使用。", schema: z.object({ city: z.string().describe("要查询天气的城市名称") }) } );

创建Agent并执行：

// lib/agent.ts import { ChatOpenAI } from "@langchain/openai"; import { createReactAgent } from "@langchain/langgraph/prebuilt"; import { MemorySaver } from "@langchain/langgraph"; import { getWeather } from "./tools/weather"; export const agent = createReactAgent({ llm: new ChatOpenAI({ model: process.env.MODEL_NAME || "gpt-4o-mini", apiKey: process.env.OPENAI_API_KEY, baseUrl: process.env.OPENAI_BASE_URL, }), tools: [getWeather], checkpointSaver: new MemorySaver() });

然后在一个接口里调用：

import { agent } from "@/lib/agent"; import { HumanMessage } from "@langchain/core/messages"; export async function POST(req: NextRequest) { const { message } = await req.json(); const result = await agent.invoke({ messages: [new HumanMessage(message)] }); const lastMessage = result.messages[result.messages.length - 1]; return Response.json({ content: lastMessage.content }); }

用户问“北京今天适合穿短袖吗”，Agent会自动判断需要调用get_weather工具，查出“晴、26℃”之后，再组织语言给出建议。前端开发者熟悉的业务逻辑，比如查库存、查订单、写数据库，都可以用同样的方式暴露给Agent，这就是AI应用接进现有业务系统的基本路径。

4.5 加一点记忆，Agent才算是Agent

没有记忆的Agent，每轮对话都是“失忆”的。用户上一句说了自己的名字，下一句就忘了。要给Agent加短期记忆，前面代码里的MemorySaver已经在做这件事了——它在服务端进程内保存每个会话的消息历史。

但MemorySaver是内存态，服务重启就没了。生产环境要持久化，LangGraph提供了一种方式：自定义CheckpointSaver，把消息历史写入Redis或数据库。前端需要做的，是在每次请求时传入一个thread_id，Agent会按这个ID去取历史消息。

const result = await agent.invoke( { messages: [new HumanMessage(message)] }, { configurable: { thread_id: userId } } );

这个设计让我想起早期前后端分离时大家从session过渡到token的经历——AI应用里，thread_id就是你的“会话令牌”。多轮对话的状态管理，在框架层面被抽象掉了，前端只需要约束好用户标识的生成与传递。

5. Demo好写，生产难：这几个坑我替你踩过了

5.1 流式数据的前端状态管理

用ReadableStream推流时，前端最常见的问题是“读了半天，页面上没反应”。原因通常是JSON序列化格式不统一——服务端每块都包了一层{ content: chunk.content }，前端却只解析了第一块；或者事件流忘了加换行符，导致解析器识别不了。

我的建议是：第一版统一用text/event-stream格式，每条数据之间用\n\n分隔。前端用EventSource标准方式去解析，代码干净，排查方便。不要把流的格式设计得太花哨，这跟不要在一开始就引入GraphQL是同一个道理。

5.2 长连接的超时与重试机制

AI模型响应慢一点很正常，但大模型服务经常出现长时间pending或返回前就断连的情况。生产环境必须考虑：

• 网关层超时设置要放宽，至少留足60秒的生成窗口；如果用Edge Runtime部署，注意平台本身的执行时长限制；
• 前端要有“重试”按钮，并在UI上明确区分“正在等待模型返回”和“网络请求失败”；
• 调用模型接口时做好自动重试，但需要限制重试次数，并做指数退避，防止模型服务过载时无限请求。

这里分享一个经验：把流程分成“快速失败”和“慢速等待”两段。例如用户提交请求后，先立刻返回一个会话ID，前端进入“已接收”状态；模型真正跑完后再通过长轮询或WebSocket推送结果。这样用户体验上永远不会出现“卡死”的错觉。

5.3 API Key必须留在服务端，一个都不能漏

只要你在前端代码里用环境变量拼接过apiKey，接下来就是事故时间。Next.js的NEXT_PUBLIC_前缀变量会打进浏览器包，直接暴露。只在服务端Route Handler或Server Action里读取process.env.OPENAI_API_KEY，这是底线。

另外，生产部署时建议给API接口加一层简单的访问限制：至少校验一下来源域名或用户Token，防止别人扒到你的接口地址后疯狂调用来刷你的模型额度。这种案例在公网上非常多见。

5.4 上下文膨胀：AI应用的成本黑洞

每次对话都把完整历史丢给模型，成本会随对话轮数线性上涨。用户聊了半小时之后，模型要处理的Token数可能已经翻了十几倍，响应变慢、账单变厚，效果还未必更好。

常用的做法有三种：第一种是做历史截断，只保留最近N轮消息；第二种是做历史摘要，让模型把较早的对话压缩成几句话的摘要，替换原始消息；第三种是结合业务场景做“只取最近相关片段”，通过语义检索只把和当前问题最相关的历史消息传进去。这个思路在LangChain.js里对应不同的记忆策略，实际项目中我一般用“摘要+最近N轮”的组合方案，成本可控且效果不差。

我的习惯是：所有这类决策都打点记录，过一阵子回来看看实际成本和留存效果，再做调整。没有数据支撑，别轻信哪种策略一定最好。

5.5 别让模型“一本正经地胡说八道”

大模型的幻觉问题绕不开，尤其当你的Agent会调用工具时，失败模式更隐蔽：工具返回了结果，但模型生成回复时添油加醋，编造了工具没给出的信息。比如查库存，工具返回“A商品剩余3件”，模型可能补一句“建议您尽快下单”，这话本身无害；但如果生成的是“该商品明天到货”，就是凭空捏造。

我常用的几个缓解手段：

• 在SystemMessage里写死规则：只基于工具返回内容作答，不要推测未知信息；
• 对结构化输出使用withStructuredOutput()，强制模型按JSON Schema返回，降低自由发挥空间；
• 关键数据以工具结果为准，UI上把“模型生成的文案”和“实际业务数据”分开展示，让用户自己能判断。

这些无法做到100%消除幻觉，但可以把风险压到产品可接受的范围内。最重要的是，不要因为幻觉就全盘否定模型的能力，工程上要想的是怎么用流程和UI兜底。

6. 低成本上桌的执行路径

6.1 先把一个垂直场景做穿，不要学一堆概念

LangChain.js的文档很长，概念很多，看一遍还能记住的很少。我的建议是不要从框架出发去学，而是从一个具体场景开始做。比如“做一个能查天气、能订会议室、能写周报的团队助手”，然后看着文档把工具、Agent、记忆一个接一个拼进去。

这和我当年学React的路径一模一样：不是先把Redux全家桶背完才开始写页面，而是写了一个TodoList，遇到状态管理痛了，再去找Redux。做AI应用更是这样，因为模型的能力边界你只有亲手试过才知道。

6.2 用三个月搭一条学习链路

如果从零开始，我给前端朋友推荐这样的节奏：

第一个月，吃透“一个模型调用闭环”：用Next.js搭一个能流式聊天的页面，把Prompt调优、上下文管理、错误处理都走一遍。这个阶段目标是理解AI应用的最小闭环，不贪多。

第二个月，主攻工具调用与Agent：把你的业务系统里的两三个API包成LangChain工具，让Agent学会按条件调用。这是从“聊天机器人”迈入“AI应用”的关键一步，也是面试时最能拿出来讲的项目亮点。

第三个月，做完整产品并部署上线：给应用加上持久化记忆、用户鉴权、成本监控、用量统计，部署到生产环境（Vercel、国内云函数、容器服务都行）。把“上线后Monitor发现的问题怎么修的”写进你的复盘笔记里，这比吹技术选型有说服力得多。

6.3 简历和作品集上真正加分的点

前端转型AI应用，面试官最怕的是“只会挂个ChatGPT的壳”。你要在作品集里展示的，一定是最能体现“工程价值”的部分。

至少包括三个东西：一是流式输出的完整链路实现，讲清楚前端如何接收、解析、渲染流数据；二是工具调用设计方案，说明你如何把一个业务系统的现有能力暴露给模型，并举出工具调用成功和失败的具体案例；三是成本与质量取舍，描述你如何通过上下文裁剪、模型分级、缓存等手段控制调用成本。

做过一次真实上线项目，这些要素都会自然长在你身上。面试时直接打开项目演示一遍流式对话加工具调用，比什么都好使。这也是我推荐你用Next.js加LangChain.js做产品的另一个原因——它产出的直接就是一个可用、可演示、可量化的项目，而不是一个躺在本地的Demo代码。

我个人做下来的体会是，前端转AI应用开发，真正难的不是技术，而是把自己从“等待需求的人”调整成“用模型能力创造产品的人”。一旦转过这个弯，你手里的React功底和产品思维就成了很稀缺的复合能力。先把一个完整的Agent应用跑上线，再回头看市场和机会，你会发现路比想象中宽。