前端这个圈子这些年有个很有趣的现象：一到技术转型节点，跳得最欢的往往不是后端，而是天天跟页面打交道的前端。前两篇我们聊了本地大模型部署和对话网页怎么搭，今天这篇我打算换个节奏，从一个真实需求出发，把“前端怎么正儿八经做一个能交给同事用的 AI 应用”这条路完整走一遍。标题里说的“跑路”，不是说真的离开前端，而是把前端技能挪到 AI 应用开发这条新赛道上，把原来会的东西变成新的优势。这篇文章会从需求拆解、技术选型、核心链路实现、知识库落地到问题排查，一步步讲清楚，适合那些前端基础扎实、想往 AI 应用开发方向转，但又被各种算法名词劝退的朋友。
1. 先对齐一下：前端做 AI 应用，到底在做什么
很多前端同学一听“AI 应用开发”，脑子里马上浮现的是神经网络、反向传播、Transformer 结构这些东西，然后直接自我劝退。实际上，我们日常所说的 AI 应用开发，跟训练模型完全是两码事。你可以把成熟的大模型想象成一个能力很强但完全不了解你们公司业务的实习生，AI 应用开发做的，就是给这个实习生配上工作台、资料库、工具链，让他能真正上手干活。这个定位想清楚了，前端在其中的价值就非常明显。
1.1 你不需要训练模型，你只需要用好模型
训练一个属于自己的模型，那是算法工程师和研究团队的工作范畴，投入大、周期长，对绝大多数业务团队来说既不现实也没必要。真正有落地价值的 AI 应用开发，是把已经存在的大模型能力，通过 API 调用、提示词工程、检索增强、工具调用等手段，嵌入到具体的业务场景里去。
拿我自己举例，去年团队里积压了大量项目文档和技术方案，新人入职后翻半天资料也找不到关键信息，我就用本地部署的大模型接了一个简单的问答服务，把资料文档切块存进向量库，做了一个内部知识库问答助手。整个开发过程没有写一行模型训练代码，核心工作量全在数据处理、接口对接和交互体验上，这些东西正是前端最擅长的。
后端同学做 AI 应用，关注点往往是服务稳定性、并发性能、模型推理优化；而前端同学做 AI 应用，最大的优势在于对用户行为的理解和对交互细节的把控。同一个问答助手，后端交付的是能跑的接口，前端交付的是用户真正愿意用的产品。一个 AI 应用到后面，拼的往往是产品体验，而不是模型的参数大小。
1.2 前端这套本事，在 AI 应用里一点没浪费
最近圈子里有“前端岗位从此消失”的说法，我持保留态度。真正发生变化的是岗位内容，不是岗位本身。以前我们写一个管理后台，核心是把表单、表格、弹窗这些组件拼装起来，数据是后端给什么我们就展示什么。到了 AI 应用时代，数据变成了一股流式返回的文本，交互从“点击-跳转”变成了“多轮对话+实时生成”，这要求前端具备更强的编排能力和状态管理能力。
组件化思维在 AI 应用里特别好用。一个对话窗口、一个参数配置面板、一个知识库管理页面，都可以拆成独立组件，复用性很高。我在做问答助手的时候，把“消息列表”“流式文本渲染”“引用来源展示”三个组件拆开，后面接不同业务场景时直接复用，省了大概三分之一的工作量。另外，前端同学普遍对异步编程比较熟悉，Promise、事件循环、回调这些概念在 AI 应用里频繁用到，因为几乎每个交互背后都是一次异步的大模型调用。
还有一点容易被忽视：AI 应用的前端要做大量的状态分支处理。模型在响应过程中会有“连接中”“正在生成”“生成完成”“发生错误”等状态，每个状态对应不同的 UI 展现，这本质上就是一个复杂的前端状态机。用 Vuex 或 Pinia 管理这些状态，简直不要太顺手。
2. 从需求到方案：一个内部知识库问答助手的设计
纸上谈兵没意思，我们直接用一个最常见的场景：内部知识库问答助手。这个需求在几乎每个有一定规模的公司里都存在，而且非常典型——它既包含了大模型调用，又包含了对私有数据的处理，还涉及完整的交互闭环，用来做 AI 应用开发的练手项目再合适不过。
2.1 先花时间把需求拆清楚，别急着写代码
接下这个需求后，我没有直接打开编辑器，而是先拉上提需求的同事聊了半小时。需求方说得很简单：“想做一个能回答公司制度问题的机器人”。但如果只按字面意思做，大概率会做一个没人用的玩具。
我把需求拆成了三层：第一层是用户问了问题，系统能调用大模型给出一个基本合理的回答；第二层是回答必须基于公司给定的资料，不能瞎编，这就引入了检索增强生成（RAG）；第三层是回答要给出参考来源，让用户能顺着答案点回去看原文，这对建立信任感非常关键。三层需求从易到难，每一层都对应明确的用户价值，这样后续的工作量和验收标准就清晰了。
拆完需求后你还会发现，很多细节问题会浮现出来：资料有 PDF、Word、Markdown 各种格式，需要做格式解析；制度文件经常更新，知识库需要支持增量导入和删除；用户提问时一定是口语化的，而资料里的措辞往往是书面化的，中间需要处理语义匹配的问题。这些问题你不提前想，写到一半大概率要返工。
2.2 技术选型：别追求花哨，选自己驾驭得了的方案
技术选型这件事，我一直秉承一个原则：选自己团队最能驾驭的方案，而不是网上讨论度最高的方案。这个项目我用的技术栈非常简单：
前端这块，Vue3 + Element Plus + Vite 是我的老搭档。Vue3 的组合式 API 在管理复杂对话状态时比 Options API 舒服得多，Element Plus 能快速搭出后台管理风格的界面，Vite 的开发体验不用多说，秒级热更新在频繁调试 AI 接口时非常省时间。
后端我选的是 Python FastAPI。可能有人会问，前端为什么不自始至终用 Node.js？原因很简单：Python 在 AI 生态里的统治地位太强了，不管是接各种大模型的 SDK，还是做文本切块、向量化，Python 都是第一公民。遇到问题搜索引擎里随手一查就是答案，这对半路出家的人来说最关键。FastAPI 本身的异步特性和自动生成接口文档的能力，也让它特别适合做 AI 应用的后端。
大模型这部分，我的建议是本地部署和云端 API 并行。开发阶段用 Ollama 跑一个中等规模的模型，比如 qwen 系列，好处是不要钱、没有调用频率限制，调试起来随心所欲；上线阶段根据数据隐私要求和性能要求，再切换到云端 API。本地部署对 GPU 的要求其实没那么恐怖，7B 到 14B 参数规模的量化模型，一张消费级显卡就能跑，大多数公司开发机都能满足。
向量数据库起步阶段用 Chroma 或者 FAISS 这种嵌入式方案就够了。很多人都想一步到位上专业的向量数据库，但实际在数据量小的时候，这些都是过度设计。我这个项目里文档总量不超过几千份，用 Chroma 一个 Python 依赖就搞定了，后面数据量真的大了，再平滑迁移到专门的向量数据库也不迟。
3. 核心链路实现：前端如何把 AI 能力接进来
技术选型定好后，接下来就是最核心的部分：前端到底怎么把 AI 能力接进来，而且要接得流畅、接得自然。这一步里，流式输出是绝对绕不开的坎。如果不用流式，用户提问后要傻等好几秒甚至几十秒，体验极其糟糕。用上流式输出后，字是一个个蹦出来的，用户第一眼反馈很快，体感时长直接缩短一大截。
3.1 先想清楚后端需要给前端提供什么
前端开发的第一步，往往是跟后端对齐接口格式。在这个项目里，我的后端只需要提供三个核心接口：
第一个是POST /api/chat，负责接收用户的提问和上下文，返回大模型的流式响应；第二个是POST /api/upload，负责接收上传的文档，做解析、切块、向量化并存入知识库；第三个是GET /api/query，负责给定一个问题，召回相关的文档片段。这三个接口一确定，前后端就可以完全并行开发，前端甚至可以先用 Mock 数据把界面写好。
关于响应格式，我强烈建议用 SSE（Server-Sent Events）而不是轮询或者 WebSocket。SSE 和 HTTP 同源，实现简单，断线自动重连，对大模型这种单方向持续输出的场景是天然匹配的。前端只需要用EventSource或者fetch的流式读取能力就能消费，不需要额外引入复杂的客户端库。
下面是我在后端用 FastAPI 实现的一个极简 SSE 流式接口示例，核心逻辑就是通过yield不断输出文本片段：
from fastapi import FastAPI from fastapi.responses import StreamingResponse import json app = FastAPI() def fake_llm_stream(prompt: str): # 实际场景这里会调用大模型，逐句返回结果 response_text = "你好，我是企业内部知识助手。" for char in response_text: yield char time.sleep(0.05) @app.post("/api/chat") async def chat(request: dict): prompt = request.get("prompt", "") def event_stream(): for chunk in fake_llm_stream(prompt): # SSE 格式要求每条数据以 data: 开头 yield f"data: {json.dumps({'content': chunk}, ensure_ascii=False)}\n\n" return StreamingResponse(event_stream(), media_type="text/event-stream")后端逻辑非常直白：把大模型返回的内容逐片拆出来，包上 SSE 格式返回。前端的核心任务就是逐段解析并渲染。
3.2 流式输出的前端写法
前端这边，我推荐用fetch而不是EventSource。原因有两个：一是EventSource只能发送 GET 请求，而我们要传递用户提问内容，POST 更合适；二是fetch配合ReadableStream可以拿到更底层的控制权，不管是处理错误还是中途停止都更方便。
核心代码长这样：
async function streamChat(prompt, onMessage, onDone, onError) { const resp = await fetch('/api/chat', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ prompt }), }); if (!resp.ok) { onError(resp.statusText); return; } const reader = resp.body.getReader(); const decoder = new TextDecoder('utf-8'); let buffer = ''; while (true) { const { done, value } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); // SSE 数据以空行分隔，这里按空行拆分 const events = buffer.split('\n\n'); buffer = events.pop() || ''; for (const event of events) { const line = event.trim(); if (!line.startsWith('data:')) continue; const payload = line.slice(5).trim(); try { const data = JSON.parse(payload); onMessage(data.content); } catch (e) { console.warn('解析失败', e); } } } onDone(); }这段代码的核心技巧在于用buffer缓存半截数据。因为网络传输是按数据块（chunk）到达的，一个完整的 SSE 事件可能被拆成两次传过来，如果直接按次解析就会漏数据。我在这里用空行作为分隔符，先把每次收到的数据追加到缓冲区，再按完整事件拆分，剩下半截暂时留在缓冲区，等下一次数据到达时再拼接，这样就不会有事件被切开了。
这个坑是实际开发中遇到的第一个大坑，当时线上偶发性地出现答案末尾缺几个字，排查了半天才发现是 SSD 传输中断导致的事件被截断。
3.3 长文本渲染与响应展示
拿到流式文本后，前端要面临一个几乎必然遇到的问题：模型输出的不是纯文本，而是包含 Markdown 格式标记的内容。大模型的回答里经常会包含代码块、列表、表格，如果直接用<div>{{ content }}</div>插值，用户看到的就是一坨带着#和*符号的原始文本，体验很差。
我的处理方案是引入一个支持流式的 Markdown 渲染库，比如marked配合highlight.js做代码高亮。这里有一个很重要的细节：流式场景下，Markdown 文本是不完整的，一段以##开头的标题，在第二个#还没到达之前，如果已经做了一次渲染，页面就会出现一瞬间的闪烁。我的解决办法是做一个简单的节流机制：每 50 到 100 毫秒才触发一次重新渲染，而不是每个字符都渲染一遍，同时在渲染前检查文本是否以 Markdown 的未闭合标记结尾，如果是就暂时不渲染这个标记，这样能显著减少闪烁感。
另外，生成过程中的 UI 状态管理也要处理好。我在 Pinia 里定义了一个会话状态机，包含idle、streaming、completed、error四个状态。用户点击发送按钮后进入streaming状态，这时输入框要禁用，停止按钮要显示，消息气泡下方可以放一个打字指示器；生成完成后回到idle状态，同时渲染“复制答案”“重新生成”这两个操作按钮。“重新生成”这个功能特别推荐加上，因为大模型本身有随机性，同一个问题多抽几次，总有一次能给到满意答案，这个操作的实现也简单，把最后一条用户消息重新发送一遍就行。
流式输出期间如果用户想终止生成，不能简单粗暴地断开连接，因为后端可能已经把整段内容都处理完了。正确做法是调用AbortController的abort方法中止前端的读取循环，同时向后端发送一个取消请求。这样既保住了已经收到的内容，也不会让后端继续空转消耗资源。
4. 知识库落地的关键：文本切块与检索增强
前面说的问答助手，如果只是把用户问题直接丢给大模型，那它就是个没有灵魂的接口搬运工，回答的质量完全取决于大模型本身训练时见过多少资料。想让模型准确回答公司内部问题，必须把知识库检索（RAG）接进来。RAG 的原理非常简单：用户提问后，先从我们的资料库里找出跟问题最相关的几段文本，把这几段文本和问题一起塞给大模型，让它“参考这些资料回答”。
4.1 为什么前端也得关注 RAG
很多前端同学觉得自己又不写算法，RAG 跟自己没关系。但实际在 AI 应用开发里，RAG 的效果直接决定了产品能不能用，而这个效果跟工程实现的关系，比跟算法模型的关系大得多。你用什么策略去切文本、用哪个向量模型做编码、检索时怎么排序打分，这些全都是工程决策，不是说用了某个“标准方案“就万事大吉。
更关键的一点是，RAG 链路中的大部分工作，本质上跟写业务接口没什么区别——读取文档、调用编码接口、写入数据库、查询数据，这些都不涉及微积分和矩阵论。就好比你在业务系统里写一个订单查询接口，公司订单表需要做分库分表，你不需要自己研究分布式系统理论，只需要掌握方案和实践经验。
前端的结构化思维在 RAG 链路里也很重要。文档解析后应该存成怎样的数据结构？切块后的文本和元信息如何关联？检索结果按什么字段返回给前端展示？这些问题前端处理起来天然有优势。
4.2 最小可行的向量化与检索方案
我用的方案分四步：文档解析、文本切块、向量化存入向量库、检索时做相似度匹配。
文档解析这步，不同的文档格式有不同的处理库。PDF 用pypdf，Word 用python-docx，Markdown 和纯文本直接读取，再把解析出来的内容统一转成纯文本。这一步的坑主要在 PDF 上，很多扫描版 PDF 其实是一张图片，直接解析出来是空文本，这种情况我用 OCR 接口去识别，但那是另外一套流程了，初期可以先把这一部分排除掉。
文本切块是整个 RAG 链路里最影响效果的环节。切得太粗，一块文本里包含多个主题，检索时召回的内容不精准；切得太细，一个完整的逻辑被拆成好几段，模型理解不了上下文。我实测下来，按固定字符数切分，块大小取 500 左右、重叠取 100 左右，综合效果最好。具体实现很简单：
def split_text(text, chunk_size=500, overlap=100): if len(text) <= chunk_size: return [text] chunks = [] start = 0 while start < len(text): end = start + chunk_size chunks.append(text[start:end]) if end >= len(text): break start = end - overlap return chunks切块完成后，把每一块文本送给 embedding 模型做向量化，得到一组几百维的浮点数数组，连同原文一起存入向量库。检索的时候，把用户问题也做同样的向量化，然后计算问题向量和库里所有文本向量的余弦相似度，取 top_k 个最相似的片段。这个匹配过程在数据量小的时候用暴力计算就行，几千条数据的计算量完全在可接受范围内。
最后一步是把检索到的片段拼进 Prompt，示意结构是这样的：
请根据以下参考资料回答用户问题。 如果参考资料中没有相关信息，请如实说明“资料库中未找到相关内容”。 参考资料： 1. [xxx 文档]：公司年假政策…… 2. [xxx 文档]：员工离职流程…… 用户问题：入职满一年后年假有几天？在 Prompt 里明确告诉模型“不知道就直说”，这一步太重要了，能避免大模型一本正经地胡说八道。引用来源的展示，本质上是把你给模型的那几个知识片段原封不动地渲染出来，用户点了能跳转到原文位置。
4.3 中文内容的切块细节与调优经验
切块的参数不能死记硬背，必须拿自己的数据做测试。但中文内容有几个细节是通用的，值得单独拿出来说。
第一，尽量优先在段落边界处切块，也就是遇到换行符优先切，而不是单纯数到 500 个字符就硬切。同一段文字硬被拆到两块里，检索时会丢失语境信息。我的做法是先按段落把文本分组，再尝试把多个段落拼成一个 500 字左右的块，这样每块内容在语义上更完整。
第二，大标题和小标题尽量单独保留。很多文档，一个章节的小标题后面跟着好几段正文，如果把标题混在正文里，检索时向量化会把标题语义稀释掉。更好的做法是切块时把最近的标题拼接在当前块的开头，比如“【员工考勤管理制度】迟到早退的认定标准……”，这样模型在回答时能更好地理解上下文出处。
第三，embedding 模型的选型直接影响检索效果。中英文混合场景下，bge-m3 这类中文优化过的模型效果明显好于通用的多语言模型。另外，同一个项目里，文档入库和线上检索必须使用同一个 embedding 模型，否则向量空间不一致，检索结果完全不可用。这个坑我踩过一次，当时切换模型后忘了更新之前的向量，导致检索结果驴唇不对马嘴，排查了半天才定位到问题。
5. 常见问题与排查实录
AI 应用开发跟传统前端开发有一个明显的区别：传统的接口调用，返回结果是确定的，出了问题查一下网络请求基本就能定位；而 AI 应用的返回结果带有很大的不确定性，有时候同一段代码，这次调用成功，下次调用就报错，甚至这次和下次生成的内容都会差很多。这种不确定性让很多人排查问题查到怀疑人生。这节我把自己反复踩过的几个坑分享出来，希望能给你省点时间。
5.1 CORS 跨域问题：前端开发的第一道坎
本地开发的时候，前端跑在 Vite 的 5173 端口，后端跑在 FastAPI 的 8000 端口，两个服务一分开，浏览器的同源策略马上就会拦你。这时候你有两个选择：后端加 CORS 头，或者前端配代理。
后端的解决方案是给 FastAPI 加上 CORSMiddleware，把前端的地址加进允许列表。但这个方案有个隐患：一旦配置了allow_origins=["*"]，等于让所有网站都能调你的接口，本地调试没问题，上了生产环境就是安全隐患。如果部署到公网，建议把允许的来源限定成你自己的域名。
前端的解决方案是在 Vite 配置文件里加代理，把/api开头的请求全部转发到后端地址。这个方案我的体感更好，因为开发环境和生产环境可以用同一套相对路径/api/xxx，不需要在前端代码里区分环境变量，部署时再用 Nginx 转发一次就行。配置如下：
// vite.config.js export default { server: { proxy: { '/api': { target: 'http://localhost:8000', changeOrigin: true, } } } }5.2 中文乱码与编码问题
AI 应用里中文是绝对的主角，但中文编码问题会在意想不到的地方冒出来。最常见的是 SSE 流式响应中的中文内容，前端用TextDecoder解码时一定要带上'utf-8'参数，而且要用{ stream: true }模式，否则多字节的中文字符可能恰好在数据块边界处被截断，解码出来就是乱码。
后端也有一个隐蔽的坑：FastAPI 在返回 JSON 时默认会做 Unicode 转义，ensure_ascii默认是True，导致返回的 JSON 里中文全变成\uXXXX格式。虽然前端JSON.parse能正常解析回来，但在浏览器 Network 面板里看不到任何可读的中文，排查问题时会特别痛苦。我习惯在后端统一设置JSONResponse的ensure_ascii=False，或者像第一节代码里那样，在json.dumps时带上ensure_ascii=False。
5.3 上下文太长与请求超时
大模型的输入长度是有上限的，比如有些模型支持 8K 上下文，有些支持 32K。当对话轮数多了，或者文本块太长，把历史消息全部塞进上下文，很容易超出限制，表现就是接口直接报 400 错误。
这个问题有几种处理思路。最简单的是超了就直接报错，然后把对话清空重新开始，但这个方案体验太差。好一点的方案是做消息压缩：当历史消息超过一定长度后，把最早的几条消息做摘要，用摘要替换原文，或者直接丢弃最早的消息，只保留最近的几轮。这个方案我现在还在用，实现成本不高，只是要注意摘要会丢失一些细节。
还有一种情况需要专门处理：前端请求超时。本地部署的模型生成速度本来就慢，如果模型比较大，一个长答案可能要生成一两分钟，而很多 HTTP 客户端和服务端的默认超时时间是 60 秒。我的建议是，前端把请求超时时间调到一个比较宽裕的值，比如 120 秒，同时实现一个心跳机制，也就是每收到一个数据块就重置超时计时器，确保长时间生成过程中连接不会被误杀。
5.4 本地模型与云端 API 的差异
开发阶段我强烈建议用本地模型，但在最后上线之前，一定要用云端 API 做一轮完整的回归测试。本地模型和云端 API 的差异，比赛犬和家犬的差距还大，不管是从响应速度、回答质量还是可用性上说。
本地模型首字延迟普遍偏高，因为模型推理需要先把整个模型加载到显存里。如果用 CPU 跑，慢得简直难以忍受。云端 API 在这方面做了很多优化，首字延迟通常能控制在 1 秒左右。但云端 API 也不是没有坑，它的限流策略、并发控制、内容安全审查，都会在某个意想不到的时候给你添堵。线上环境一定要做失败重试和降级策略，比如用一个轻量本地模型作为兜底，云端 API 不可用的时候自动切换过去。
质量差异方面，同一个问题，云端的大模型回答得通常更有条理，本地的小参数模型则会时不时冒出一些常识性错误。最好的策略是开发时本地调逻辑，上线前线上跑真模型，两边的差异心里有数，上线后才不会慌。
6. 再往前一步：从对话助手到 Agent
如果你的问答助手已经稳定跑起来了，恭喜你完成了 AI 应用开发的第一阶段。下一步自然要考虑的是：如何让助手不只是“回答问题”，而是能“做事情”，这就进入了 Agent 的范畴。Agent 这个词最近被炒得很热，但剥开外壳看核心，无非就是三件事：调用工具、管理记忆、自主规划。
6.1 工具调用：让模型不只是会说，还能“做”
工具调用（Function Calling）是 Agent 能力的关键，它让大模型不再局限于生成文本，而是可以在生成过程中触发一些预设的外部操作。最经典的例子是：用户问“帮我查一下昨天订单的退款进度”，大模型识别出这是一个查询动作后，会调用一个query_refund_status(order_id)的函数，拿到结果后再把结果组织成自然语言回复用户。
工程上的实现方式其实很简单。后端定义好一串函数描述（包括函数名、参数含义、返回结构），在调用大模型时把函数描述一起传过去，让模型决定要不要调用、参数填什么。模型返回的结果分为两种情况：如果是普通文本，直接推给前端展示；如果是一个函数调用指令，后端就执行这个函数，把执行结果回传给模型，让模型基于结果再生成最终回复。这个“模型决策—函数执行—结果回收”的循环，就是 Agent 的基本运行逻辑。
从前端视角来看，工具调用的交互设计特别有发挥空间。比如模型调用了一个查询函数，前端可以在等待结果时展示一个 Loading 状态或者一个小的操作日志面板，把“正在查询部门考勤数据…”这样的过程展示给用户，让用户感觉Agent真的在干活，而不是卡住了。这种过程透明的设计，对用户信任感的建立帮助非常大。
6.2 多轮记忆与上下文管理的进阶玩法
Agent 的记忆管理是一个很让前端头疼的问题。每一轮对话都包含用户提问、模型回复、工具调用结果这几类信息，如果全部留存在上下文中，Token 消耗和上下文长度会迅速膨胀。我的经验是给消息打上标签，分清哪些是用户消息、模型消息、工具消息、系统消息，在组织上下文时按标签分类添加。工具调用结果一般留最新一轮的就够了，历史会话的详细内容不必每次都传给模型。
更进阶一点的做法是做一个独立的总结线程。对话进行一定轮数后，启动一个小模型，把目前为止的对话要点总结成 100 字左右的摘要，替代之前全部的对话历史。这是一个典型的用空间换时间、用计算换带宽的策略，实测对长会话的稳定性提升非常明显。
到了这个阶段你会发现，所谓 Agent 开发，底层依然是前端工程思维——消息路由、状态管理、异常捕获、生命周期管理，只是数据来源从“数据库”换成了“大模型 + 工具返回结果”。之前做前端积累的架构能力，在这里不是没用，反而是最稀缺的竞争力。
我做 AI 应用开发这段时间，最大的感受倒不是技术上的，而是心态上的。很多前端同事聊起 AI 都会说“这东西太深了，我等会儿再看看”，然后就没有然后了。但事实上，把 AI 能力接进产品，跟当年把地图 SDK 接进 H5 页面没有本质区别——都是调用一个黑盒能力，把返回结果做成好用的用户界面。你不需要读懂 Transformer 论文才能写 AI 应用，你只需要把一个最小的闭环跑通，然后把体验打磨到别人愿意天天用。先跑通再优化，这是我自己一直信奉的开发法则，同时也是前端这个职业在 AI 浪潮里不会掉队的底气所在。
