大家好，我是刘布斯。

在前端混了十多年，从 jQuery 时代一把 $ 走天下，到后来三大框架“打江山”，再到现在的各种构建工具“内卷”，感觉啥场面都见过了。

但最近这两年的 AI 热潮，尤其是大模型（LLM），说实话，刚开始我心里也犯嘀咕：这玩意儿，跟我们前端到底有多大关系？是不是又要“狼来了”？

跟不少圈里朋友聊，也面试了一些新人，发现大家对这块儿要么就是觉得“与我无关”，要么就是焦虑得不行，生怕马上被 AI “干掉”。

今天就想以一个老前端的身份，跟大家聊聊我的看法：大模型对于我们前端来说，不是危机，而是个带点挑战的巨大机遇。关键看你怎么用，以及你到底懂多少。

这篇文章不讲那些虚头巴脑的理论，咱们就从三个层面，聊聊前端工程师现阶段最应该知道的大模型知识。

第一层：把它当成“外挂”，先让自己的开发效率起飞

这应该是最立竿见影，也是所有前端同学都应该立刻马上搞起来的。别把大模型想得太复杂，你就把它当成一个语言能力超强的、24小时待命、还不要工资的“结对编程小弟”。

我现在的开发流程里，很多环节都已经离不开它了。举几个我最常用的场景：

1. 写那些烦人的“杂活”代码：比如，项目里要写个解析 URL query 的复杂函数，还得考虑各种边界情况。搁以前，得自己吭哧吭哧写半天，还得找一堆测试用例。现在呢？我直接把需求丢给 GPT-4 或者 Copilot Chat：“帮我写个 JS 函数，解析 URL query string，要处理数组、特殊字符解码，还要有详细的注释和测试用例。” 几秒钟，一个质量相当不错的代码片段就出来了。我需要做的，是审查它、理解它、然后把它整合进我的代码库。注意，是“审查”，不是“复制粘贴”，这是专业工程师的底线。

2. Debugging 的新思路：有一次遇到个特诡异的 bug，一个 React 组件在特定交互下状态更新总是不对，console.log 打了一堆，眼睛都看花了。后来我索性把组件代码、相关状态管理的代码，连同报错信息和我的操作步骤，一股脑全贴给 AI，问它：“你觉得问题可能出在哪？” 你还真别说，它给的一个可能性提示——“你这里的 useEffect 依赖项数组是不是漏了一个变量，导致闭包陷阱了？”——一下就点醒了我。有时候我们钻进牛角尖，AI 这种“旁观者清”的视角反而能提供意想不到的思路。

3. 学习和方案调研：想用一个新的库，比如 TanStack Query，但文档又长又臭。可以直接问 AI：“我想用 TanStack Query 在 React Native 里实现一个下拉刷新、上拉加载更多的列表，并且需要做本地缓存。能给我个核心代码示例吗？” 它给出的代码基本就是个可以直接跑的 demo。这比自己一行行啃文档快多了。

踩坑经验：千万别完全信它！尤其是一些冷门的 CSS 属性或者不常用的 API，它经常会“一本正经地胡说八道”，给你编造一个不存在的 API 出来。我上次就被它“创造”的一个 Canvas API 坑了小半个钟头。所以，AI 给你的代码，永远是“草稿”，最终拍板的必须是你自己。把它当成 Stack Overflow 的一个超级进化版就对了。

第二层：开始琢磨怎么在“产品”里用它，这是进阶的关键

如果说第一层是提升个人效率，那这一层就是提升你的技术价值和产品视野了。现在很多公司都在探索怎么把 AI 能力整合进现有产品，而我们前端，作为离用户最近的一环，能做的事情其实非常多。

但这不意味着我们前端要去研究什么炼丹、调参，那些是算法大佬们干的活。我们要关心的，是如何消费（Consume）大模型的 API，并把它无缝地融合到用户体验里。

我上半年研究的一个项目，尝试在一个网站中嵌入 AI 功能。这里面就有几个前端必须搞定的点：

1. 流式传输（Streaming）：大模型的 API 回复通常不是一下子全给你的，而是一个字一个字地“吐”出来，就像打字机一样。这种体验对用户来说是最好的，能最快看到反馈。在前端，你就不能用普通的 fetch 请求然后 .then() 就完事了。你得用 ReadableStream 或者 EventSource (SSE) 来处理这种流式数据。怎么接收、怎么拼接、怎么在界面上实时渲染出来，这套活儿现在已经是前端面试里关于 AI 的必考题了。我前阵子面试一个候选人，问他怎么实现打字机效果，他要是能从 SSE 聊到 fetch 的 body 属性是个 ReadableStream，那绝对是大大加分。

2. 前端的 Prompt 工程：别以为 Prompt 只是后端的事。很多场景下，前端需要根据用户的输入、当前页面的上下文（比如用户正在编辑的文字、选中的表格），动态地在本地“组装”成一个高质量的 Prompt，再发给后端。比如，一个“帮你润色”的功能，前端传给后端的，不应该仅仅是用户选中的那段文字，最好带上“这是一篇技术博客的段落”、“用户的要求是让语气更专业”这类上下文信息。怎么在前端收集和构造这些上下文，直接决定了最终生成效果的优劣。

3. 交互设计和状态管理：引入了 AI，产品的交互就变了。你需要处理加载中（Loading）、生成中（Streaming）、生成完毕、错误处理等多种状态。这些状态怎么优雅地展示给用户？比如，生成内容时，是不是应该有个“停止生成”的按钮？如果生成结果不满意，如何提供“重试”或“换一个”的选项？这些都是前端需要考虑的体验细节，也是体现你产品感和设计能力的地方。

大家一定要注意：API Key 的安全问题！任何情况下，都不要把你的 OpenAI 或者其他大模型的 API Key 直接暴露在前端代码里。这等于把家门钥匙直接挂在门上。所有对大模型的 API 调用，都必须通过你的后端服务器做一层转发。前端请求你的后端，你的后端再去请求大模型的 API，这样 Key 才能保证安全。这是个红线问题，面试时问到，答错就直接 out 了。

第三层：理解它的边界和成本，让你思考得更深

到了这一层，说明你已经不满足于当一个“调包侠”了，而是开始像一个架构师或者产品负责人一样思考问题。

1. 理解 Token 和成本：大模型的调用不是免费的，是按 Token 计费的。你可以简单理解成按“字数”算钱。这玩意儿对前端的影响是啥？意味着你不能无限制地把长篇大论塞给 AI。比如，想让 AI 帮你总结一个网页内容，你是把整个 document.body.innerText 全都传过去吗？可能直接爆 Token 上限了，而且费用会很贵。所以你需要思考，是不是可以先在前端做一些预处理，提取关键文本？或者是不是可以让用户手动选择要总结的区域？对成本的感知，是区分普通工程师和高级工程师的一个重要标志。

2. 知道它的“不能”：大模型不是万能的。它没有实时联网能力（除非通过插件或特定 API），所以你问它今天的天气，它不知道。它的知识有截止日期，你问它最新的前端框架是啥，它可能还在说去年的东西。它也没有真正的逻辑推理能力，复杂的计算或者逻辑判断它会经常出错。了解它的能力边界，可以让你在做技术选型和产品设计时，避免掉进大坑，不会设计出一些看起来很美好但根本无法实现的功能。

3. 思考延迟（Latency）问题：调用一次大模型 API，快则一两秒，慢则十几秒，这在前端看来是无法接受的延迟。所以，你不能把 AI 功能放在用户操作的主路径上，阻塞用户的下一步操作。大部分 AI 功能都应该是“异步的”、“非阻塞的”。怎么设计 UI，让用户在等待 AI 响应的时候不焦虑，甚至可以继续做别的事情，这是对前端功力的一大考验。

总而言之，我觉得大模型这波浪潮，对我们前端来说，更像是一次“装备升级”。它不会替代我们写业务逻辑、调页面样式的核心工作，但它能让我们把这些工作做得更快更好。同时，它也开辟了一个全新的领域，让前端可以直接参与到构建下一代智能应用的过程中去。

别焦虑，也别躺平。我的建议是，先从“外挂”用起，在日常工作中把它玩熟。然后搞个 API Key，自己写点小东西，把流式传输、Prompt 构造这些坎儿趟平。当你能把这套东西自然地融入到你的技术栈里时，你会发现，新的机会已经悄悄来到你面前了。

就这样吧，一点不成熟的经验之谈，希望能给还在迷茫的你一点启发。

最后

还没有使用过我们刷题网站（https://fe.ecool.fun/）或者刷题小程序的同学，如果近期准备或者正在找工作，千万不要错过，题库已经录入 1600 多道前端面试题，除了八股文，还有现在面试官青睐的场景题，甚至最热的AI与前端相关的面试题已经更新，努力做全网最全最新的前端刷题网站。

有会员购买、辅导咨询的小伙伴，可以通过下面的二维码，联系我们的小助手。