企业官网建设流程全解析

最近我在梳理技术团队的人才评估标准时，明显感觉到2026年的招聘风向已经和去年完全不同了。过去大家聊AI更多是“你用过哪些AI工具”，现在前端、后端、算法三个岗位的JD里，AI技能已经从锦上添花的加分项，变成了明晃晃的必选项。特别是对标一线大厂的核心业务团队，面试官不再问“你会不会调大模型API”，而是直接要求候选人讲清楚：你怎么做RAG、怎么优化推理延迟、怎么设计Agent任务链路、怎么评估模型效果。

这篇文章我打算把三岗位的AI技能清单拆开揉碎，按“基础必须掌握、进阶加分、大厂面试高频题”三层来讲，同时结合我自己带项目和筛简历时的一些实际感受。如果你正在准备春招、暑期实习，或者刚转行AI方向，这份清单可以直接拿来对照自测。

1. 为什么2026年AI技能不再是"加分项"

1.1 岗位需求的变化：从"会用工具"到底层逻辑

三年前，简历上写一句“熟悉ChatGPT使用”可能还能博眼球。现在再这么写，面试官只会觉得你没有深入思考。大厂业务对AI的依赖已经从“偶尔调用”变成了“核心链路的一部分”。前端要处理模型流式输出、端侧推理、交互降级；后端要保证RAG系统在高并发下的稳定性、可控成本；算法岗更是直接背上了数据、训练、评估、部署的全链路责任。

所以你会发现，2026年的岗位要求不是“你懂一点AI”，而是“你能用AI解决真实业务问题”。这背后需要的是工程化思维：怎么做限流、怎么缓存、怎么评估效果、怎么监控模型退化。单纯会“调包”已经很难通过一面了。

还有一个重要变化是，面试官自己也在用AI准备面试题。他们更清楚哪些知识能通过搜索引擎快速获得，哪些能力必须靠动手积累。底层逻辑、系统设计、成本控制、容错方案，这些是AI替代不了的经验壁垒，也正是大厂真正想看的东西。

1.2 哪些技术栈会真正沉淀下来

说实话，AI技术迭代太快，2024年还在聊的很多框架到了2026年已经被重构。但有些底层原理不会过时：

• 大模型API的基本交互逻辑：流式、函数调用、多轮上下文管理。
• 向量检索与RAG流程：切分、嵌入、召回、重排、生成。
• Agent的任务拆解与工具调用协议。
• 模型推理的延迟、吞吐、成本优化思路。
• 数据闭环和评估体系：没有评估就没有迭代。

工具库可以换，但解决问题的框架会留下来。所以这份清单里我不会列一大堆注定被淘汰的琐碎库，而是把三个岗位最核心的AI工程能力讲透，告诉大家这些能力背后对应的面试题和实战项目应该怎么做。

2. 前端岗位：AI能力从"调接口"到"模型的终端宿主"

2.1 必备AI技能清单速览

前端岗位在AI团队里的角色正在发生质变。过去前端只是把后端返回的JSON渲染成页面，现在前端要直接面对模型输出，负责流式渲染、交互状态管理、提示词注入防护，甚至要把小模型搬到浏览器里跑。

我整理了下面这个清单，你可以对照检查：

2.2 前端AI应用开发的三个层次

第一层，也是最常见的：调大模型API，做一个流畅的聊天对话框。别小看这件事，很多候选人栽在细节上。比如流式输出时，如果用户反复点击发送，你怎么处理？要不要取消上一个请求？错误之后要不要重试？上下文数组怎么裁剪？Token超限了怎么办？大厂面试不止要你写功能，还要你考虑边界和异常。

我自己的经验是，流式输出的前端实现有几个容易忽略的坑：第一，一定要用AbortController去中断的请求，否则组件卸载后回调还在执行，会报内存泄漏警告；第二，SSE流的JSON切片可能把一个中文字符拆成两半，你需要做缓冲和拼接，不能直接JSON.parse；第三，渲染Markdown时要小心xss注入，模型如果被提示词注入，返回的内容可能包含恶意脚本，前端必须做过滤或使用安全的markdown渲染器。

第二层，前端主动参与RAG链路。大厂很多AI应用是知识库问答，前端不能只是傻等后端结果。你可以自己用LangChain.js在前端完成文本切分、向量化、检索，甚至调用本地模型生成摘要。这样做的优势是用户数据不用全部上传，隐私性好。缺点是前端性能压力大，所以要在“全端执行”和“后端兜底”之间做降级设计。

我在做某个跨平台系统Demo时，前端需要支持用户导入一个PDF后提问。当时我们做了两套方案：PC端直接用WebLLM在本地跑小模型，移动端因为性能不足自动切换成后端API调用。这个降级逻辑看起来简单，但实际上需要处理很多状态同步问题，比如本地上已经加载的向量索引怎么复用，模型切回后端后上下文是否还连续。这些细节反而是面试官最想听你讲的东西。

第三层，端侧AI与AI原生交互。2026年浏览器能跑的不再是简单demo，WebGPU的普及让小模型的推理速度大幅提升。前端可以借助WebLLM、Transformers.js在用户的浏览器里跑3B、7B甚至13B的量化模型。这意味着你的应用可以不依赖后端，离线也能工作，这对隐私敏感场景（比如医疗文本、笔记内容）非常有吸引力。

踩过的坑提醒：不要一上来就追求在浏览器跑大模型。模型加载时间、显存占用、浏览器兼容性都要考虑。我实测下来，在Chrome上通过WebGPU加载4bit量化的7B模型，首包大概需要2~4秒，之后每个token生成速度在20~50毫秒左右，但如果用户用的是Safari，很多WebGPU特性不支持，必须切到WebGL或者CPU后端。所以做之前先给用户弹个兼容性检测。

2.3 大厂前端面试高频考察点与实战场景

现在大厂前端面的AI题往往围绕真实业务展开。我总结几个高频场景：

第一个：写一个类似“AI搜索框”的组件，支持用户输入问题、流式显示答案、点击停止、重新生成、多轮上下文。看似简单，但考察点密集。你需要理解流式协议、并发控制、错误处理、状态管理、以及如何优雅地在列表中插入流式更新的token。

第二个：如果让你设计一个“合同条款问答”的前端页面，合同PDF有几十页，前端怎么处理？很多候选人会直接说“把PDF传给后端”，但更好的回答是“先在前端用PDF解析库抽文本，用JS分块后调嵌入模型做向量化，检索在本地或后端完成，高亮引用的原文片段”。这个回答展示了你对RAG全流程的理解，而不是只会调接口。

第三个：“如何在前端做提示词注入防护？”这个问题现在真的很常见。后端会有系统提示词，但前端可能会拼接用户输入。如果用户输入的文本里带有“忽略之前的指令”，直接拼到Prompt里就危险了。你可以回答：把用户输入作为不可信数据，限定在数据区；对引用的文档内容做truncation；后端再做一层校验。前端不能只想着界面，要考虑到模型层面的安全。

第四个：性能优化。流式聊天组件在快速产出token时可能造成频繁重渲染。推荐用“增量更新 + 不变量引用 + 虚拟滚动”的优化方案。同时用Web Worker去做文本解析和向量化，这样主线程卡顿会明显减少。

3. 后端岗位：AI工程的扛把子，拼的是系统稳定性与成本

3.1 必备AI技能清单速览

后端是AI落地的核心承载者。前端体验再好，后端如果扛不住并发、控制不住成本、没有容错机制，AI应用一样会翻车。大厂后端AI岗位现在更偏向“AI工程化”，不是普通CRUD，而是围绕模型服务、检索系统、Agent编排、数据管道来做系统设计。

3.2 RAG服务化落地的关键环节

RAG已经是后端AI项目的基础，但能在生产环境稳定运行的RAG没有想象中简单。我会把它拆成几个环节讲。

数据接入与解析：输入可能是PDF、Word、网页、数据库。PDF解析尤其痛苦，有的PDF是扫描件，要先OCR；有的PDF排版混乱，段落会被切断。你需要在解析阶段保留文档结构，比如标题层级、表格、图片。否则后续切分效果会很差。我的做法是先用结构性解析工具抽出块信息，再根据语义相似度合并相邻短块，这个步骤能明显提升召回。

切分策略：无脑按固定字符数切分是新手最容易犯的错误。固定切分会把一个语义完整的段落硬生生切成两半，检索时匹配不到完整信息。我建议按“标题层级优先，辅以段落边界，最后才用max_tokens控制上限”的方式来做。如果一个段落太长，用重叠窗口切分，保证上下文连续性。

嵌入模型选型：不要一上来就用最大的Embedding模型。先考虑维度、成本、语言适配。中文场景要选在中文语料上训练过的模型。嵌入模型也分不同用途，用于检索的模型和用于聚类的模型不一样。我们通常用多个候选模型做线上效果对比，而不是只看离线指标。这步很花时间，但非常值得。

向量数据库与混合检索：存向量只是第一步，更重要的是检索策略。纯向量检索在某些领域（比如法律、医疗）表现不一定好，因为术语很精准，语义近似反而匹配差。所以大厂基本都会做“BM25稀疏检索 + 向量稠密检索”的混合召回，再用RRF（Reciprocal Rank Fusion）或重排模型把结果融合。这个组合在实际项目里效果稳定得多。

生成阶段：检索到的上下文和用户问题一起交给大模型。这里有一个关键点：上下文窗口不是无限塞，塞得越多模型越容易迷失，也越慢越贵。你需要设计“上下文压缩”逻辑，去除无关段落，只保留与用户问题最相关的内容。同时要控制引用来源，让模型学会用[来源1]这样的格式标注。这样才能做可信AI。

评估与迭代：RAG上线后，不能只看几个case觉得“不错”。建议你构建一套包含“检索命中率、生成忠实度、答案相关度、引文准确率”的评估集，用RAGAS这类框架做自动化评测。我见过很多团队辛辛苦苦搭好RAG，最后因为没有评估体系，优化全靠感觉，结果越改越差。这是最值得投入时间的地方。

3.3 模型部署与推理优化的经验

后端AI越来越拼推理性能，因为大模型推理成本很高。如果你只是调别人的API，这关可以略过。但如果你要把开源的Qwen、LLaMA、DeepSeek系列模型部署到自己的服务里，就必须理解推理优化。

首先说显存占用。7B模型FP16权重大约14GB，加上KV cache和激活值，一般需要24GB显存。如果放到A10（24G）上，必须用量化。4bit量化之后权重只有约4GB，可以轻松放进一张卡，但精度有轻微损失。你要根据业务场景做取舍。推理框架方面，vLLM是当前主流，它支持PagedAttention、连续批处理、前缀缓存，能够把吞吐提升数倍。相比简单用Transformers库的generate方法，vLLM的吞吐可能有5到10倍差距。

再讲一个容易忽略的点：模型服务化不能只暴露一个生成接口。你需要考虑流式输出、健康检查、预热、优雅退出、超时控制。模型在冷启动时加载很慢，所以上线前要做预热，把权重加载到显存。K8s上要做多副本和HPA。GPU是稀缺资源，不能像普通服务一样随便扩缩容，最好根据排队长度做弹性伸缩。

另外，长上下文场景的优化也是重点。现在模型支持几十万token，但实际推理速度会随序列长度增长而显著变慢。你可以用prompt缓存，将系统提示词和文档前缀缓存下来，这样重复请求能省去prefill时间。如果你的服务偏向多轮对话，还要考虑历史token裁剪策略。

成本控制是后端AI另一个大厂面试常谈的话题。面试官很可能会问你：如果现在线上请求量很大，但成本飙升，你怎么优化？你需要从模型选型、量化、缓存、网关限流、降级方案全链路给出答案。

3.4 后端AI面试高频考察点

后端AI面试最经典的场景题是：设计一个企业知识库问答系统，支持2000人同时使用，要求平均首token延迟小于1秒，总回答时间小于8秒，怎么设计？

回答时不要一上来就摆技术栈，先拆架构。入口有网关做鉴权和限流，请求先到队列，模型服务是多副本，前面有缓存层。如果命中缓存直接返回；没命中则走RAG流程：先向量检索+关键词检索，再重排，拼接Prompt，最后调用模型推理。文档更新时通过异步任务同步到向量库，避免写入影响在线查询。同时要设计降级方案：模型服务挂了，可以返回缓存的相似答案或提示用户稍后重试，不能让整个系统雪崩。

这类题考察的是系统设计能力，不是具体框架。你需要在答完技术方案后，主动聊监控指标：QPS、缓存命中率、检索耗时、GPU利用率、首token延迟、错误率。这样会给面试官留下“可落地”的好印象。

还有一类的原理题：“为什么RAG要用混合检索？”可以回答：向量检索擅长语义相似，但对精确术语和ID匹配差；BM25擅长关键词匹配，但对同义改写无能为力。两者融合能互补。同时RAG还需要重排模型，因为向量召回的top10可能有很多噪声，重排模型能精排。

4. 算法岗位：从"刷模型"到"造数据、调系统、抠成本"

4.1 必备AI技能清单速览

算法岗原本是AI的核心，但在大模型时代，算法工程师的职责边界扩大了。你不只是训练模型，还要管数据、做评测、调推理、写训练代码、维护实验环境。大厂算法岗面试也更看重“用数据说话”。

4.2 数据工程与评估体系是真正的分水岭

很多人以为算法岗每天在做模型结构设计，但真正在大厂做过项目的都清楚，数据才是决定效果上限的因素。同样的开源模型，有人微调后效果飞跃，有人反而变差，差别往往在数据。

数据构造：微调数据不是越多越好，关键在“分布准确、覆盖边界、难度适中”。从通用语料里直接抽句子当指令数据是错误做法，因为模型学不到指令遵循能力。需要构建“指令-输入-期望输出”的三元组，而且要有一定比例的负样本。比如“模型答非所问”“引用不存在的信息”等badcase，都要收集。

我自己做过一个模拟文本分类项目的微调，刚开始用公开的通用语料，效果提升很小。后来从业务日志里扒出真实badcase，再人工标注了5000条高质量样本，效果立刻上来了。这让我深刻意识到，闭门造数据没有用，必须贴近真实使用场景。

数据配比也一样重要。通用数据太大，会稀释领域能力；领域数据太多，可能会导致灾难性遗忘。常见做法是混合比例控制在“领域数据:通用数据=1:4到1:10”之间，然后通过小规模验证集反复调。

评估体系：算法岗面试时一定要能够说出你用了哪些指标。大模型生成任务不能用简单的accuracy，因为答案可以有多种表达。你需要用“语义相似度 + 规则命中 + 人工盲评”相结合。线上还要看用户反馈，比如点赞、点踩、追问率。更专业的做法是构建一个包含“有用性、忠实度、安全性、格式正确性”的多维评估框架，定期组织标注团队打分。

目前开源社区里有很多评测工具，比如RAGAS、DeepEval等，但它们的默认指标未必适合你的业务。你得学会自己写评估Prompt，让一个大模型给另一个大模型的答案打分，同时要校验打分稳定性。否则辛辛苦苦做出来的评估体系可能噪音很大。

4.3 多模态、强化学习与模型压缩的真实权重

2026年，纯文本模型已经不够用了。无论是办公场景的图文理解，还是营销场景的视频生成，算法岗都要接触多模态。面试中高频考察：怎么把图片编码成视觉token，怎么对齐文本与图像特征，怎么设计跨模态的指令数据。你不一定要从零训练一个多模态模型，但至少要知道CLIP类模型的工作原理，会处理图像和文本的联合表征。

强化学习相关技术也很热。大厂尤其关注RLHF/DPO、安全对齐。你不需要能手推PPO全部细节，但要能说清楚RLHF和DPO的核心区别：RLHF需要训练一个奖励模型然后做强化学习，流程长、不稳定；DPO直接基于偏好数据优化策略，更简单、更稳。面试官往往更关心你怎么构造偏好对数据，比如两个答案哪个更好，为什么好，这比背公式更贴近实战。

模型压缩在端侧和私有化场景是重头戏。你要熟悉量化（PTQ、GPTQ、AWQ）和蒸馏。实际项目里，把一个大模型蒸馏成小模型，往往比直接用小模型微调效果更好。蒸馏时不仅要用教师模型的软标签，还要注意温度参数的选择。量化时最容易踩的坑是只看权重误差，不看生成效果。有些层对量化特别敏感，需要混合精度处理。

4.4 算法岗面试高频考察点与准备方向

算法岗面试流程通常包含算法题、模型原理、项目深挖三部分。模型原理题常见的有：

• Transformer的self-attention计算复杂度是多少？为什么是O(n²)？
• LoRA的原理是什么？如果rank设为64效果反而不如rank=8，可能是什么原因？
• RLHF和DPO核心区别是什么？DPO的损失函数是怎么推导的？
• 你如何判断一个微调模型是否有“幻觉”？怎么减少？

这些题目靠背八股不够，最好是从自己的项目出发。面试官让你讲项目时，会一层层追问：你数据怎么清洗的？训练时怎么设置学习率？loss曲线长什么样？线上badcase是哪些？你怎么迭代？如果都答不上来，简历写得再花哨也撑不住。

我的建议是，算法岗候选人至少完整跑通一个“数据构造-微调-评估-部署”的闭环项目。哪怕只是基于开源小模型做一个领域问答助理，也能让你在面试时讲出别人没有的细节。

5. 三个岗位的共同底座：AI编程、Agent知识与工程素养

5.1 会用AI写代码只是入门，能拆任务才是核心

2026年的工程师如果还不会用AI编程工具，在面试中会非常吃亏。但这里说的“会用”不是指装个插件看自动补全，而是利用AI做正确的事情：把复杂需求拆成小任务，让AI逐步生成代码；对AI生成的代码做代码评审；遇到bug时，把报错、日志、需求背景一起整理给AI，快速定位问题。

我工作里已经把很多重复编码任务交给AI了，比如写单元测试、生成CRUD接口、做数据清洗脚本。但核心的系统设计和架构能力，AI没法替你决定。所以面试时我不会问候选人“你用没用过Copilot”，而会问“你怎么判断AI生成的代码是否安全？怎么验证它不会引入越权和SQL注入漏洞？”这考察的是工程判断力。

平时练习时，我建议给自己设定一个规则：AI生成代码后，必须逐行review，能说清楚每一段在做什么。如果看不懂的代码，不要盲目合并。这一习惯能让你快速成长，也能在面试里讲出真实细节。

5.2 Agent/RAG/Prompt三者关系必懂

这三者是2026年AI应用里绕不开的概念，三个岗位面试都可能会问。你需要在理解各自定义的基础上，说清它们如何配合。

Prompt是与大模型沟通的“输入模板”，它决定模型的输出风格和约束。好的Prompt不只是“请回答”，还要包含角色、任务、输入、输出格式、边界约束、few-shot示例。RAG是给模型外挂知识库，解决模型不知道最新信息、容易胡编的问题。Agent是让模型具备“感知-决策-行动”的能力，能够调用工具、分解任务、循环执行。

三者的关系可以这样理解：Agent调度整个流程，RAG提供决策所需信息，Prompt控制每次调用的输入和输出质量。面试常见题：“如果让你做一个用户报障的客服Agent，你会怎么设计？”你应先声明主要用Agent做任务拆解：识别用户意图，查历史工单（RAG），调用工单系统（Tool），最终生成回答（Prompt）。如果工具调用失败，还要有兜底话术。这会让你的答案明显更有层次。

5.3 软技能与学习路径建议

除了技术，大厂面试还会关注一个候选人的表达和复盘能力。面试官喜欢听你遇到问题→思考原因→提出方案→验证效果的story。如果你只是叙述“我做了什么”，没有“为什么这样做”和“后续怎么改进”，会显得没有深度。

学习路径上，我强烈建议采用“项目驱动”的方式。前端可以做一个端侧AI文档问答；后端做一个高并发RAG服务；算法做一次领域模型微调。不要盲目追新框架，先把一条链路彻底跑通。在跑通的基础上，再横向扩展：前端去了解后端接口设计，后端去学一些模型推理细节，算法去了解工程部署，这样你就具备了大厂很看重的全栈AI意识。

6. 我的实操经验与踩坑建议

6.1 学习节奏与项目选择

如果你是从零开始转AI方向，不要试图一上来学完所有东西。我见过太多了，收藏了上百篇教程，最后连一个大模型API都没调通。建议用“最小闭环”作为第一步：花两三天，从注册大模型API开始，写一个简单的流式问答函数。然后在此基础上逐渐加RAG，加Agent，加部署，加评估。

项目选择上，切忌做一个烂大街的“聊天机器人”。你要找一个有真实使用场景、能体现你思考的项目。前端可以做一个“基于本地知识库的PDF问答助手”；后端可以做一个“针对多个知识库的检索问答API，支持混合检索和权限隔离”；算法可以做一个“面向特定领域数据的模型微调与效果对比报告”。面试时，项目不用大，但要有完整的方案、难点、做过的取舍。

我自己的经验是，项目最好的“包装”不是把过程铺开，而是提炼出亮点。比如你解决了某个模型的幻觉问题，或者把检索延迟从800ms降到200ms，或者设计了一套半自动数据标注流程，这些才是真正值钱的东西。

6.2 简历上怎么写AI项目才不虚

写简历时要避免空话。比如“熟悉大模型应用开发”就没有任何区分度。你应该写“基于LangChain搭建RAG系统，使用混合检索策略，在领域数据集上回答准确率提升15%”。这里量化数字很重要，而且数字必须来自真实的评估，不是编的。

简历上的项目描述建议包含四部分：背景与目标、个人职责、技术方案、量化结果。比如“设计某法律文书问答系统：负责文档解析与向量库构建；采用BM25+向量混合检索加RRF融合；最终在100条测试集上回答正答率达到87%，首token延迟低于800ms”。这样写，面试官一眼就知道你做了什么、做得怎么样。

如果真的没有大项目，不要虚构。面试官深挖三句就会露馅。你可以做一个小而完整的开源demo，并确保自己能够讲清楚每行代码的意图。诚实永远是最稳的策略。

6.3 最后的小技巧：把日常需求当AI用例练手

我给自己一直保留一个习惯：把每天重复的工作拆出来，想想能不能用AI自动化。比如自动整理会议纪要、自动提取简历关键信息、自动生成周报、用本地模型对自己收藏的文章做一遍摘要归档。这些日常小项目，不需要大厂业务数据，不需要服务器资源，但能让你持续积累真实的Prompt、模型选择、错误处理经验。

时间长了你会发现，自己不仅技术提升了，看待问题的角度也会变。你不再关心某个框架有多火，而是关心它能不能解决实际问题，成本和收益是否合理。这种思维习惯，才是真正能对标大厂的竞争力。