企业官网建设流程全解析

“前端岗位消失”的说法，这两年隔一阵就在群里被翻出来讨论一次。尤其当我看到一些同行在焦虑“前端是不是要被AI替代”，再对比那些已经用大模型写业务代码、给公司搭内部AI工具的前端，差距其实不是编程能力，而是对AI知识的掌握程度。我自己从去年开始陆陆续续做了几个面向业务的AI应用，踩了不少坑，也总结出了一套比较明确的知识结构。这篇就把“前端学习AI知识到底需要学哪些”这件事讲透——不列那种永远学不完的清单，而是按真实工作里能用上的优先级来拆。

1. 先拆掉AI的技术围墙：前端该认识哪些核心概念

很多人一提到AI，脑子里就是数学公式、神经网络、反向传播，然后直接劝退。但前端工程师学习AI知识，根本不需要从机器学习理论开始啃。你需要的是建立一个“够用的认知地图”：知道大模型是怎么工作的、什么叫Token、为什么有上下文限制、什么是API调用、什么是向量化，以及哪些概念是纯唬人的。

1.1 把AI知识分层：哪些必须懂，哪些了解即可

我习惯把前端需要的AI知识分成三个层级：

很多前端面试题2026已经开始覆盖这几个方向了，所以这不是我个人的“从兴趣出发”，而是整个行业的前端岗位要求真的在变。你不需要自己训练模型，但需要知道模型从输入到输出经过的大致环节——提示词进到上下文窗口，模型根据概率生成Token序列，最后你拿到文本或JSON。这个链路理解透了，后面调试起来才有方向感。

1.2 关键名词先过一遍：别让概念卡住你

• Token：模型处理文本的最小单位，大约 1 个汉字约等于 1 到 2 个Token，英文单词大约 0.7 到 1 个Token。前端在做输入框字数限制时，不要按字符限制，要按Token算，否则用户贴一段英文可能直接撑爆上下文窗口。

• 上下文窗口：模型一次能“记住”的最大Token总量。比如 8K、32K、128K 等。前端做长文档处理时，必须自己管理“历史消息”的裁剪、摘要、截断，不能无脑把整个会话全量发给模型。

• 温度参数：控制生成随机性。写代码、提取结构化数据时温度调到 0 到 0.3，做创意文案再调高到 0.7 以上。这一点前端在做功能开关时应该暴露给用户，而不是写死一个固定值。

• Embedding（向量）：把文本转换成一串数字数组，语义相近的文本向量距离就近。这是RAG和语义检索的基础，我后面会细讲。

• System Prompt：给模型设定角色和行为约束的提示词。前端在做系统架构时，需要把System Prompt独立抽出来配置化管理，不能写死在代码里。

这些概念看起来多，但每个都有一个“前端对应的实操落点”。你不需要会推导，但你需要知道它影响你代码里哪个参数、哪个调用方式。这就是“够用的认知地图”。

2. 大模型API接入：前端工程师的主战场

前端学AI，最直接的价值输出就是“把大模型接到产品里”。这就绕不开API调用。目前主流大模型服务商都提供了OpenAI兼容格式的HTTP接口，你只需要用fetch就能完成一次对话。但真实项目里远不止“发个请求”这么简单。

2.1 从一次流式请求开始：SSE与fetch的配合

大模型生成文本是逐个Token蹦出来的，所以服务端返回的是流式数据。前端如果等全部生成完再渲染，用户会等十几秒没反馈，体验极其糟糕。正确做法是用SSE（Server-Sent Events）协议，后端分块推送，前端实时消费渲染。

用fetch读取流式响应的核心代码逻辑如下：

// 前端发起流式请求 const response = await fetch("/api/chat", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ messages: [ { role: "system", content: SYSTEM_PROMPT }, { role: "user", content: userInput }, ], stream: true, }), }); const reader = response.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 lines = buffer.split("\n"); buffer = lines.pop(); for (const line of lines) { if (line.startsWith("data: ")) { const payload = line.slice(6); if (payload === "[DONE]") return; const json = JSON.parse(payload); const delta = json.choices[0].delta?.content || ""; updateUI(delta); // 逐字追加到页面 } } }

这里有几个容易踩坑的地方。第一，不要直接用EventSource对象，因为它不支持自定义Header，而很多大模型网关需要你把API Key放Header里做鉴权。第二，数据分块解析要处理半包粘包，网络传输过程中一个data块可能被拆成两截，所以需要维护一个buffer循环拼接。第三，中断和取消要用AbortController，用户在流式输出过程中点击停止按钮，必须能立即终止请求，否则后端还在消耗Token计费。

前端还有一层“渲染层”的工作。流式返回的虽然是文本，但AI应用往往是边生成边出一个Markdown文档，你要接一个Markdown渲染器，并且处理代码块、表格、数学公式等。更进阶的是把“生成过程”本身可视化——当前在读取哪个文档、检索到了哪几个片段、生成到第几段，让用户感受到AI是在“工作”而不是“卡住”。

2.2 API Key安全与后端代理

一个新手最常见的安全漏洞，是把API Key直接放在前端代码或浏览器localStorage里。一旦被人抓到，轻则被盗刷，重则整个业务账户被封。正确的方案永远是在自己的后端维护一个代理接口，前端只向后端发请求，后端负责拼接API Key并转发到模型服务商。

后端代理层还要顺便做几件事：请求频率限制（防止用户无限刷）、Token用量统计（按用户或按部门核算成本）、敏感词过滤和合规检查（面向C端尤其需要）、模型路由（不同用户角色切到不同模型）。这些都不是模型本身的能力，而是前端主导推动的工程化改造。

2.3 模型选型和成本意识

前端工程师在做AI功能设计时，最容易忽略的是成本。我的建议是先算一笔账：

• 高频简单任务（标题生成、标签抽取）用便宜的小模型
• 中等复杂度任务（结构化数据提取、代码生成）用主流的中型模型
• 复杂推理或长文本改写再用旗舰大模型

拿一个常见的“AI帮写周报”功能举例，公司1000人，每人每天调用10次，每次平均消耗1500个Token的输入、500个Token的输出。按当前主流模型市场价格粗算，一天的调用成本大约是几十到一百美元区间。如果所有请求都走最贵的旗舰模型，成本直接翻几倍。所以前端在做选型时，最好在界面层做成可配置项，方便后续动态调整模型。

3. RAG：让AI根据你的业务说话

上一代的AI对话应用只能“聊”，但企业级场景真正要的是“让AI结合私有知识回答问题”。这就进入了RAG的领域。RAG全称是Retrieval-Augmented Generation，检索增强生成。简单理解：用户问问题之前，先从你的知识库里检索相关片段，再把片段塞进提示词里，让模型基于这些材料作答。

3.1 RAG的基本流程：从文档到答案要经过几步

一个完整的RAG应用由离线处理和在线查询两条线组成。

离线处理（也叫索引阶段）：

1. 文档解析：把PDF、Word、Markdown等格式转成纯文本，去掉页眉页脚。
2. 清洗：去掉空行、乱码、特殊符号，按语义拆块。
3. 切块：按固定长度（例如300到500个Token）切分，注意保留段落完整性。
4. 向量化：用Embedding模型把每个文本块转成向量。
5. 存储：向量数据写入向量数据库（如Milvus、Qdrant、Chroma、pgvector），同时保留原文引用信息。

在线查询阶段：

1. 用户问题向量化：用同一个Embedding模型转换。
2. 相似度检索：在向量库里找到最相似的Top-K片段。
3. 组装提示词：把用户问题和检索片段一起组装成Prompt，发送给大模型。
4. 返回并展示来源：答案生成后，前端要把引用的原文段落用角标标记出来。

前端在这个链路里的角色远超想象。绝大多数业务方并不关心你的向量库有多快，他们看到的是“这个AI能不能在回答下方展示引用来源的原文”。这个交互设计就是典型的活：检索到的原文卡片、角标数字、点击跳转阅读原文、相似片段对比等。

3.2 一个可以落地的练手方向：ChatPDF类的知识问答工具

假设你想做一个内部员工问制度的小工具。用户上传一份几百页的制度PDF，AI要能回答“年假怎么算”“报销流程是什么”这类问题。前端的职责大概分这些模块：

• 上传与解析进度页：大文件上传用分片，解析进度实时推送到前端。
• 文档切块可视化：允许管理员查看文本被切成了哪些块，每块有多少Token。
• 问答对话框：流式输出，答案里的每个论点都带引用角标，点击弹出来源段落。
• 无结果引导：当检索到的内容相关性太低时，前端要明确提示“知识库中暂未找到相关内容”，而不是让AI强行编造。

做这个项目时我踩过一个很经典的坑：切块大小与检索质量强相关。块太小，语义会被切断；块太大，检索返回的片段会夹带大量无关噪声，既浪费Token又干扰生成。实践下来，300到500字左右一块、相邻块之间重叠20到50字，是比较通用的默认参数。切块时还要优先保留标题层级，让每个片段自带“章节上下文”。

3.3 前端要避开的“伪RAG”陷阱

很多团队做一个“AI问答系统”，其实是把所有文档直接灌进上下文让大模型硬读。这个方案在文档不超过上下文窗口时看似好用，但一旦文档变多、变大，费用和延迟都会爆炸。真正的RAG优势在于：知识更新不需要重新训练模型，替换知识库里的文档就行；来源可追溯，回答背后有凭有据。

另外一个容易踩的点是Embedding模型的选型问题。全英文场景用OpenAI的Embedding接口没问题，但中文场景特别考验模型对分词和语义的理解。我建议中文业务先跑一个评测集——准备几十条代表性的问题，人工判断检索到的Top-5片段是否真的相关，再决定要不要换Embedding模型或调整切块策略。

4. Agent与前端自动化：未来的交互入口

如果说RAG让AI具备了“知识”，那Agent就是让AI具备了“行动能力”。这也是目前AI Agent概念在面试和实战里越来越频繁出现的原因。前端工程师学习AI知识，Agent是一个绕不开的进阶方向。

4.1 Function Calling：让大模型学会调用你的工具

Function Calling（函数调用）是大模型厂商提供的一种机制：你定义一批带参数说明的函数，模型在回答过程中判断需要调用哪个函数时，会返回一个结构化的调用指令，你可以据此执行真实函数，再把执行结果回传给模型继续推理。

举个例子，你在做一个前端运维助手，想让AI能查服务器状态：

const tools = [ { type: "function", function: { name: "get_server_status", description: "通过传入的服务器IP地址查询该服务器的实时运行状态", parameters: { type: "object", properties: { ip: { type: "string", description: "服务器IP地址，例如 192.168.1.100", }, }, required: ["ip"], }, }, }, ];

当用户说“帮我看看10.2.3.4这台机器现在负载高不高”，模型不会直接读数据，而是返回一个函数调用请求，你的代码收到后去执行真实的查询接口，再把结果追加到对话里，让模型基于真实数据给出结论。前端在这个环节的关键工作是：函数定义规范与参数校验、调用过程中的状态可视化（“正在查询服务器状态…”）、失败重试与用户确认机制。

4.2 MCP协议：Agent工具的标准化方向

Model Context Protocol（MCP），本质上是一个让AI应用和外部工具之间通信的标准化协议。类比一下，它像USB接口——过去每个设备有自己专用的充电线，现在统一成一个标准，任何支持MCP的工具都可以直接被AI应用调用。对于前端而言，意味着以后做AI功能时，不需要为每个数据源单独写一套对接逻辑，只要数据源提供了MCP服务，AI就能直接访问。

目前主流的浏览器自动化工具、数据库连接器、文件系统工具、代码解释器，很多都已经提供MCP服务了。前端参与Agent开发时，可以考虑把自己团队的内部系统包成MCP服务，这样以后的AI应用顺手就能调用这些系统能力。

4.3 浏览器自动化和Agent可视化

有一种Agent形态值得前端特别关注：自动操作浏览器。比如让AI自己打开网页、点击按钮、填写表单、提取数据。这类Agent的技术原理不复杂——通过浏览器调试协议控制页面，大模型把用户指令拆解成操作步骤，每一步执行后获取新的页面状态并反馈给模型，类似“看一步走一步”的循环。

前端在这里的价值是做一个“Agent控制台”：展示AI当前的思考过程、计划执行到哪一步、每个动作的截图、允许用户中途介入修改步骤，以及在危险操作前弹确认。这个界面的交互复杂度远超普通CRUD页面，非常考验前端对异步流程和状态管理的理解。

面试中如果被问到Agent项目，建议不要只讲“我调用了大模型”，而是讲清楚：任务拆解、工具定义、循环终止条件、用户介入机制、安全审核这五个维度。

5. 提示词工程 + AI编程：每天都会用到的技能

这部分看起来不像“技术”，但实际是前端学AI后性价比最高的一块。无论你是在写一次性脚本，还是在给业务方搭建AI功能，提示词工程都直接决定输出质量。

5.1 提示词的核心逻辑：限定任务、限定格式、给出示例

很多人的提示词写得像聊天，写道“帮我写一个登录页面”。模型的输出大概率也是稀里糊涂的。但如果你像给实习生布置任务一样写提示词，效果立刻不一样：

你的角色：资深前端工程师。 任务：使用React + TypeScript实现一个登录表单组件，包含用户名、密码、验证码三字段。 要求： 1. 使用Ant Design组件库。 2. 表单提交时做前端校验，用户名不少于3位，密码不少于8位。 3. 提交成功后调用 /api/login 接口，展示加载状态和错误提示。 4. 输出完整组件代码，不要解释思路。

这个提示词做对了三件事：角色限定让模型使用正确的背景知识；任务边界清晰让它不开源发散；输出格式明确让它直接生成可用代码。前端偏业务的场景下，多花30秒把需求写清楚，能省掉几十次无意义的修修补补。

5.2 JSON结构化输出：让AI的结果能被代码安全消费

纯文本输出在AI产品里很难直接落库，所以现在主流模型都支持JSON Mode，强制模型输出合法的JSON对象。前端在接接口时，一定要在产品层面约定好输出结构，例如：

{ "code": 0, "data": { "summary": "一句话总结", "keywords": ["keyword1", "keyword2"], "risk_points": ["风险点1"] } }

前端拿到JSON后还要做一层结构兜底校验。别迷信“模型一定会遵守格式”，实际情况中经常出现字段名变化、嵌套层级错误、甚至JSON不完整被截断的情况。所以建议在解析层写一个修复函数：能解析就解析，解析失败就提示用户重试，而不是让页面直接报错白屏。

5.3 AI编程工具和前端工作流

AI编程工具已经成了很多团队前端的日常标配。我认为前端学AI知识时，应该主动把大模型助手当成“结对编程伙伴”，而不是搜索引擎。实操中我有一个自己的节奏：

• 写新组件时：先把接口文档、设计稿描述、组件库版本告诉模型，让它先写一版，然后我检查状态管理和边界条件。
• 改遗留代码时：把代码片段和报错信息整段发给模型，让它先解释这段代码在干什么，再让它给出修改方案，不直接粘贴。
• Code Review时：把Diff摘要抛给模型，让它关注内存泄漏、重复渲染、未捕获Promise、安全问题，能抓到不少漏掉的细节。

但有一点要提醒：AI生成的代码在“量”上是惊人的，在“正确性”上仍然需要人来兜底。尤其是权限相关、支付相关、数据一致性相关的逻辑，必须人工逐行审查。我见过有人全盘接受AI生成的权限校验代码，结果外层的if判断没问题、内层却漏了一个return，直接把越权漏洞带上线了。这个底线前端不能丢。

6. 学习路线与练手项目：从0到1别走弯路

最后这部分是给“准备开始学但不知道从哪下手”的人。我整理了一条可执行的路线，不是按知识点堆砌，而是按“能做出东西”的顺序安排。

6.1 路线拆解：分四个阶段递进式学习

第一阶段（1到2周）：API理解和基础调用目标：用fetch调用一个大模型接口，实现一个最简单的聊天机器人。重点理解messages参数、流式输出、上下文管理。参考代码不用自己造，直接跑通官方示例再改造。

第二阶段（2到3周）：RAG和知识库应用目标：做一个带上传、解析、检索、问答的助手工具。重点理解Embedding、向量检索、知识库结构。这个阶段同时练了文件解析、状态管理、流式渲染、异步任务队列等前端硬技能，一举多得。

第三阶段（3到4周）：Agent与Function Calling目标：给AI接上2到3个真实工具，比如天气查询、数据库查询、内部系统搜索。重点理解工具定义JSON Schema、执行循环、状态反馈。作品可以是一个“个人AI助理”类的演示，面试时非常容易展开讲。

第四阶段（长期）：工程化与产品化目标：AI能力接入已有业务系统，做好安全审计、成本监控、体验设计。重点是：系统提示词配置化、请求队列与并发控制、内容合规、Prompt版本管理。

6.2 练手项目清单：每个都能写进简历

我筛选项目的标准很简单：业务价值清楚，技术栈踩得准，能讲出自己独有的思考。推荐这几个方向：

• 企业知识库AI问答系统：支持多格式文档上传、来源角标引用、敏感词过滤。
• 数据提取助手：用户粘贴一段非结构化文本，AI按预设字段输出JSON并可视化展示和修正。这个项目特别能体现前端对JSON结构设计的理解。
• 浏览器操作Agent控制台：让AI根据指令自动打开网页做信息采集，前端展示计划步骤、实时截图、人工确认节点。
• AI报表解读器：接入公司数据接口，AI把数据变化转成自然语言解读，并支持下钻问答。注意所有回答必须带数据来源。

做这些项目时，别把重心全放在“调用了大模型”上，面试官更想听的是：你怎么处理多轮会话的记忆、怎么设计引用数据校验、怎么控制成本和延时、怎么处理模型输出不稳定。这些才是前端介入AI应用的独特价值点。

6.3 关于“前端岗位消失”的几句实话

很多前端被“前端岗位消失”的说法搞得很焦虑。以我观察到的实际情况，消失的不是前端岗位，而是只会“切图、调接口、写页面”这种单一技能的岗位。AI把低层次代码的生成成本打下来了，但把“需求拆解、技术判断、交互设计、工程兜底”这些能力的重要性拉高了。前端学习AI知识，最稳的心态不是“怕被替代”，而是“我能用AI做出原来三个人才能做的事”。把学习重点放在AI API接入、Agent编排、RAG应用、提示词工程这些地方，你的岗位价值不会降低，反而更稀缺了。

最后分享一个我用下来的习惯：每学一个新的AI能力，就强制自己写一篇几十行的最小Demo发到公司的内部知识库。一来能沉淀踩坑记录，二来同事遇到同类问题可以直接搜到，三来这本身就是一种“可展示的技术影响力”。学习的终点不是“会调一个接口”，而是你能把学到的知识沉淀成别人也能用得上的方法论。这一点，前端和AI其实是通的。