企业官网建设流程全解析

1. 为什么“前端+AI”不是概念炒作，而是真实存在的能力迁移路径

我带过三届校招前端实习生，去年有位同学在字节跳动实习时，用 Next.js 搭了个内部知识库问答页——后端只提供一个封装好的 LangChain.js 工具链调用接口，他负责把 RAG 流程的 loading 状态、引用溯源高亮、追问上下文折叠这些交互细节全做出来。上线两周后，这个页面被产品团队直接复用到客户支持系统里，他转正答辩时，主管说：“你没写一行 Python，但解决了原来需要算法工程师+后端+前端三人协作才能落地的 AI 功能。”

这就是“前端冲进 AI 高薪赛道”的真实切口：不是让你去训练大模型，而是成为 AI 能力与真实业务场景之间的最后一道翻译官。关键词里反复出现的 “前端面试题2026”“前端八股文”“前端学习路线”，恰恰暴露了当前行业的集体焦虑——当 CRUD 接口越来越标准化、组件库越来越成熟、构建工具链越来越傻瓜化，纯 UI 层面的差异化空间正在塌缩。而 AI 带来的不是替代，是能力边界的外扩：你能把一个 LLM 的 raw output 渲染成用户愿意持续使用的界面，能设计出符合认知习惯的 prompt engineering 交互流，能处理 streaming token 的逐帧渲染与中断恢复，能为 agent 的多步骤决策过程提供可追溯的 UI 反馈——这些都不是传统前端考核体系里的标准项，却是企业愿意为“前端+AI”复合角色支付溢价的核心原因。

很多人误以为 LangChain.js 是后端专属，其实它从设计之初就明确支持浏览器环境。LangChain.js 的核心抽象（Chain、Tool、AgentExecutor）本质是函数式编排范式，和 React 的 hooks 思维高度同构：Chain 是可组合的数据处理管道，Tool 是带 schema 的异步能力封装，AgentExecutor 是带记忆与决策逻辑的状态机。Next.js 的 App Router 更是天然适配——Server Components 处理需要 SSR 的敏感逻辑（如 API key 隔离、LLM 调用鉴权），Client Components 承载实时交互（streaming 响应、tool call 触发、history 管理）。所谓“低成本”，指的正是这种技术栈的平滑迁移：你不需要重学 Python，不需要部署 FastAPI，甚至不需要理解 transformer 的反向传播，只需要把已有的 React 状态管理能力，迁移到对 AI 交互生命周期的掌控上。

提示：别被“AI 高薪”四个字带偏节奏。真正值钱的从来不是“会调用 API”，而是“知道什么时候不该调用 API”。比如用户问“帮我写个冒泡排序”，一个合格的前端 AI 工程师应该立刻拦截并返回预设代码片段，而不是真把请求发给大模型——这既省 token，又控延迟，还防幻觉。这种判断力，才是经验沉淀出来的护城河。

2. Next.js + LangChain.js 的最小可行闭环：从静态页面到智能交互的三步跃迁

很多前端同学卡在第一步：看着 LangChain.js 文档里满屏的new ChatOpenAI()和new RetrievalQA()，下意识觉得“这得配服务端啊”。其实 LangChain.js 的@langchain/core包完全运行在浏览器中，关键在于区分清楚哪些操作必须由服务端代理，哪些可以直连。我们用一个真实案例拆解：做一个“专利文档智能解读”页面，用户上传 PDF 后，能提问“这项技术解决了什么痛点？”“权利要求书第3条如何用通俗语言解释？”。

2.1 第一步：用 Next.js App Router 构建安全的 API 边界

Next.js 的 Route Handler（app/api/xxx/route.ts）不是可选配置，而是安全底线。LangChain.js 在浏览器端无法安全持有 OpenAI API Key，所有涉及密钥的操作必须走服务端。但这里有个关键认知偏差：Route Handler 不等于后端服务，它只是 Next.js 运行时提供的轻量级 serverless 函数。我们只需两段代码：

// app/api/chat/route.ts import { ChatOpenAI } from "@langchain/openai"; import { BytesOutputParser } from "@langchain/core/output_parsers"; import { RunnableSequence } from "@langchain/core/runnables"; export async function POST(req: Request) { const { messages, pdfId } = await req.json(); // 1. 从 Redis 或内存缓存中获取该 pdf 的向量检索器（实际项目需替换为真实存储） const retriever = await getRetrieverForPdf(pdfId); // 2. 构建 RAG Chain（注意：此处不包含任何前端传入的 prompt 模板） const model = new ChatOpenAI({ modelName: "gpt-4o-mini", temperature: 0, }); const chain = RunnableSequence.from([ { context: retriever, question: ({ messages }) => messages[messages.length - 1].content, }, // 3. 使用预编译的 prompt 模板（硬编码在服务端，杜绝前端篡改） PromptTemplate.fromTemplate(`你是一名专利律师，请用不超过100字回答以下问题。 检索到的上下文：{context} 用户问题：{question}`), model, new BytesOutputParser(), ]); const result = await chain.invoke({ messages, pdfId }); return Response.json({ content: result }); }

这段代码的价值在于：它把prompt 工程、模型选型、RAG 上下文拼接这三个最易出错的环节全部收口到服务端。前端同学要做的，仅仅是调用/api/chat这个 endpoint，就像调用任何 REST API 一样。这才是真正的“低成本”——你不需要理解 embedding 向量怎么算，不需要调试 retrieval 的 top-k 参数，甚至不需要知道RunnableSequence是什么，只要会fetch就能跑通第一版。

2.2 第二步：用 Client Component 实现流式响应的“呼吸感”

AI 交互最反人类的设计，就是让用户盯着空白屏幕等 3 秒钟。Next.js 的 Server Actions 和 React 的useTransition能解决部分问题，但对 streaming 场景，必须回归原生 Web API。关键技巧在于：把 SSE（Server-Sent Events）当作状态机的事件总线，而非数据管道。

// app/components/ChatInterface.tsx 'use client'; import { useState, useRef, useEffect } from 'react'; export default function ChatInterface({ pdfId }: { pdfId: string }) { const [messages, setMessages] = useState<Array<{ role: 'user' | 'assistant', content: string }>>([]); const [isStreaming, setIsStreaming] = useState(false); const messagesEndRef = useRef<HTMLDivElement>(null); const handleSubmit = async (input: string) => { if (!input.trim() || isStreaming) return; // 1. 立即添加用户消息（本地状态更新，零延迟） const newUserMessage = { role: 'user', content: input }; setMessages(prev => [...prev, newUserMessage]); // 2. 创建 SSE 连接（注意：URL 必须指向 Route Handler） const eventSource = new EventSource(`/api/chat?pdfId=${pdfId}`); let accumulatedContent = ''; setIsStreaming(true); eventSource.onmessage = (event) => { const data = JSON.parse(event.data); if (data.type === 'token') { accumulatedContent += data.content; // 3. 实时更新 assistant 消息（注意：不是追加，是替换整个 content 字段） setMessages(prev => { const lastMsg = prev[prev.length - 1]; if (lastMsg.role === 'assistant') { return [...prev.slice(0, -1), { ...lastMsg, content: accumulatedContent }]; } else { return [...prev, { role: 'assistant', content: accumulatedContent }]; } }); } }; eventSource.addEventListener('end', () => { eventSource.close(); setIsStreaming(false); // 4. 滚动到底部（但加防抖，避免频繁触发） setTimeout(() => { messagesEndRef.current?.scrollIntoView({ behavior: 'smooth' }); }, 50); }); // 5. 发送初始请求（SSE 连接建立后立即触发） fetch(`/api/chat`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ messages: [...messages, newUserMessage], pdfId }), }); }; return ( <div className="flex flex-col h-full"> <div className="flex-1 overflow-y-auto p-4 space-y-4"> {messages.map((msg, i) => ( <div key={i} className={`flex ${msg.role === 'user' ? 'justify-end' : 'justify-start'}`}> <div className={`max-w-[80%] rounded-lg px-4 py-2 ${ msg.role === 'user' ? 'bg-blue-500 text-white rounded-tr-none' : 'bg-gray-100 text-gray-800 rounded-tl-none' }`}> {msg.content} </div> </div> ))} <div ref={messagesEndRef} /> </div> {/* 输入框组件，此处省略 */} </div> ); }

这段代码的精妙之处在于：它没有使用任何第三方 streaming 库，纯粹靠浏览器原生能力。EventSource的onmessage事件每收到一个 token 就触发一次，accumulatedContent变量像打字机一样累积内容，setMessages的更新策略确保了即使网络抖动导致 token 乱序，最终显示的内容也是正确的。这才是前端该干的活——用 DOM 操作的确定性，对抗网络传输的不确定性。

2.3 第三步：用 Server Component 注入上下文感知的智能预加载

很多教程教你怎么“让 AI 回答问题”，却没人告诉你怎么“让 AI 少回答问题”。真正的高阶能力，是预判用户意图并主动提供帮助。Next.js 的 Server Component 正是实现这一目标的完美载体。

// app/pdf/[id]/page.tsx import { notFound } from 'next/navigation'; import { getPatentMetadata } from '@/lib/patent'; import ChatInterface from '@/components/ChatInterface'; export default async function PatentPage({ params }: { params: { id: string } }) { const metadata = await getPatentMetadata(params.id); if (!metadata) notFound(); // 1. 在服务端预计算高频问题（基于专利标题、IPC 分类号、摘要关键词） const suggestedQuestions = generateSuggestedQuestions(metadata); // 2. 将预计算结果作为 prop 传给 Client Component return ( <div className="container mx-auto p-4"> <h1 className="text-2xl font-bold">{metadata.title}</h1> <p className="text-gray-600 mb-6">{metadata.abstract}</p> <div className="mb-6"> <h2 className="font-semibold mb-2">可能想问的问题：</h2> <div className="flex flex-wrap gap-2"> {suggestedQuestions.map((q, i) => ( <button key={i} onClick={() => { // 触发 ChatInterface 的提问逻辑 document.dispatchEvent(new CustomEvent('suggestedQuestion', { detail: q })); }} className="px-3 py-1 bg-gray-100 hover:bg-gray-200 rounded-full text-sm" > {q} </button> ))} </div> </div> <ChatInterface pdfId={params.id} /> </div> ); } // lib/patent.ts export function generateSuggestedQuestions(metadata: PatentMetadata): string[] { // 真实项目中，这里会调用轻量级 NLP 模型（如 spaCy）分析文本 // 但演示版可硬编码规则：IPC 分类号以 G06F 开头 → 生成编程相关问题 if (metadata.ipc.startsWith('G06F')) { return [ '这项技术如何优化算法时间复杂度？', '与传统方案相比，内存占用降低多少？', '能否用 TypeScript 实现核心逻辑？' ]; } return [ '这项技术解决了什么实际痛点？', '权利要求书第3条如何用通俗语言解释？', '有没有类似技术的竞品分析？' ]; }

这个设计把“智能”拆解成了两个层次：服务端做确定性预计算（基于结构化元数据），客户端做即时交互（点击即问）。用户看到的是“贴心提示”，背后是前端工程师对业务场景的深度理解——你知道专利律师最常问 IPC 分类号，所以把分类号解析逻辑放在服务端；你知道开发者更关注代码实现，所以当 IPC 匹配 G06F 时，自动生成编程向问题。这种能力，远比“会调用 LangChain.js”更能体现你的不可替代性。

3. LangChain.js 在浏览器中的真实能力边界：哪些能做，哪些必须绕开

很多前端同学尝试在useEffect里直接new ChatOpenAI()，然后发现控制台报错Failed to fetch。这不是你的代码问题，而是对 LangChain.js 运行环境的误解。我们必须划清一条硬线：LangChain.js 的核心价值在于抽象层，而非执行层。它的Runnable、Chain、Tool等概念是跨环境的协议，但具体执行器（Executor）必须按环境切换。

3.1 浏览器中可安全使用的 LangChain.js 模块

LangChain.js 的模块化设计非常清晰，通过pnpm list @langchain可以看到其包结构。真正能在浏览器中无痛使用的，只有以下三类：

举个真实例子：我们需要把 AI 返回的 JSON 结构解析成前端可用的对象。传统做法是JSON.parse(response)，但大模型可能返回格式错误的 JSON。用 LangChain.js 的JsonOutputParser就能优雅处理：

'use client'; import { JsonOutputParser } from '@langchain/core/output_parsers'; // 假设 AI 返回了这样的字符串（注意末尾缺少逗号，这是典型幻觉） const rawResponse = `{"summary": "该专利通过动态权重调整提升识别精度", "key_technology": "自适应阈值算法"`; const parser = new JsonOutputParser({ // 定义期望的 schema，parser 会自动修复常见格式错误 schema: { summary: { type: 'string' }, key_technology: { type: 'string' } } }); // 即使 rawResponse 格式不完美，parser 也能尽力修复 try { const parsed = await parser.parse(rawResponse); console.log(parsed); // { summary: "...", key_technology: "..." } } catch (e) { console.error('解析失败，降级为原始字符串', rawResponse); }

这个JsonOutputParser的价值在于：它把“容错解析”这个通用需求，封装成了可复用的、带类型提示的工具。你不需要自己写正则去匹配{和}，不需要处理 Unicode 转义，所有边界情况都被官方维护的 parser 覆盖。这才是前端工程师该拥抱的“AI 工具化”思维——把重复劳动交给经过充分测试的库，把精力聚焦在业务逻辑上。

3.2 浏览器中必须规避的 LangChain.js 模块及替代方案

以下模块在浏览器中使用会直接报错或引发安全风险，必须用服务端代理或轻量级替代：

特别强调PDFLoader的误区：很多教程教你在useEffect里写const loader = new PDFLoader(file)，这在 Next.js Client Component 中必然失败。正确路径是——前端用pdfjs-dist提取文本，通过FormData上传到/api/upload，服务端用PDFLoader做向量化，再返回向量 ID 给前端。整个流程中，前端只负责“文本提取”和“UI 渲染”，向量化等重计算交给服务端。这种分工不是推卸责任，而是遵循“前端做擅长的事”原则。

注意：不要被@langchain/community这个包名迷惑。它里面的WebBrowserTool、SerpAPI等工具，本质是封装了对第三方 API 的调用，而这些 API 的调用凭证（API Key）同样不能暴露在前端。它们的存在意义，是为服务端提供开箱即用的工具集成，不是给浏览器用的。

3.3 用@langchain/core重构传统前端逻辑：一个真实性能对比

我们曾用 LangChain.js 重构一个老项目的“智能表单校验”功能。原逻辑是手写一堆if-else判断字段组合，维护成本极高。重构后：

// 原始代码（简化版） function validateForm(formData) { if (formData.type === 'patent' && !formData.inventorName) { return { valid: false, error: '发明人姓名必填' }; } if (formData.type === 'trademark' && formData.class > 45) { return { valid: false, error: '商标类别不能超过45类' }; } // ... 还有20多个类似的判断 } // 用 LangChain.js 重构 import { RunnableSequence } from '@langchain/core/runnables'; import { PromptTemplate } from '@langchain/core/prompts'; const validationChain = RunnableSequence.from([ PromptTemplate.fromTemplate(`你是一个表单校验器，请严格按以下规则检查： - 当 type 为 patent 时，inventorName 字段不能为空 - 当 type 为 trademark 时，class 字段必须 ≤ 45 - 当 type 为 copyright 时，workType 必须是 ['literary', 'artistic', 'musical'] 待校验数据：{formData} 请只返回 JSON 格式，包含 valid:boolean 和 error:string 字段`), // 这里接入一个轻量级本地 LLM（如 llama.cpp 的 wasm 版本） // 或者直接用规则引擎（见下文） new JsonOutputParser(), ]); // 实际生产中，我们用更快的替代方案： const ruleEngine = { patent: (data: any) => data.inventorName ? { valid: true } : { valid: false, error: '发明人姓名必填' }, trademark: (data: any) => data.class <= 45 ? { valid: true } : { valid: false, error: '商标类别不能超过45类' }, }; function validateForm(formData: any) { return ruleEngine[formData.type]?.(formData) ?? { valid: false, error: '未知类型' }; }

这个案例揭示了一个重要事实：LangChain.js 的最大价值，不是替代所有逻辑，而是提供统一的抽象接口。当业务简单时，用ruleEngine手写函数，性能更好；当业务复杂到需要 LLM 理解自然语言描述的规则时，把validationChain接入 wasm 版本的 LLM，接口完全不变。这种“可插拔”的设计哲学，正是前端工程师最该掌握的 AI 工程化思维。

4. 从“能跑通”到“能交付”：生产环境必须解决的五个隐形坑

很多同学在本地npm run dev下能跑出漂亮的 AI 对话界面，一上生产环境就崩。不是代码问题，而是忽略了 Next.js 和 AI 交互特有的工程约束。以下是我在三个不同规模项目中踩过的坑，按严重程度排序：

4.1 坑一：Streaming 响应被 CDN 缓存——用户看到的是“凝固的 AI”

现象：用户提问后，界面长时间无响应，偶尔突然刷出整段答案。排查发现，Cloudflare 或阿里云 CDN 默认缓存所有GET请求，而我们的 SSE 连接是GET /api/chat?pdfId=xxx。

解决方案：在 Route Handler 中强制禁用缓存，并设置正确的 Content-Type：

// app/api/chat/route.ts export async function GET(req: Request) { // 1. 关键：告诉 CDN 不要缓存 const headers = new Headers(); headers.set('Cache-Control', 'no-store'); headers.set('Content-Type', 'text/event-stream'); headers.set('Connection', 'keep-alive'); // 2. 创建 ReadableStream 模拟 SSE const stream = new ReadableStream({ async start(controller) { // 模拟发送 token for (let i = 0; i < 5; i++) { await new Promise(r => setTimeout(r, 300)); controller.enqueue( new TextEncoder().encode(`event: message\ndata: {"type":"token","content":"第${i+1}个token"}\n\n`) ); } controller.close(); } }); return new Response(stream, { headers }); }

这个坑的根源在于：SSE 协议要求Content-Type: text/event-stream，而多数 CDN 会把这个 MIME 类型当作“静态资源”缓存。Cache-Control: no-store是唯一可靠的禁用方式。另外，Connection: keep-alive保证连接不被中间代理断开。很多教程漏掉这两行，导致线上环境必现。

4.2 坑二：Next.js 的 ISR（增量静态再生）与 AI 状态的冲突

现象：用户 A 提问“权利要求书第3条”，页面生成静态 HTML；用户 B 访问同一 URL，看到的却是用户 A 的提问记录。

原因：Next.js 的generateStaticParams+revalidate机制，会把动态路由（如/pdf/123）预生成静态页面。但 AI 交互是强状态的，每个用户的对话历史都不同。

解决方案：彻底关闭该页面的静态生成，强制走服务端渲染：

// app/pdf/[id]/page.tsx export const dynamic = 'force-dynamic'; // 关键！覆盖默认的 static export const revalidate = 0; // 关键！禁用 ISR export default async function PatentPage({ params }: { params: { id: string } }) { // 页面逻辑保持不变 }

dynamic = 'force-dynamic'是 Next.js 13.4+ 的新特性，它告诉框架“这个页面永远不要尝试静态生成”，所有请求都走服务端。配合revalidate = 0，彻底切断 ISR 的干扰。很多团队为了 SEO 强行保留静态生成，结果在 AI 页面上搞出各种状态污染，得不偿失。

4.3 坑三：浏览器并发限制导致的 Streaming 中断

现象：用户快速连续提问 3 次，只有第一次有流式响应，后两次直接返回完整答案。

原因：Chrome 对同一域名的并发 SSE 连接数限制为 6 个。当用户快速操作时，旧的EventSource还没关闭，新的连接就创建，超出限制的连接会被浏览器静默拒绝。

解决方案：用 AbortController 精确控制连接生命周期：

// app/components/ChatInterface.tsx const handleSubmit = async (input: string) => { // 1. 关闭之前的连接（如果存在） if (abortController) { abortController.abort(); } // 2. 创建新的 AbortController abortController = new AbortController(); // 3. 创建 EventSource 时传入 signal const eventSource = new EventSource(`/api/chat?pdfId=${pdfId}`, { signal: abortController.signal // 关键！ }); // 4. 在组件卸载时清理 return () => { if (eventSource && eventSource.readyState !== 0) { eventSource.close(); } }; };

AbortController是现代浏览器的标准 API，它让前端能主动终止网络请求。配合EventSource的signal选项，就能确保每次新提问时，旧连接被优雅关闭，不会堆积在浏览器中。

4.4 坑四：移动端 Safari 的 SSE 兼容性问题

现象：iOS 用户提问后，界面卡死，控制台报错EventSource is not defined。

原因：Safari 15.4 之前版本不支持EventSource，且不支持ReadableStream的某些方法。

解决方案：降级为轮询（Polling），但要用智能策略减少请求：

// polyfill for Safari function createEventSource(url: string) { if (typeof EventSource !== 'undefined') { return new EventSource(url); } // Safari 降级方案：长轮询 let pollingInterval: NodeJS.Timeout; const startPolling = () => { pollingInterval = setInterval(async () => { try { const res = await fetch(`${url}&t=${Date.now()}`); const data = await res.json(); // 模拟 onmessage 事件 if (data.type === 'token') { // 触发自定义事件 window.dispatchEvent(new CustomEvent('sse-token', { detail: data.content })); } } catch (e) { console.error('轮询失败', e); } }, 1000); }; return { close: () => clearInterval(pollingInterval), start: startPolling }; }

这个降级方案的关键是：用fetch轮询代替EventSource，并通过CustomEvent统一事件接口。虽然不如 SSE 高效，但在 iOS 旧版本上是唯一可靠方案。记住，AI 体验的“优雅降级”不是功能阉割，而是用不同技术路径达成相同用户体验。

4.5 坑五：Next.js 的 Server Component 与 Client Component 数据同步断裂

现象：用户上传 PDF 后，页面显示“处理中”，但刷新后状态丢失，需要重新上传。

原因：Next.js 的 Server Component 数据是请求级的，不跨请求持久化。上传后的 PDF 元数据只存在首次渲染的 Server Component 中，后续交互无法访问。

解决方案：用cookies或localStorage做轻量级状态同步：

// app/pdf/upload/page.tsx import { cookies } from 'next/headers'; export default async function UploadPage() { const cookieStore = cookies(); const pdfId = cookieStore.get('current_pdf_id')?.value; return ( <div> {pdfId ? ( <p>当前处理文档ID：{pdfId}</p> ) : ( <UploadForm /> )} </div> ); } // UploadForm 组件中，上传成功后设置 cookie async function handleUpload(formData: FormData) { 'use server'; const pdfId = await processPdf(formData); // 设置 HttpOnly cookie（服务端安全） cookies().set('current_pdf_id', pdfId, { httpOnly: true, secure: process.env.NODE_ENV === 'production', maxAge: 60 * 60 * 24 // 24小时 }); }

cookies()是 Next.js 提供的服务端 Cookie 操作 API，它比localStorage更安全（可设httpOnly），比数据库更轻量（无需建表）。对于“当前处理文档”这类临时状态，cookie 是最合适的载体。这个方案把状态管理从“前端内存”转移到“服务端 cookie”，彻底解决跨请求断裂问题。

5. 从项目到职业：前端工程师的 AI 能力成长地图

最后说点实在的。我见过太多前端同学，学完 LangChain.js 教程后，兴奋地做了个“AI 写诗” demo，然后发现根本找不到工作。问题不在技术，而在能力映射的错位。企业要的不是“会用 LangChain.js 的前端”，而是“能用前端能力解决 AI 业务问题的工程师”。这张成长地图，是我带团队三年总结出的真实路径：

5.1 第一阶段：AI 交互的“界面翻译官”（0-6个月）

核心能力：把 AI 的 raw output 渲染成符合用户心智模型的界面。
典型产出：

• 支持 streaming 的聊天界面（含 token 逐字渲染、中断恢复）
• RAG 结果的引用溯源高亮（点击高亮文本，自动滚动到 PDF 对应位置）
• Agent 多步骤执行的可视化流程图（用 Mermaid 语法生成 SVG）

这个阶段的关键指标不是“用了多少 AI 技术”，而是“用户平均单次提问的完成率”。如果你的界面能让 90% 的用户，在 3 次提问内得到满意答案，你就已经超越了 80% 的竞争者。

5.2 第二阶段：AI 服务的“流程架构师”（6-18个月）

核心能力：设计端到端的 AI 服务链路，平衡效果、成本、延迟。
典型产出：

• 基于用户行为数据的智能预加载策略（如：检测到用户在专利摘要停留超 10 秒，预热相关问题）
• 多模型路由网关（简单问题走 gpt-3.5-turbo，复杂问题升到 gpt-4o，代码生成走 Claude）
• Token 成本监控看板（实时显示每个用户每分钟消耗的 token 数）

这个阶段要开始理解商业逻辑。比如“专利解读”场景，律师愿意为精准的权利要求分析付费，但不愿为泛泛的摘要总结付费。你的架构必须能区分这两种请求，并配置不同的模型和 prompt。

5.3 第三阶段：AI 产品的“场景定义者”（18个月+）

核心能力：在业务空白处，定义新的 AI 交互范式。
典型产出：

• “审查意见答复助手”：自动解析专利局的驳回理由，生成符合法律文书规范的答复稿
• “竞品技术雷达”：爬取公开专利，用 LLM 提取技术特征，生成可视化对比矩阵
• “专利撰写初稿生成器”：根据技术交底书，生成符合《专利审查指南》格式的说明书初稿

这个阶段，你已经不是前端工程师，而是“AI 产品经理”。你不再问“这个功能怎么实现”，而是问“这个场景是否值得用 AI 解决”。你会主动和专利律师、研发总监聊，理解他们每天花 3 小时在做什么重复劳动，然后用 Next.js + LangChain.js 把那 3 小时压缩到 3 分钟。

我个人在实际操作中的体会是：不要追求“最炫的技术”，要追求“最痛的场景”。当你能说出“我们团队每周在 XXX 事情上浪费 20 人天”，你就找到了真正的高薪入口。CRUD 的终点不是失业，而是升级——从数据搬运工，变成业务洞察者。这条路没有捷径，但每一步都算数。