8 月 31 日，工信部办公厅挂出一份文件：《关于开展人工智能应用服务商培育专项行动的通知》。
文件很长，目标很硬：2026 年底，全国人工智能应用服务商资源池 2000 家；2027 年底，不少于 3000 家。
多数人扫的是这两个数字。真正值得停下来看的，是任务四里的一句话——
鼓励服务商搭建前线部署工程师（FDE）团队，扎根用户现场，保障场景落地。
FDE，Forward Deployed Engineer，前线部署工程师。一个英文缩写，原样写进了中文红头文件。这不是翻译偷懒。是这个工种在国内还没有一个公认的对应岗位。
它从哪来，干什么，和你有什么关系？这篇讲清楚。
被工信部点名的 FDE，二十年前在 Palantir 是干什么的？
先把时间拨回 2003 年。Palantir 刚成立，接的是情报机构的单子。这类客户有个共同特点：数据涉密，不能出内网；需求涉密，说不清楚。
软件公司的标准打法在这里全部失效。你没法让客户填需求文档，没法远程部署，更没法卖完 license 就走人。
Palantir 的解法很笨：把工程师派进客户现场。这些人不写 PPT，不陪吃饭。他们拎着笔记本进客户大楼，一住几周。白天陪分析师看案件数据怎么流动，晚上改代码、改数据本体，第二天早上直接给客户看改完的东西。
这批人就是 FDE。他们的工作方式后来成了 Palantir 的产品方法论：产品不是销售卖出去的，是被 FDE 在客户现场「长」出来的。Gotham 的绝大多数核心能力，最初都是某个现场的临时改动，被反复使用之后回流进了产品主线。
这个工种在 Palantir 体系内活了二十年。硅谷有个说法，Palantir 走出的创业者分两批：一批是创始人那拨，另一批就是 FDE 出身的产品型工程师——他们见过最真实的客户烂摊子，手里又有把烂摊子改好的技术能力。
一句话回答本节的问题：FDE 的起源，是「工程师」和「现场」两个词的合体。它解决的不是人力不足，是「客户在楼里、产品在公司里」的距离问题。
售前、实施、交付都在现场，FDE 凭什么单独成一个工种？
国内 toB 公司早就有人在客户现场跑。售前讲方案、写标书；实施按图施工、装系统配环境；交付盯验收、催回款。这三类岗位都在现场，凭什么 FDE 要单独算一个工种？
差别在一件事上：FDE 手里有代码权限。
这个差别带来两个可检验的指标。
第一，回款逻辑不同。传统交付的收入节点是「验收」——系统装完、文档签完、钱到账。FDE 模式的收入节点是「用起来」——客户每天真的在用，续费和扩容自然发生。前者怕客户提需求，后者靠客户需求活着。
第二，产品反哺不同。实施工程师在现场做的东西，项目结束就留在现场，成为没人维护的定制包袱。FDE 在现场改的东西，必须回答一个问题才能动手：这个改动，下一个客户用不用得上？用得上的进主线，用不上的不做——或者想清楚再做。
一句话区分：实施工程师把产品装进客户环境，FDE 把客户环境装进产品。
AI 时代，落地的活儿为什么突然变重了？
FDE 模式在 Palantir 体内循环了二十年，没怎么外溢。原因很简单：SaaS 时代不需要它。标准品软件装好就能用，交付很轻，销售驱动足够打天下。
大模型把这件事翻过来了。
根源在于，大模型是个半成品。同一个模型，接进 A 厂的质检产线和 B 行的客服系统，是两套完全不同的东西。数据要现场洗，工作流要现场改，评测集要现场建——客户老师傅凭手感判废的标准，得有人翻译成机器能评测的用例。提示词和工具调用链，也得贴着真实业务调。
这些活儿，远程干不了，标准品干不了，纯销售更干不了。「最后一公里」从工程问题变成了产品问题。这恰好是 FDE 的射程。
市场的信号已经很直白。OpenAI 组建了面向企业客户的 FDE 团队，Anthropic 用 Applied AI 的序列干同样的事，一批 AI 原生公司把「驻场工程师」写进招聘启事的第一行。前沿实验室集体把工程师往前线推——模型越强，通用 demo 越漂亮，落地那截脏活越集中爆发。
FDE 的身份也跟着变了。在软件公司里，交付岗位历来是成本中心，是收入的附属品。在 AI 公司里，FDE 变成了收入引擎本身：客户为「跑起来的场景」付钱，不为「装好的模型」付钱。
工信部的专项行动，给这个工种画了一条多粗的政策线？
看清了市场侧的逻辑，再回头看 414 号文，就能读出它真正在干什么。
目标：2026 年底服务商资源池 2000 家；2027 年底不少于 3000 家
任务四原文：鼓励服务商搭建前线部署工程师（FDE）团队，扎根用户现场，保障场景落地
配套：算力券 · FDE 实训基地 · 「小快轻准」产品包 · Token 采购与首购首用风险补偿
这份文件的完整逻辑是一条链：先建资源池，把服务商找出来；再组「人工智能应用服务团」，每地区不少于 10 个，1 家牵头加至少 2 家上下游；然后用算力券降成本、用实训基地补人才、用首购首用兜风险。FDE 落在链条的最后一环——场景落地。
政策没有发明 FDE。这个词在 Palantir 和硅谷的 AI 公司里已经存在了很多年。政策做的是另一件事：给需求侧一个可计算的保证。未来两年，资源池里的 3000 家服务商，每一家都被鼓励养一支 FDE 团队。按一家团队 5 到 10 人粗算，这是一万五到三万个岗位的量级。
岗位需求第一次从招聘启事，变成了部委文件里的指标。这是这条政策线的真正粗细。
一个 FDE 的一天在做什么，需要哪几块能力？
抽象定义说到这，看一个具体的场景。
某服务商的 FDE 驻场一家汽车零部件厂，任务是把质检环节的视觉模型跑顺。
这一天里他干了四种活：看工况、改代码、做翻译、做取舍。对应的正是 FDE 的四块能力。
薪酬水位也跟着这个能力组合走。硅谷的 FDE 总包普遍高过同资历的纯后端工程师——因为他同时对签单和续费负责。国内招聘市场上，AI 交付和驻场算法类岗位的报价，也开始压过同资历的传统实施工程师一档。逻辑一样：离钱近的工程师，从来都比离代码近的工程师贵。
谁适合转 FDE，谁转了会后悔？
最后落到最实际的问题：这个风口，该不该追？
适合的人画像很清晰。技术底座扎实、又不想离业务太远的工程师——写代码的瘾还在，但对着屏幕改一天的满足感，已经不如看客户把东西用起来。干过售前但真的会写代码的，也算。还有一种：在客户现场待得住的人。别人嫌机房吵、嫌工厂偏，你能蹲得住。
只想写纯代码、把需求文档当圣经的，不要转——FDE 的需求是客户在产线上随口说的，没有文档。
只想做客户关系、不愿碰代码的，也不要转——那是售前的路，不是 FDE 的路。这个工种两头都要，缺一端就不是它。
还有一个具体的坑要防。项目制公司会挂 FDE 的头衔，干实施的活。辨别方法只有一个，面试时问一句：我在现场改的代码，进不进产品主线？回答含糊的，就是传统交付换了个时髦名字。
FDE 走红，不是因为这个头衔好听。是因为 AI 终于要从 demo 走进生产线了。生产线不认 PPT，只认能不能跑。
政策把这条线画出来了，市场把价格标出来了。剩下的问题是：你站在线的哪一边。