1. 前端开发者学 AI，到底该学什么

最近不少做前端的同行问我同一个问题：AI 这么火，我是不是得转行去做算法？还是赶紧去学 Python 和搞模型训练？

我的回答一直是：不需要，也不建议。前端开发者学 AI，跟算法工程师学 AI，完全是两条不同的路。算法工程师关心的是 loss 怎么降、模型怎么收敛，而前端关心的是怎么把模型能力变成用户能感知的功能——聊天框里的流式回复、上传图片后的识别结果、长文档的智能总结，这些东西的最后一公里都在前端手里。

所以这个问题的核心答案其实很清楚：前端学 AI，学的不是怎么训练模型，而是怎么“用”模型。你要掌握的是 API 怎么调、数据怎么传、流式响应怎么解析、对话上下文怎么管理、AI 功能怎么嵌入现有业务，以及在什么场景下选什么模型。这就像你不需要会造发动机，但你要知道怎么把发动机装进车里，并且让司机开得顺手。

那具体需要学哪些东西？我按自己从传统前端转过来的实际经历，把路线拆成六个模块：AI 基础知识、模型 API 调用、Prompt 工程、RAG 应用开发、AI 前端架构设计、AI 辅助开发工具链。下面逐个说清楚。

2. AI 基础知识：不是让你去推公式，但也不能完全不懂

2.1 模型是怎么工作的，用前端的语言解释

你不需要能推导 Transformer 的数学公式，但你必须理解几个最基础的概念，否则跟后端沟通、跟算法同学对接需求的时候，你连“Token”“上下文窗口”“温度”这些词都听不懂，会非常被动。

我用前端的角度来看这几个概念：大语言模型本质上是一个“超级文本预测器”。你给它一段文字，它根据这段文字预测下一个最可能出现的词，再预测下一个，循环往复，就生成了一整段话。这个过程跟你在编辑器里按 Tab 键自动补全代码很像，只不过它的输入范围更大、预测能力更强。

Token 是模型处理文本的基本单位，一个 Token 大概是一个英文单词的一部分或一个中文字符的一部分。这直接关系到两件事：一是计费，大多数 API 按 Token 计费；二是上下文窗口，模型一次性能处理的 Token 数量是有限的。GPT-4o 的上下文窗口大概在 128K Token，Claude 的 Sonnet 和 Opus 系列能做到 200K Token。 写代码的时候，你就要预估一段长文本会消耗多少 Token，比如把一本 300 页的书塞进上下文，大约要消耗 25 万个 Token，这已经超过大多数模型的窗口上限，得做切分。

温度（Temperature）是一个 0 到 2 之间的参数，控制输出的随机性。温度越高，回答越发散；温度越低，回答越稳定。做分类提取这类任务，温度建议调到 0 到 0.3，做创意文案可以调到 0.7 以上。前端的场景里，生成 UI 代码、做代码解释，温度设 0.1 就行，不然它每次给出来的代码结构都不一样，没法稳定落地。

2.2 需要补一点 Python 吗

很多前端一听到 AI 就以为必须学 Python。实际是我的建议是：前端不需要系统学 Python，但最好能看懂基础语法。

原因很直接：你在实际开发中用到的 AI 能力，绝大多数是通过 HTTP API 调用的，JavaScript 是完整的语言支持。真正需要 Python 的场景，是你要自己跑一些开源模型的推理脚本、做数据处理，或者要用到 LangChain 这类偏后端的框架做原型验证。这些场景你只要能看懂脚本里的逻辑，能改参数、能跑起来就够了，不用达到能写项目的程度。

我自己的经验是花了两个晚上过了一遍 Python 的基础语法，重点是列表推导式、字典操作、requests 库发请求这老三样。后面遇到需要调用模型做批量测试的脚本，我都是直接让 AI 帮我写，我能看懂它在干什么、知道怎么改就行。对前端来说，这才是效率最高的学习方式。

2.3 数学要补到什么程度

不需要。除非你打算转岗做算法，否则线性代数、概率论、微积分这些你都可以不碰。你只需要理解两个跟数学沾边的概念就行——

第一，向量和向量相似度。向量就是把一段文本转换成一串数字，这串数字代表这个文本在语义空间中的位置。两个文本越相似，它们在语义空间里的距离就越近。这个概念在 RAG 里特别重要，后面会展开讲。

第二，嵌入（Embedding）。你可以理解成模型给每个词或每段话算出一个“语义坐标”，比如“苹果”和“香蕉”的坐标距离很近，“苹果”和“汽车”的距离就很远。前端要做的，就是调用嵌入接口拿到这个坐标，然后做相似度计算。

就这么多。其他数学知识什么时候用到什么时候再查，完全不影响你开展工作。

3. 模型 API 调用：前端接入 AI 的基础功

3.1 主流模型的 API 结构长什么样

现在主流的模型 API 基本上都是 OpenAI 兼容格式。你只要会调一家，其他家的文档扫一眼就能上手。一个最基础的对话接口长这样：

const response = await fetch('https://api.example.com/v1/chat/completions', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': 'Bearer YOUR_API_KEY' }, body: JSON.stringify({ model: 'model-name', messages: [ { role: 'system', content: '你是一个前端开发助手，回答要简洁、准确。' }, { role: 'user', content: '请介绍一下 React 的 useMemo 和 useCallback 的区别。' } ], temperature: 0.3 }) }); const data = await response.json(); console.log(data.choices[0].message.content);

这里有几个关键点，前端必须重视。

第一个是 messages 数组的结构。这里面分 system（系统指令，设定模型角色和行为规则）、user（用户输入）、assistant（模型的历史回复）。多轮对话就是把历史消息都放进这个数组里发给模型。前端每次请求都要把之前的所有对话记录重新发一遍，因为模型本身没有“记忆”，所谓记忆是靠你把历史信息塞进上下文实现的。

第二个是流式输出。生产环境里，你不可能让用户等模型把整段话生成完再展示。用户需要的是打字机一样逐字蹦出来的效果。这时候就要用流式模式，把 stream 参数设为 true，然后用前端的方法解析流式数据。具体做法是：

const response = await fetch(url, { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': 'Bearer sk-xxx' }, body: JSON.stringify({ model: 'model-name', stream: true, messages: [{ role: 'user', content: '写一首诗' }] }) }); const reader = response.body.getReader(); const decoder = new TextDecoder(); while (true) { const { done, value } = await reader.read(); if (done) break; const chunk = decoder.decode(value, { stream: true }); // 解析 SSE 格式的数据 const lines = chunk.split('\n'); for (const line of lines) { if (line.startsWith('data: ') && line !== 'data: [DONE]') { const json = JSON.parse(line.slice(6)); const delta = json.choices[0].delta?.content; if (delta) { // 把 delta 追加到界面上的文本节点里 updateUI(delta); } } } }

流式响应的数据格式叫 SSE（Server-Sent Events），服务端会持续推送以data:开头的文本块。你要处理的是分块解析、编码解码和缓冲区对不齐的问题。实测下来，中文文本用 UTF-8 解码时，一个汉字可能被拆成两个 chunk，所以必须用TextDecoder并设置stream: true，否则经常出现乱码。

第三个是 API Key 安全。这里必须郑重提醒：API Key 绝不能暴露在前端代码里。你写在前端 bundle 里的任何字符串，用户都能在浏览器开发者工具里找到。正确做法是走你自己的后端代理，前端把请求发给后端，后端在服务端调用模型 API，再转发回前端。如果只是做个本地开发的 Demo，可以临时写在本地配置文件里，但不要推到线上。

3.2 前端接入 AI 的架构模式

我自己在实际项目中，总结出三种前端接入 AI 的架构模式，你可以按需选：

一是纯组件模式。把 AI 能力封装成一个前端组件，比如一个内置了提示词逻辑、流式渲染、状态管理的聊天组件。适合快速搭建 AI 功能原型，业务方只需要拿来即用。缺点是不够灵活，复杂的定制需求会比较难满足。

二是 API 代理模式。前端调用自己的后端接口，后端统一管理模型 API 的调用、密钥、限流和缓存。这是生产环境最推荐的模式，安全和可控性兼顾。缺点是前后端需要约定好接口文档，多一层联调成本。

三是 Edge Function 模式。用边缘函数来代理模型请求，可以同时解决跨域、密钥保护和地区延迟的问题。适合有全球用户的产品，但部署和调试的复杂度会高一些。

前端开发者一定要养成一个习惯：把 AI 调用封装成一层独立的 Service，不要散落在各个页面里。我见过一个项目，六个页面各自直接调 API，后来要统一加日志上报和错误处理，改了一个通宵。

3.3 多模型协作的架构思路

最近的热搜词里出现了“多 AI 协作”，这个方向在实际项目中越来越常见。核心思路是把不同模型用在不同的环节，比如用速度快、成本低的模型做意图识别和分类，用强推理模型做复杂问题解答，用多模态模型做图片理解，然后在架构层做一个路由器，根据用户请求的类型自动选择最合适的模型。

前端的职责是设计统一的调用接口，不暴露底层模型切换的逻辑。也就是说，页面层调aiService.chat()，至于内部是用 GPT-4o、Claude 还是国产模型，由配置中心决定。这样可以灵活应对模型价格波动和能力变化，不会因为换一个模型就得重写整个前端。

4. Prompt 工程：前端最应该掌握的能力

4.1 为什么 Prompt 是前端的主场

Prompt 工程是前端最容易上手且产出最明显的一项能力。为什么？因为其他能力都需要跟后端、算法配合，而 Prompt 你自己就能写。前端项目里的 AI 功能，大部分是为了解决用户交互问题：帮用户生成文案、总结内容、提取信息，这些都需要设计高质量的提示词。

我给你举一个最典型的场景：你在开发一个 AI 文档助手，用户上传一篇长文，要求总结要点。如果你只是简单地说“帮我总结这篇文章”，模型输出的结构、详略、风格完全不可控。但如果你写的是：

你是一名专业的文档分析助手。请阅读以下文档内容，并按照以下要求输出总结： 1. 先用一句话概括文档的核心主题 2. 然后分点列出主要观点，每点不超过50字 3. 最后列出文档中提到的重要数据 要求：语言简洁、客观中立、不添加文档之外的信息。 文档内容：{{这里插入文本}}

这样输出的结果就稳定得多，而且便于前端做结构化展示，比如把三个部分分别渲染成摘要卡片、要点列表和数据表格。这就直接体现了前端做 Prompt 工程的价值。

4.2 Prompt 的核心结构

我写过上百条 Prompt 之后，总结出一个实用的公式：角色 + 任务 + 上下文 + 格式约束 + 禁止项。

角色是“你是什么人”，任务是你需要它做什么，上下文是它需要用到的信息，格式约束是输出应该长什么样，禁止项是你明确不希望它做的。你给我试一下，把前面那个文档助手的 Prompt 套进去，角色、任务、上下文、格式约束、禁止项全都齐了。

有几个常见的坑值得提醒。第一，Prompt 不是越长越好，但关键信息不能省。上下文信息必须给足，否则模型只能靠猜。第二，要给示例。模型对格式的理解能力，很大程度上取决于你有没有给它一个样例。你希望它输出什么样的结构，就直接给它一段你想要的输出样例。第三，中文场景下明确说明“用中文回答”，不然它可能因为某个上下文片段自带英文而切到英文输出。第四，禁止项很重要。很多模型默认倾向“脑补”和“挖续”，你必须加一句“不要添加文档之外的信息”，否则它给你谎报数据，用户会投诉。

4.3 用 Prompt 驱动前端 UI 生成

最近热议的“Claude Code 前端开发插件”也好，“AI 生成 UI”也好，底层核心就是模型对代码和金手指标记的理解能力。作为前端，你要掌握的就是怎么用 Prompt 让它生成符合你项目规范的前端代码。

我常用的方式是在项目根目录放一个AGENTS.md或.cursorrules文件，里面写明项目使用的框架版本、样式方案、组件库、编码规范、目录结构。这样在 AI 编码工具里，每次生成代码时它都会自动读取这些约束，输出就不会跑偏。比如我的一个 Vue 项目里就写着：

# 项目规范 - 框架：Vue 3 + TypeScript - UI 组件库：Element Plus - 样式方案：SCSS，使用 BEM 命名规范 - 组件文件结构：template 放在 script 前面 - 禁止使用 any 类型 - 通用请求统一走 src/utils/request.ts，不允许直接使用 axios

有了这份文件，AI 生成的代码风格跟团队代码基本一致，你只需要改改业务逻辑就行。反过来，没有规范文件，它给的代码就是八仙过海各显神通，拿来还要大改。这是我很想分享的一个重要经验。

5. RAG 应用开发：让 AI 用上你自己的数据

5.1 什么是 RAG，前端为什么要了解

RAG 全称是 Retrieval-Augmented Generation，检索增强生成。它的核心思路是：模型本身的知识库是有截止日期的，而且不包含你公司的私有数据。你把相关文档先存到向量数据库里，当用户提问时，先在向量库里找到跟问题最相关的几个片段，把这些片段连同问题一起发给模型，让模型基于这些片段来回答。

前端开发者在 RAG 里主动参与的机会很多。一是知识库管理界面，你要开发上传、切分、预览、检索测试的页面。二是问答交互界面，你要设计流式问答的输入输出，处理相关文档的展示，让用户看得到答案是引用了哪些资料。三是状态管理，索引构建的进度、检索的置信度、对话的历史，这些都需要前端做良好的展示。

理解 RAG 的原理对前端很有用。它的流程概括为：文档加载、文本切分、向量化、存储、检索、生成，六个环节。前端能直接感知的是检索环节，也就是你搜一个问题，系统要能在几百个文档片段中快速找出最相关的几个。这个“相关”就是用文本向量的相似度来衡量的。你需要把用户的问题也向量化，然后在向量数据库里做相似度检索。

5.2 前端在 RAG 项目里实际要做的

我参与过一个企业知识库问答项目，前端承担的工作归纳下来有这几个模块：

文档管理页面是用户上传 PDF、Word、Markdown，上传后触发后端异步处理，前端要有进度反馈和失败重试机制。我实现的时候用 Web Worker 处理文件解析和切片，避免阻塞主线程导致页面卡死。

检索测试页面是提供给管理员的一个调试工具。输入一个问题，展示系统召回的相关片段和相似度分数，方便排查“为什么这个问题答得不好”。这个页面对于运营调优特别有价值。

问答交互页面就是核心功能了。用户提问、展示流式回答、展示引用的文档片段。引用片段的展示是关键体验：回答里如果把某句话链到第 3 个文档片段，那么点击这句话应该能定位到原始文档的位置。

这里有一个前端必须注意的技术点：长文档的切片展示。文档切片之后把原始内容保存到数据库，前端拿到的只是一段一段的文本，要把这些片段拼接回一个可阅读的文档视图，同时还要支持高亮定位。我当时的方案是使用虚拟滚动来渲染长篇文档，点击引用跳转时计算目标片段在整体文档中的位置，然后滚动到对应区域并加上高亮动画。

5.3 文本切分和向量检索的基础原理

RAG 有一个典型现象：切分长度决定回答质量。你切得太短，语义不完整，模型理解不了上下文；切得太长，干扰信息增多，检索精度下降。实践经验是：中文文档按 200 到 500 字切一段比较合适，相邻切块保留 20 到 50 字的重叠，防止关键句子被从中间切断。

向量检索的原理可以类比成一个“语义定位系统”。每一段文本都被模型转换为高维空间中的一个点，用户的查询文本也被转换为一个点，系统计算这两个点之间的距离，距离越近语义越相近。前端的实际工作也包含把相似度分数可视化展示出来，比如做一个进度条或者雷达图，让运营人员直观地看到召回结果的质量。

6. 前端 AI 实战：从聊天框到复杂 AI 应用

6.1 搭建一个基本的 AI 对话组件

写一个简洁但完整的 AI 对话组件，是前端学 AI 最好的入门项目。它看似基础，但涉及了前端 AI 集成的所有核心要素：状态管理、流式请求、安全代理、错误处理。我提供一个基础版的思路：

整个组件需要管理的状态有：消息列表、当前接收中的临时消息、是否正在生成中、模型名称和参数设置。组件需要实时渲染流式输出的内容。这里我用的是一个中间态消息对象，它的 content 随流式数据不断追加，直到流结束才把它正式推入消息列表。

组件的外层还需要防抖处理。用户高频点击发送时，要防止在模型还没返回完就再次发起请求，可以把请求状态作为一个锁。实测中，如果不做锁机制，用户在模型输出期间连续发送消息，会出现响应错乱、消息顺序颠倒的严重问题。

组件还需要滚动管理。流式输出时，内容会不断变长，你要保证界面始终显示最新内容，但又得允许用户上翻看历史。实现方式是监听 scroll 事件，当用户接近底部时自动跟随滚动，否则不打扰。

6.2 输入车牌前端页面：一个具体的企业级 AI 识别需求

热搜词里有一条“输入车牌前端页面”，实际上这是 AI 图像识别在前端的一个很典型场景。停车场、物流园区、工地出入口，经常需要前端页面实现“输入车牌 + 拍照识别”的组合功能。

这里的技术核心是 OCR 识别与前端 UI 的结合。用户拍一张车辆照片，前端把图片传给后端或直接调用多模态模型 API，让模型返回车牌号，然后把识别结果自动填入输入框，用户确认后提交。这套流程比传统的手动输入体验好得多。

前端要实现的关键点：图片压缩，因为手机拍的照片动不动就五六兆，直接上传很慢。用 Canvas 做压缩，把图片控制在 1MB 以内，识别率不受影响。然后是识别结果的处理，多模态模型返回的可能是带了空格或特殊字符的字符串，要做一个格式化函数，清理异常字符，比如去除-、空格，统一大写。最后是防抖校验，车牌输入框要做实时合法性校验，但接口调用要加 300ms 到 500ms 的防抖，防止每敲一个键就发一次请求。

6.3 流式输出和大文件上传的优化

热词里有两个技术点值得详细拆解，一个是前端流式输出的细节优化，另一个是前端使用 Worker 上传大文件。

先说流式输出。基础做法是解析 SSE 然后逐字追加到 DOM。但简单地把每个字都插入 innerHTML 是性能灾难。实测在长文本输出时，浏览器会卡顿甚至白屏，因为每个字都触发一次重排。更科学的做法是使用 requestAnimationFrame 做批量渲染，每帧只更新一次 DOM，把这期间收到的所有增量合并成一次追加。优化后即在 30 到 60 帧的刷新率下，界面依然流畅。

大文件上传配合 Worker 是我强烈推荐的做法。AI 应用里经常涉及上传视频、长音频、高分辨率图片。如果用主线程做分片读取和加密，页面会卡死。使用 Worker 把文件切片、计算哈希、控制并发上传全部放到后台线程，主线程只负责显示进度条和接受完成回调。

Worker 上传的核心代码思路：

// main.js const worker = new Worker('./upload-worker.js'); worker.postMessage({ type: 'upload', file, chunkSize: 5 * 1024 * 1024 }); worker.onmessage = (e) => { if (e.data.type === 'progress') { updateProgressBar(e.data.percent); } }; // upload-worker.js self.onmessage = async (e) => { const { file, chunkSize } = e.data; const chunks = []; let offset = 0; while (offset < file.size) { const chunk = file.slice(offset, offset + chunkSize); // 这里将切片内容 hash 后组织为 FormData 分片上传 chunks.push(chunk); offset += chunkSize; self.postMessage({ type: 'progress', percent: Math.round(offset / file.size * 100) }); } // 所有切片上传完成后，调用合并接口 };

实际做的时候有几个坑：一是切片大小要权衡，太大会导致单次上传耗时过长，太小会产生大量请求。5MB 到 10MB 是实验下来比较合理的区间。二是断点续传要用文件指纹（Hash）来标识文件，后端才能判断哪些切片已经上传过。三是并发数量控制，实测并发 3 到 5 个请求是比较稳定的区间，并发太高反而会因为带宽争抢导致整体速度下降。

6.4 前端数字孪生网站的 AI 结合点

“前端数字孪生网站”是最近挺火的热词，它和 AI 的结合点也很有价值。数字孪生指的是通过数字模型实时映射物理世界，比如智慧园区、设备监控、城市管理。前端需要用到 Three.js、WebGL 或 GIS 相关技术。

AI 在这个场景里能干几件事：一是语义化交互，用户用自然语言查“昨天 3 号车间最高温度是多少”，AI 把这句话翻译成对前端数据模型的查询，然后高亮对应的设备、显示查询结果。二是 AI 驱动的设备状态诊断，把设备实时数据喂给大模型，让它给出异常原因分析和处理建议。三是自动生成孪生场景的描述性文案，运维人员查看某个区域时，AI 自动生成该区域当前状态的文字汇报。

前端在数字孪生项目里切 AI，最重要的一步是定义数据接口的语义层——让模型理解“发送一条指令给设备”对应的 API 是什么。这就用到了 Function Calling 或者 Agent 的规划能力，下面说。

6.5 Function Calling：让 AI 能操作你的前端应用

Function Calling 是这两年最值得前端学习的 AI 能力之一。简单说，就是你给模型声明一批函数，模型在回答过程中判断“这个需求需要调用哪个函数”，然后返回一个结构化的函数调用指令，由前端执行这个函数，再把结果反馈给模型继续生成回答。

这个能力让 AI 从单纯的聊天工具变成了能操作应用的中枢。你可以在前端定义一个函数：

const functions = [ { name: 'queryDeviceStatus', description: '查询指定设备的实时状态', parameters: { type: 'object', properties: { deviceId: { type: 'string', description: '设备 ID' }, timeRange: { type: 'string', description: '时间范围，如 last24h' } }, required: ['deviceId'] } } ];

用户说“帮我看看车间 A 的那台空压机今天运行正常吗”，模型判断这条请求需要调用queryDeviceStatus，返回的 content 里带上了参数 JSON。前端解析到函数调用后，执行该请求，把结果拼装成一条新消息回传给模型，模型再基于真实数据生成最终回答。

前端实现需要注意：每个函数描述必须清晰准确，模型依赖 function description 来判断什么时候调用。还有执行函数要有超时和异常兜底，不能让一次接口超时导致整个对话崩溃。再一个就是函数返回的数据大小要控制，回传给模型的函数结果太长会占用大量上下文 Token，可以截断或精简后再返回。

7. AI 辅助开发：前端提效工具链与学习路径

7.1 用好 AI 编程助手，但不被它带偏

现在的AI编程工具，比如 Cursor、GitHub Copilot，再到更智能的 Claude Code，已经能非常自然地嵌入开发流程。前端工具链的搭建思路是：把 AI 当成一个严谨但需要监督的同事。

前端的 AI 辅助开发，我现在的工作流是：先花 10 分钟把项目规范文档（AGENTS.md 或 .cursorrules）写好，里面包含技术栈、目录结构、命名约束、请求封装方式。然后日常开发的分工是：AI 负责写重复性高的 CRUD 代码、生成单元测试、写 Git Commit message、做代码审查；我负责系统设计、数据模型定义、复杂状态管理、性能优化决策。

这里必须提醒：AI 生成的代码一定要自己看一遍逻辑。我见过太多案例，开发人员完全信任 AI 生成的结果，结果代码有隐蔽的状态更新错误、异步时序问题，或者界面表现正常但数据持久化逻辑是错的。AI 生成代码的正确姿势是把它们当成“初稿”，而不是“终稿”。

7.2 前端学习 AI 的项目式路径建议

结合我自己转 AI 应用开发的经验，我建议前端按下面的项目路线来学，每完成一个都有一个可展示的成果，成就感拉满：

第一个项目，做一个 AI 聊天框。用任一主流模型 API，实现流式输出、多轮对话、Markdown 渲染。这个项目能覆盖 API 调用、状态管理、SSE 解析三个核心知识点。

第二个项目，做一个 AI 文档助手。支持上传文档，后端做切分和向量化，前端实现问答和引用溯源。这个项目能覆盖 RAG 完整流程和长文本交互设计。

第三个项目，做一个 AI 工具页面。比如代码解释器、文案生成器、表格分析助手，重点是用 Prompt 工程控制输出质量，配合 Function Calling 实现工具调用。

第四个项目，把 AI 能力集成进你现有的业务系统。这可能是个内部运营系统、电商管理后台或内容平台。加上一个智能搜索、自动标签或内容总结功能，让业务方真实用起来，再根据反馈迭代。这一步才会真正加深你对前端 AI 应用场景的理解。

7.3 2026 前端面试里的 AI 考点预判

热搜词里有“2026 前端面试题”“前端开发 skills”之类的内容，这里结合我的经验给个判断：前端 AI 化必然是面试热点。未来前端面试一定会覆盖几个维度。

第一个维度是基础的应用能力。你会不会调用模型 API，懂不懂流式输出的解析，知不知道怎么处理流式渲染的性能问题。面试官很可能会让你现场写一个流式输出的 Demo。

第二个维度是架构能力。让你设计一个多模型接入的前端架构，考察点包括：如何抽象统一的模型接口、如何做配置化切换、如何设计消息协议。

第三个维度是经验深度。比如问“你在项目里怎么处理模型返回的 Token 超限问题”“遇到流式输出乱码你怎么排查”“长文档 AI 问答如何保证速度”。这些问题没有标准答案，拼的就是实战经验。

第四个维度是 AI 辅助开发效率。候选人能不能熟练使用 AI 编程工具，有没有积累一套方法论来保证 AI 输出代码的质量。这个能力正在成为区分前端工程师水平的重要标尺。

7.4 给前端新手的 AI 学习资料建议

前端学 AI，最忌讳一上来就买一堆大部头的教材。我的建议是按需学习，需要什么查什么。这里给几个我觉得性价比极高的资源方向：

模型官方文档是第一优先级。OpenAI、Anthropic、以及国内的几家主流模型厂商，他们的官方文档都写得很清楚，有代码示例、参数说明、限流策略，这些才是最新的第一手资料。

开源项目是第二优先级。GitHub 上有一堆 AI 对话前端的开源实现，比如各种大模型的 Web UI 项目，你去看它们的源码结构、状态管理方式、流式处理逻辑，比你从零摸索快得多。

第三是社区里的实操分享。很多一线前端工程师会分享自己在真实业务里嵌入 AI 的踩坑记录，包括 Token 计费的坑、流式渲染的性能优化、多轮对话的内存占用等。这些一手经验在搜索的时候用“AI 前端实战”“大模型集成交付”“SSE 流式踩坑”之类的关键词，比看教程有用得多。

最后，我也特别推荐一个做法：自己维护一个小的 AI 知识库仓库，把你用到的 Prompt 模板、代码片段、踩坑记录都存进去。做得越久，这个仓库的复用价值越高，它就是你区别于其他前端的最大的资产。我自己目前已经有 200 多条 Prompt 模板和 50 多个代码片段，新项目直接调用，效率提升非常明显。

8. 最后说点实操中积累的体会

前端学 AI 这件事，我在实际项目中经历过几个阶段。最早觉得这东西玄乎，后来又觉得 API 一调就完事，再往后踩了性能、安全、体验的各种坑，才发现它其实还是一个工程问题。用一句话总结我的整体感受：AI 前端开发的核心已经从“调接口”变成了“做体验”，谁能在流式输出的顺滑度、交互的自然度、异常处理的完整度上做得更好，谁就能做出真正好用的产品。

有几个小技巧想分享给同行。第一，所有 AI 接口调用都要做超时控制和重试机制。模型服务的稳定性跟传统接口不太一样，高峰期响应慢、偶发超时非常正常。前端要设计合理的重试策略，而且要明确告知用户“模型思考比较慢，请稍等”。

第二，Prompt 要版本化管理。你的 Prompt 会随着业务迭代不断调整，不管理版本的话，你会发现“上周还好的功能这周突然不行了”，但你想不起改了哪句话。我用的是每个 Prompt 带版本号和变更记录，用之前先对比一下。

第三，前端一定要学会看模型返回里的 usage 字段。它包含了本次请求消耗的 Token 数。养成检查 usage 的习惯，你可以及时发现某些用户对话异常消耗 Token 的情况，侧面暴露了 Prompt 设计或上下文管理的问题。

最后我想说的是，前端学 AI 一点都不晚，而且现在的学习成本已经比以前低太多了。API 化让大部分能力都可以直接调用，你真正需要修炼的是产品思维、架构能力和工程意识。以前端为起点出发，这条路能走得很远。

我手上还有几个 AI 前端项目的实战拆解和代码仓库没来得及整理，后续有需要的话可以再展开说说。先这些，希望对你的方向选择有帮助。