1. 这个“日程记录”背后：华为AI岗到底招什么人
1.1 一条日历提醒的三层信息
如果翻到2026年3月14日那一格日历，上面只写了“华为AI岗”五个字，估计你也会像我当时一样，在手机备忘录里写满了各种待确认的问题：这是终面还是HR面？要不要重新做性格测评？base地有没有得选？其实这一行短短的记录，拆开来看至少有三层信息，值得每一位准备投大厂AI岗的应届朋友提前琢磨清楚。
第一层是“2026年”。按校招节奏，2026届的秋招提前批通常在2025年6月启动，到了2026年3月，剩下的主要是补录批和春招批。如果你在这个时间点还在面试流程里，说明前面至少熬过了简历筛选、机考、两到三轮技术面，也可能是在等排序结果。3月14号这个日子并不特殊，但对个人来说，它往往意味着一个“能不能上岸”的关键节点。
第二层是“华为”。华为的AI岗位和其他互联网大厂不太一样，招聘系统里可能同时出现“AI算法工程师”“AI平台开发工程师”“AI应用开发工程师”等不同title，但很多候选人在投递时根本分不清这些岗位的差异，甚至有人拿到offer之后才意识到自己干的是模型训练还是推理优化，是纯业务算法还是偏向云服务开发。
第三层是“AI岗”本身。这是今天最值得展开的关键词。2026年前后，各大厂对AI岗的定义已经明显分叉，有人做大模型预训练和微调，有人做Agent应用和RAG，有人做模型部署和推理加速，还有人做数据工程和评测体系。如果你只抱着“AI岗”三个字去准备，很容易在技术面里被问穿。
1.2 华为AI岗的几类实际工作方向
以我自己的观察和面试经验，华为目前招聘的AI岗可以粗略分成四个方向，虽然招聘页面上岗位名称可能相似，但面试考察侧重点完全不同：
| 岗位方向 | 工作内容 | 面试考察重点 | 更适合谁 |
|---|---|---|---|
| AI研究岗 | 大模型预训练、多模态、AI for Science | 论文复现、算法推导、最新模型原理 | 有顶会论文或重点实验室背景的硕博 |
| AI算法/应用岗 | RAG、Agent、业务场景建模、提示词工程 | 项目深挖、结构化表达、评估体系 | 做过完整应用项目的硕士/本科生 |
| AI平台/部署岗 | 推理加速、模型量化、训练框架、资源调度 | 系统底层、CUDA/算子、vLLM/Triton | 工程能力强的候选人 |
| AI产品/项目管理岗 | 产品定义、场景挖掘、交付管理 | 行业理解、方案设计、沟通协作 | 有产品意识的技术候选人 |
我在投递时选了第二类，也就是AI算法/应用方向。原因是我的背景比较偏向“把开源大模型接进业务系统”，做过的项目包括企业内部知识库问答、Agent自动报表生成、以及一个基于LoRA微调的分类模型。这个背景去投研究岗肯定不够，投纯平台岗又差一点系统知识，反而是应用岗的匹配度最高。
如果你是2026届甚至2027届的同学，我建议投递前先花一个晚上，把这四个方向的岗位JD分别打开，逐条对比自己做过的事情有没有直接对应。别小看这一步，面试时候讲的每一个词，简历上写的每一个项目，都是在替你做定位。
1.3 投递前先搞明白的“用工形式”
这里要插一个很多论坛里都不愿意直说、但真实存在的坑：华为的AI岗招聘里，有正式员工编制，也有大量OD岗位。OD从法律意义上是外包，但办公地点、项目内容甚至部分面试流程都和正编岗位混在一起，招聘平台上看起来就是个普通AI岗。
我不是说OD一定不能去，而是强调你要在投递时主动确认。我自己在筛招聘信息时看到过不少标着“华为AI岗”的职位，点进去之后才在某个角落看到“外企德科”“OD”字样。OD岗位过去几年帮助很多背景一般但技术扎实的同学拿到了大厂项目经验，转正通道也确实存在，但过程会伴随考核、答辩和HC限制，心理预期必须先建立起来。
所以“2026-华为-03月14号AI岗”这一条记录，背后第一件事不是刷题，而是先确认：这到底是一个什么用工形式的岗位？面试流程是正编的5轮还是OD的3轮？如果连这个都没搞清楚，后面所有准备都可能跑偏。
2. 从投简历到机考：先迈过第一道硬门槛
2.1 简历筛选：项目经历要写成“工程实践”，而不是课设报告
华为的简历筛选相对不那么玄学，本硕学历、论文/比赛、实习经历、项目经历，这几个维度占了大头。但根据我的观察，不少人挂在初筛上的原因不是学历，而是项目经历写得太像课程设计报告。
什么叫课设报告写法？通篇都是“本文研究了某某模型，提升了准确率3个点”，看起来有结论，但面试官根本看不到“你自己做了什么”。一个合格的AI工程实践项目，至少要说明这几个问题：场景和输入数据是什么？你做了哪些数据清洗和样本构建？模型怎么选、为什么选？评估指标为什么用这个不用那个？服务是怎么封装上线的？上线之后有没有出过badcase、怎么修复的？
我在简历里写了三个项目：一个是基于RAG的部门技术文档问答系统，一个是大模型驱动的Agent自动报表助手，还有一个是7B模型的LoRA微调与INT8量化部署。每个项目下面我只保留了3到4条bullet，但每条都会落到具体动作和数字上。比如RAG项目里写的是“通过调整chunk_size从128到512，召回率@5从68%提升到83%，首token延迟控制在1.2秒以内”，而不是简单写一句“提升了检索效果”。
这种写法的好处是，面试官在十几秒的筛选中就能判断出你做过真正的工程实践，而不是只调过API。更重要的是，后面技术面的深挖环节，你会有足够多的细节可以讲。
2.2 机考算法题：难度在LeetCode中等及以上，别只刷高频题
华为的AI岗机考一般在牛客或者他们自己的考试平台上进行，支持C++、Java、Python等主流语言，题目数量通常是三道算法题加若干选择题，总分固定，但每道题分值不一样。难度中枢大约在LeetCode中等水平，偶尔会出现一道接近Hard的。
很多同学准备机考时特别喜欢看“华为机考高频题单”，然后只刷那几十道。我一开始也是这样，后来发现光靠高频题并不够，因为机考更喜欢出组合型的题目：一道题同时考贪心和二分，一道题同时考图遍历和条件分支。你背得再熟，换个壳就容易卡住。
我实际遇到的第二题就是一个二分答案的变形：给定一批货物的重量数组和一个天数限制，要求在限定天数内把所有货物运完，问最小载重是多少。这道题的核心是先对载重做二分，再用贪心判断当前载重能不能在限定天数内完成任务。类似思路在LeetCode 1011这类题里出现过，但机考会在输入输出上增加一些干扰条件，比如货物顺序不能变、天数可能大于货物数量等。
我当时的解法大致是这个结构：
def can_ship(weights, capacity, days): cur = 0 need = 1 for w in weights: if cur + w > capacity: need += 1 cur = w else: cur += w if need > days: return False return True def min_capacity(weights, days): left, right = max(weights), sum(weights) while left < right: mid = (left + right) // 2 if can_ship(weights, mid, days): right = mid else: left = mid + 1 return left这类题考察的不是你会不会背二分模板，而是能不能快速判断“可行性函数怎么定义”。我建议机考准备阶段把高频题按“思想”而不是按“题号”归类：二分答案一个文件夹、动态规划一个文件夹、图遍历一个文件夹，每个文件夹里放5到8道变体题，反复训练“把新题归到已知思想里”的能力。
2.3 在线测评里的大模型基础题
算法题之外，华为AI岗的机考环节通常还会混入一批选择题，范围包括机器学习基础、深度学习基础和大模型基础。2026年这个时间点上，Transformer相关的题目几乎是必考的，比如self-attention为什么除以根号d_k、positional encoding怎么加、KV Cache在解码阶段是怎么复用的。还有一些题目会考训练相关的概念，比如LoRA的低秩矩阵加在哪些层、梯度累积怎么影响有效batch size、混合精度训练里fp16和bf16的区别。
我印象很深的一道题是：“一个7B参数模型，如果用fp16精度做推理，仅模型权重大约需要多少显存？”答案就是大约14GB，因为7B乘以每个参数2字节。这道题看着简单，但很多人没算过，直接在14和28之间犹豫。类似的题还包括“bf16有几个指数位和尾数位”“int8量化后KV Cache显存大约降为原来的几分之一”。这类问题不需要背资料，动手部署过一次模型、跑过一次nvidia-smi，基本就记住了。
机考这段经历给我的最大感受是：算法题决定你能不能进下一轮，而大模型基础题决定面试官一开始怎么看你的水平。如果选择题答得稀烂，就算算法题AC了，后面面试也会被当成“刷题型选手”，需要花更多轮次证明自己真懂AI。
3. 技术面现场：Transformer、Agent、RAG一个都没少
3.1 一面：手推attention，还要会算显存
一面通常是技术面，时长约60分钟，前20分钟是自我介绍和项目简述，中间30分钟是手写代码和数学推导，最后10分钟是反问。我遇到的第一轮面试官来自AI应用团队，整个面试节奏非常紧凑。
自我介绍之后，他直接在共享文档里甩了一道手写题：用PyTorch实现一个简化版本的multi-head attention前向过程，不需要考虑mask，但要把head数、embedding维度和缩放因子交代清楚。我写的时候大致是这个结构：
import torch import torch.nn.functional as F def attention(Q, K, V, num_heads): batch_size, seq_len, d_model = Q.shape head_dim = d_model // num_heads def split_heads(x): x = x.view(batch_size, seq_len, num_heads, head_dim) return x.transpose(1, 2) # [batch, heads, seq, head_dim] Qh, Kh, Vh = split_heads(Q), split_heads(K), split_heads(V) scores = Qh @ Kh.transpose(-2, -1) / (head_dim ** 0.5) weights = F.softmax(scores, dim=-1) output = weights @ Vh output = output.transpose(1, 2).contiguous().view(batch_size, seq_len, d_model) return output写完后面试官没有让我继续补多头输出拼接的反向传播，而是追问了一个更实际的问题：推理阶段KV Cache能省多少计算？如果输入长度是1024，又要额外占多少显存？
这个问题需要临时估算。以一个7B模型为例，通常有32层、40个KV头、每个头的维度是128，如果kv cache用fp16存储，每生成一个token需要缓存的自变量数量是：2（K和V）乘以层数乘以KV头数乘以head维度。套数字就是2乘32乘40乘128，等于327680个fp16数值，大约0.65MB。生成1024个token就是大约655MB，这还只是单请求的额外开销。如果把batch size放大到8，显存占用直接翻到5GB以上。面试官要的其实不是精确值，而是看你有没有“算账”的意识。
这一面之后我最大的感受是：光会调用transformer库远远不够，你至少要能在白板上把attention的计算流程画出来，并且理解KV Cache为什么只出现在解码阶段。这些知识只要真正跑过一次模型推理服务，很容易就理解了。
3.2 二面：项目深挖，最怕“假做过”
二面更像一次项目答辩，时长约45分钟，全程围绕你简历上的一个核心项目展开。面试官不会泛泛地让你介绍项目，而是像做代码审查一样不断往下钻细节。我讲的是那个RAG问答系统，于是他先问了数据构建：文档是怎么解析的？PDF里的表格怎么处理？切分chunk时按什么策略？
这里我犯了一个小错误：我把chunk_size基本凭记忆报成了256，但当被追问“为什么选256而不是512”时，我明显卡了一下。后来面试官看出我的尴尬，退一步换了个角度问：你做过对比实验吗？有没有数据支撑这个选择？
实际上我在项目里做过实验，chunk_size从128到512之间，256确实在召回率和回答质量上更均衡，但当时我并没有把实验结果量化到可以脱口而出的程度。所以这个问题的教训就是：项目里的每个关键数字，都要能讲出它是怎么来的。一个真正的工程师不会拍脑袋定参数，他会记录实验过程并保留对比数据。
紧接着面试官把问题引向了RAG幻觉。他问：“如果检索到的文档内容本身是对的，但模型生成的答案里加了一句文档里没有的信息，你怎么处理？”我当时的方案是从三个方向下手：第一是生成时限制模型只能基于给定的context作答；第二是在prompt里强制输出引用来源；第三是在后处理阶段做规则校验，如果检测到关键实体不在context里就给用户提示“当前文档不支持该结论”。面试官对后两个方案比较认可，还追问了引用来源是用正则抽取还是让模型结构化输出。
这段对话让我意识到，2026年的AI岗面试已经不只是问“你会不会用LangChain”，而是会拆解到“生成结果如何可控”“失败情况如何兜底”这些工程问题。你如果没有真正处理过badcase，很难在这种追问下稳住。
后面聊到Agent时，面试官对工具调用和成本特别感兴趣。他问了一个非常实操的问题：“一个Agent任务如果平均要调用3次大模型接口，一次回答要消耗多少Credits？”这里需要说明一下，Credits在AI语境里通常指调用模型API的配额或费用单位，很多平台上1个Credits对应固定的输入输出token量或图片处理量。我当时算了一笔账：假设一个任务涉及系统提示词500个token、用户输入2000个token、每轮工具结果回填500个token，三轮调用下来，输入token累积每次4000，输出token每次600，合计净消耗大约13800个token。按当时一个中等模型每百万token约10美元的价格折算，单任务大约0.14美元，一天10万次调用就是1.4万美元。如果不做缓存、不降级模型，这个成本是完全扛不住的。
这个话题很加分，因为大多数候选人只关心模型效果，很少有人认真算过成本。面试官明确说“做AI应用的人必须会算Credits账”，这让我确信备一面时顺手了解API计费方式是值得的。
3.3 三面：AI工程实践和部署，决定你能走多远
三面更像主管面或者综合面，技术深度反而比重不比二面低，但它跳出了单个项目的细节，开始考察你对“模型上线这条路”的整体理解。我记得面试官问了这么一句话：“如果你的模型想要在业务里上线，手头只有一台8卡A800的机器，用户要求首token延迟不超过500毫秒，你会怎么做？”
这个问题有很多层次。我当时的回答分了三步：第一步选择推理框架，直接上vLLM，利用它的PagedAttention和continuous batching提高吞吐；第二步做模型量化，先把权重从bf16压到INT8，精度损失用离线评测集验证，如果评测指标降幅超过阈值就退回bf16；第三步是服务封装，用OpenAI兼容接口，再加上前缀缓存和动态批处理。如果单卡还是跑不满性能，再按模型并行切分到多卡。
这个过程中面试官补了几个细节问题：vLLM的PagedAttention到底在解决什么问题？continuous batching和传统静态batching有什么区别？量化用的是PTQ还是QAT？我虽然没有每个问题都答得完美，但至少把“显存碎片和预留显存浪费”这个点讲清楚了。传统推理框架需要在请求前预留一个最大长度对应的KV Cache空间，导致显存浪费严重，PagedAttention把KV Cache分成固定大小的块，像操作系统的虚拟内存一样按需分配，这就是它能大幅提升吞吐的本质原因。
部署命令层面的实操经验也在这一面变得很有用。我自己当时在项目里启动服务的命令大致长这样：
python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --quantization awq面试官没有要求我背框架参数，但他看到我能把gpu-memory-utilization、max-model-len这些参数和显存分配逻辑对应上，就知道我是真的部署过，而不是只看了几篇博客。
三面结束时他问了一个题外话：“你平时跟得上大模型的迭代速度吗？最近发布的新模型你了解多少？”我说我每周会固定看模型release notes，小模型比如7B、14B级别的会尽量本地跑一遍评测，大模型则关注官方技术报告和GPT4级别模型的思路变化。这个习惯让三面变成了相对轻松的交流，而不是严格的拷问。
4. 面试官真正想看的底层能力
4.1 算账能力：AI岗不是纯研究岗，要会算成本收益
经历过这一整套面试，我最大的感悟是：AI岗面试官在判断候选人时，除了技术深度，最看重的是“能不能把账算清”。这个“账”可能是显存账、推理延迟账、API成本账，也可能是项目投入产出比。
举一个真实的后续场景：我在另一个项目的Agent方案评审里，和同事争论该不该给每个复杂问题都加一个“多Agent总结”的环节。单纯从效果上说，多Agent能提升答案条理性，但如果看Credits消耗，至少比单次调用贵出2到3倍。后来我拉了一个小表格做对比：单Agent首token延迟200ms，成本0.02美元一次；多Agent延迟800ms，成本0.07美元一次，而人工评测的胜率只提升了约8%。最终结论是只在用户明显需要长文档总结时才启用多Agent，其余情况一律走轻量路径。
这个案例在面试时讲出来，效果远好于单纯说“我熟悉某框架”，因为它展现了候选人的工程判断力。现在的AI岗，尤其是华为这类偏实业和交付的公司，不会养一个“只需要跑通模型”的人，他们更希望你能对GPU资源、API预算、上线时间点、灰度策略都有通盘考虑。
4.2 AI编程与提示词：会用工具，但必须能解释每一行
另一个面试里反复出现的话题是AI编程。2026年，如果你还在简历里写“熟练使用AI编程工具”，基本等于没写，因为这已经是开发者默认能力。面试官更关心的是：你用AI写出来的代码，自己是否真的能看懂、能改、能解释。
我在项目里确实大量使用Cursor辅助写代码，比如数据清洗脚本、API封装、单元测试。但在机考和手写环节，我绝对不会依赖生成。原因很直白：AI生成代码看起来能用，一旦面试官追问某个角落的逻辑，你没看透就会瞬间穿帮。我当时给同事的建议是，AI编程的正确用法不是“让AI替我写”，而是“让AI替我起草，我来review”。每段生成代码都要过一遍，至少做到能说出每个函数做了什么、边界条件在哪里、复杂度是多少。
提示词工程也是类似逻辑。很多人把提示词当成一个文本技巧，但真正有价值的提示词是结构化的：先给角色，再给任务背景，然后给输入格式和输出格式，最后给限制条件。这些内容其实和系统设计一样，本质是在定义接口契约。面试时如果你能现场把一个模糊需求拆成结构化的提示词，并且解释每一步为什么存在，已经算是一个很加分的技能点。
4.3 跟进大模型迭代：怎么证明你一直在场上
三面主管面结束后我又复盘了一遍，发现面试官反复在问的其实还有另一个问题：你凭什么说你跟得上这个行业？AI领域的技术迭代在2025年到2026年依然非常快，模型架构、训练方法、推理优化、Agent框架，每隔几个月就有一轮新的热点。面试官不会指望你把每篇论文都读完，但他们希望你有一个持续跟踪和验证的机制。
我的机制非常简单粗暴：每周固定做三件事。第一，关注开源模型的发布动态，重点看7B到32B级别的小模型，能本地跑的都本地跑一遍，用一套统一的评测prompt记录效果变化；第二，拆一个开源项目的核心模块，比如读vLLM的调度器源码或者某个Agent框架的tool调用链路，不追求全懂，但一定要弄明白一个完整调用闭环；第三，随手记技术笔记，把自己的实验结论和踩坑点写进个人知识库，作为长期积累。
这套方法没有多高级，但它的好处是让我在面试里聊“最近在看什么”时有真实素材。我记得面试官问我对当前Agent开发框架怎么看，我提起自己在用现成框架时踩过memory管理的坑，他马上追问“你最后怎么设计的memory结构”，这说明面试官更看重的是你有没有真正深入过某个环节，而不是停留在看新闻的层面。
5. 复盘与避坑：那些Offer之外更值钱的教训
5.1 我踩过的三个坑，记录在这里供你避雷
这段复盘我犹豫了很久要不要写，因为确实有些丢人，但如果能帮你少踩一次坑，那就值得写。
第一个坑是简历里堆效果数字，但没有提前准备好“这些数字是怎么算出来的”。我在简历里写“模型推理性能提升40%”，可是当面试官追问“怎么测的、和什么基线比、机器配置是什么”时，我拿出一套基于同一批数据的复现报告。虽然数字是真的，但表达得很散，给面试官的印象分打了折扣。后来我学乖了，简历里每个数字旁边提前写好一句话解释，比如“40%是首token延迟从1.9秒降到1.1秒，基于A10单卡、vLLM框架测得”，这样无论从哪里被问，都能准确命中。
第二个坑是机考时没提前熟悉考试平台的输入输出模板。很多平台自带的main函数读入模板和LeetCode不太一样，需要自己处理多行输入、多组测试用例。我第一场模拟练习时在标准输入解析上浪费了将近二十分钟，完全打乱了节奏。后来我总结出一个笨办法：平时刷题故意不用可视化模板，而是用命令行标准输入输出跑一遍自定义用例，逼自己习惯考试环境的写法。
第三个坑是项目里的关键参数没有形成“实验对比”的叙事。前面提到chunk_size=256这个数字，就是典型的拍脑袋痕迹。正确做法是在简历和面试前准备一张小表格，列出chunk_size分别取128、256、512时的召回率、回答准确率、耗时，即使最终线上用的就是256，也要让面试官看到你经过了对比，而不是猜了一个数字。
这三个坑其实都属于同一个根源：项目做到位了，却没有做好“能被追问”的工程记录。面试和评审一样，不是在考察你过去的成绩，而是在考察你能不能把过去的决策逻辑讲清楚。那些“为什么”说得越流畅，面试官对你的信任度就越高。
5.2 面试后我如何处理“被问住”的问题
3月14号面试结束后，我当天晚上做了一件很重要的事：把面试复盘写成一张表，左边是我被问住或答得不够好的问题，右边是对应的补强计划。后来我发现这个表比面试本身更值钱。
比如面试中我对“模型并行时all-reduce的通信开销怎么估算”答得比较模糊，我的补强计划是去读DeepSpeed和Megatron的文档，再本地用两台机器跑一次张量并行实验，记下实际通信时间和计算时间。再比如我对“RLHF或DPO在项目里怎么落地”没有太多经验，之前只停留在理论层面，我的补强计划是拿一个开源偏好数据集做一次小规模DPO微调，把整个训练、评测流程走通。
如果你现在也正在准备AI岗面试，我强烈建议你也做一张类似的表。不要只盯着“我拿到了多少分”，而要盯着“哪些知识缺口暴露出来了”。面试是最好的学习诊断工具，这比任何网课和面经都更个性化。
5.3 给下一届投递者的一句话建议
要我说，如果只能给一条建议，那就是：把所有精力“向内修行”，做真项目、留真记录、讲真过程，而不是背面经、刷AI味答案。我见过太多人一上来就找所谓“最新面经汇总”，把答案背得滚瓜烂熟，结果面试官换个角度追问，立刻就露馅。面试官尤其是华为的技术面试官，普遍经验丰富，对背题型回答极度敏感。
我自己在2026年3月14号这一天之后，把“AI岗”三个字的理解刷新了一遍：它不是一个终点，不是一个上岸后就可以躺着吃老本的岗位。AI技术迭代那么快，今天你会部署vLLM，明天可能就有新的推理引擎要学；你今天会在RAG里做chunk调优，明天可能就要做多模态文档问答。整个岗位更像一个持续学习和工程交付的长期训练场。
如果你也想投2027年的华为AI岗，现在就开始动手做一个能回答“我到底在这条路上做过什么”的项目，把每个参数、每个故障、每次调优都记成一篇可以讲清楚细节的小结。等你真的走到面试官对面，你会发现真正让你安心的，不是背诵过的面经，而是那一个个真实踩过、修过的坑。
