考完 HCIE 的人，是时候重新算一笔账了。
前几天刷招聘，看到一个岗位愣了两秒。
AI FDE 私有化部署工程师，深圳，3-5 年，本科，30-60K。
我把任职要求逐条看了一遍，有件事得跟兄弟们说清楚：这个岗位里一半以上的硬性要求，是网工本来就在干的活。
Linux、Nginx、防火墙策略、端口管理、网络路由、负载均衡、故障分析、驻场交付——这些词从网工简历里抠出来贴过去，毫无违和感。
真正"新"的东西只有三条：Docker/K8s、大模型推理服务了解、RAG 或智能体 PoC 实操。
所以标题那个问题，答案已经很清楚了：网工转 FDE，不是从零开始。但我必须提醒一句——大多数人会走错路。
01
PART
先把话说死：FDE 不是一个岗位，是三个岗位共用一个名字
这是这篇文章最重要的一句话，建议截图。
市面上挂着 FDE（Forward Deployed Engineer）名头的招聘，实际上分三类，三类对应三种完全不同的人：
第一类：偏应用开发的 FDE。 要求你会 Python、懂前后端、能自己搭 RAG、能写 Agent 工作流。本质是"懂业务的 AI 工程师"。这类岗位对网工最不友好，你去投简历，HR 第一眼看的是 GitHub 不是 HCIE。
第二类：偏部署集成的 FDE。 就是开头那张 JD 的类型。核心是把一套 AI 系统塞进客户内网，让它跑起来、接得上、不出事。这类是网工最该瞄准的方向，因为交付能力的 70% 你已经有了。
第三类：给网络运维本身做 AI 方案的 FDE。 比如告警分析助手、故障排查 Agent、变更检查智能体。这类岗位对网络领域知识的要求甚至比对 AI 的要求还高——因为模型给出的"某条链路有问题"，必须有人能回到实际数据里验证。这类岗位稀缺，但一旦匹配，网工的议价权极强。
看招聘别只看"FDE"三个字母，往下翻任职要求，三秒就能判断是哪一类。
02
PART
网工的真正资产，不是配置命令，是"能回到数据里验证"的判断力
这句话我想多说两句，因为它决定了你转型时怎么定位自己。
大模型现在最大的短板是什么？是它会一本正经地胡说八道，而且在网络运维场景里，胡说八道的代价是生产事故。
一个只懂 Python 和 LangChain 的 AI 工程师，让他做一个"网络故障助手"，他能把 RAG 搭起来、把 Agent 跑通，但他判断不了模型给出的答案是不是对的。他不知道那条链路的告警时间窗口应该怎么取，不知道这个设备的业务归属应该怎么对应，不知道哪些历史故障才算"相关证据"。
这些东西，你一个干了五年的网工，闭着眼睛都知道。
所以网工转 FDE，不是"从网络跨到 AI"，是让你本来就值钱的网络经验，在 AI 时代重新定价。 这个心态定下来，后面所有的学习路径都会不一样。
03
PART
三个最容易踩的坑，先说在前面
转型路上我见过太多人走弯路，三个最常见的坑，兄弟们先避开：
坑一：一上来就啃 LangChain、看 Transformer 论文。 不是说这些不重要，而是优先级错了。你是去交付的，不是去发论文的。先把 Docker、K8s、Nginx 反代、容器网络摸熟，这些是你当天就能用上的。模型原理慢慢补，不耽误上岗。
坑二：去考所谓的"AI 认证"。 目前市面上大部分 AI 认证对招聘方来说参考价值很低，远不如一个你自己做出来的、能跑起来的小 Demo。考 HCIE 的那套"刷题-过考-拿证"路径，在 AI 这边不成立。AI 领域看的是作品，不是证书。
坑三：离开网络领域去跟 AI 原生工程师卷。 你跟一个 985 CS 应届生比谁 Python 写得优雅，这是拿自己短板打别人长板。应该做的是守在网络 + AI 的交叉地带——这里 AI 工程师进不来（不懂网络），纯网工也抢不走（不懂 AI），护城河就是这么挖出来的。
04
PART
手里的证，还能用上几成？
我把常见的几本证和 FDE 任务做了个对照表，兄弟们对号入座：
| 已有证书/方向 | 能直接接上的 FDE 任务 | 还需要补的 |
|---|---|---|
| CCIE EI / HCIE-Datacom | 复杂访问路径设计、网络故障分析、给网络 AI 方案做领域判断 | Python 基础、API 调用、至少做出一个 RAG Demo |
| 红帽 RHCE / RHCA | 系统配置、服务维护、权限日志、部署自动化 | 容器编排、模型推理服务基本概念 |
| CKA | K8s 集群、服务网络、存储、故障排查——几乎可以直接上第二类 FDE 岗 | 模型服务部署（vLLM、Ollama 之类）、RAG 流水线 |
| 深信服等安全方向 | 企业接入、访问控制、安全运维 | 身份集成、数据权限模型、AI 应用交付流程 |
说一句得罪人的真话：CKA + Linux 功底扎实的人，现在去投第二类 FDE，比纯 HCIE 的人更吃香。 这是现实。
但别慌，HCIE 不是没用，它是你去冲第三类 FDE 的核心弹药——那个方向上，网络领域知识的权重远大于容器编排。
05
PART
别光想，花一个周末做一个 Demo
认知归认知，招聘方最后看的还是你能不能干活。
给个具体建议：找一个周末，用你手里的实验设备（EVE-NG、GNS3 都行），做一个"只读的网络巡检问答助手"。
要求很简单：用户输入一句话（“帮我看看核心交换机今天的 CPU 情况”），助手能够去查相关设备、返回结果、带上数据来源。
你会在这个过程中踩完所有该踩的坑：怎么把设备信息组织成模型能用的格式、怎么处理"查不到"的情况、怎么限制模型别乱说、怎么验证回答是不是对的。
做完一个这样的 Demo，比你看三个月视频课有用。 而且面试的时候直接甩链接，HR 不懂也会去问技术负责人，技术负责人一看就知道你是不是真会干。
06
PART
写在最后
岗位名称还会继续变，今天叫 FDE，明天可能叫 AI 解决方案工程师，后天可能叫别的。名字不重要，重要的是你把自己放在哪条价值链上。
网工这个群体，手里握着一张被严重低估的牌：对真实生产环境的理解力。
这张牌在纯软件时代不值钱，因为没人在乎机房里那些弯弯绕绕；但在 AI 落地时代，它突然就值钱了。所有 AI 应用最后都要落到真实环境里跑，而真实环境里 80% 的意外，都和网络、系统、权限有关。
别急着焦虑，也别急着转。先搞清楚自己想干哪一类 FDE，再决定要补什么。手里的 HCIE、CCIE、CKA 都是弹药——只是过去几年，你一直在用它打一场越来越小的仗。
现在，有一场更大的仗开始了。
AI 时代，终于轮到网工的经验被看见了。
互动一下： 聊聊你手里有什么证、现在负责什么工作、看上了哪个 FDE 岗，我挑几个典型案例拆解缺口在哪儿。
想做系统性准备的兄弟，公众号后台回复 “FDE方向”，带上你的 JD 或者目前的技术栈，我们一起核对一下 HCIE、CCIE、Linux、CKA 这些课程能覆盖到哪儿，还有哪些实践需要另外安排。
（本文岗位信息核对于 2026 年 10 月；所引招聘为具体样本，不代表整体岗位数量。）