FDE究竟每天在做什么？我拆解了北上广深34份真实JD

本文根据 Kelly 陈霈霖对北上广深 60 个 FDE 招聘链接的研究整理。研究最终纳入 34 份可完整读取的职位描述；职责百分比是 JD 文本提及率，不代表员工实际工时。以下保留研究者第一人称叙述。

34 份真实 JD 却显示：94% 先找业务问题，91% 还要亲手开发

从模糊业务问题到可验收结果的 FDE 工作路径

如果只看名字，我也会以为，FDE 就是负责把模型装进服务器的工程师。

毕竟它的英文全称是 Forward Deployed Engineer，国内有人翻译成“前沿部署工程师”，也有人叫“前线部署工程师”。

“部署”两个字听起来很技术：装环境、配机器、接接口、处理故障。

但我把 BOSS 直聘上北上广深的 60 个 FDE 招聘链接逐个打开，最后筛出 34 份还能完整读取的职位描述以后，发现完全不是这么回事。

这个人上午可能在客户公司追问业务流程，中午把一句含糊的要求拆成任务，下午开始搭 Agent、接数据、改代码，临近上线又要做测试、培训和验收。项目做完以后，他还不能立刻离场，还要看客户到底有没有用、结果有没有变、这套做法能不能复制到下一个场景。

如果你是老板，为什么会想把这么多事情放在同一个岗位里？

FDE 究竟是工程师、产品经理、实施顾问，还是售前？

它每天到底在做什么？你做 AI 落地时，又到底需不需要这样一个人？

这 34 份 JD，给出了一个比岗位名称更有意思的答案。

第一层揭秘：FDE最常做的，居然不是部署

先看这次研究里出现频率最高的职责。

34 份 FDE 职位描述中的职责提及率

我把这张表来回看了几遍，最扎眼的不是某个技术词，而是三个很朴素的动作：找问题、动手做、把结果交出去。

94% 的岗位要求 FDE 先理解业务需求，91% 要求本人能够搭建或修改方案，88% 要求负责上线交付。

但你再往下看，明确写到系统集成的只有 53%。

换句话说，FDE 并不等于传统意义上的“部署工程师”。有些岗位确实要处理私有化、接口、权限和运行环境；但更多公司先要的是一个能走进业务、把模糊问题变成可运行应用的人。

如果你已经买了工具、做了培训，甚至跑过几个 Demo，业务却还是没什么变化，你大概率也碰到了这个问题。

AI 成果公式：场景选择、责任人和验收标准

我把它叫作AI 落地断层：老板知道 AI 重要，员工也开始使用工具，但从想法到业务结果之间，没有一条完整的责任链。

我一直用一个很简单的式子理解这件事：

AI 成果 = 场景选择 × 责任人 × 验收标准

所以，很多企业不是缺少会使用 AI 的工程师。

恰恰相反：他们缺的是一个愿意从问题出发、亲手做完、再用结果证明的人。

如果你是老板，可以拿这个式子问团队三个问题。

我们选的，真的是现在最值得解决的场景吗？

有没有一个人，愿意从头跟到尾？

做完以后，谁能说清楚它到底有没有用？

场景选错，做得再快也没有价值。

场景选对，没有人从头跟到尾，项目会死在交接里。

有人负责，但没有验收标准，最后就只剩下一场看起来不错的演示。

FDE 这个角色，就是在填这条断掉的责任链。

第二层揭秘：FDE根本没有“标准的一天”

如果你问一个普通岗位每天做什么，通常能得到相对稳定的答案。

但 FDE 的一天，会随着项目阶段完全改变。

这次研究没有记录员工的真实考勤，所以我不想硬画一张精确到小时的时间表，看起来很科学，实际上全靠猜。

更接近事实的说法是：FDE 通常会经历三种完全不同的工作日。

FDE 在三个项目阶段中的工作日

第一种：客户调研日

上午，他可能和业务负责人开会，但不是坐在那里听一句“我们想做一个智能客服”。

他要继续追问：

• 客户每天在重复回答哪些问题？
• 答案现在存在哪里？
• 哪些问题允许 AI 直接回答，哪些必须转给人工？
• 答错一次的业务后果是什么？
• 谁来判断第一版能不能投入使用？

问完以后，他还要跟着一线员工走一遍真实流程，检查文档、表格、聊天记录、系统权限和数据口径。

一天下来，看起来代码没写多少，真正重要的东西却出来了：问题到底是什么、现在怎么做、为什么值得改、第一步做到哪里为止。

如果问题都没选对，后面做得越快，浪费得也越快。这一天其实在决定公式里的第一项：场景选择。

第二种：原型构建日

需求收敛以后，FDE 要立刻把讨论变成可以操作的东西。

可能是一个能回答企业资料的知识助手，也可能是一条自动整理销售线索的工作流，或者是把几个已有系统串起来的小应用。

这时会出现 Agent、RAG、API 这些技术词。

用人话解释：Agent 是能按目标执行一串任务的 AI；RAG 是让 AI 先查企业自己的资料再回答；API 是让不同软件互相传递数据的接口。

FDE 不一定要从零训练一个大模型，但他不能只会聊概念。他得把已有模型、企业数据、业务规则和软件系统拼起来，先做出一个真的能用的东西。

他还要主动拿失败样本测试，而不是只挑最好看的例子演示。

做到这里，事情才算真正有人接住。这一天对应的是公式里的第二项：有没有一个真正负责的人。

第三种：上线验收日

到了上线前，工作又变了。

账号权限有没有开对？真实数据能不能读到？异常时会不会泄露不该出现的信息？旧系统出问题时能不能回退？一线员工知不知道怎么用？

这些问题不能靠一段提示词解决。

FDE 要和客户的业务、技术、数据、安全团队一起联调，准备培训，处理问题，整理操作文档，再让指定的人确认结果。

如果项目有夜间发布、故障值守或驻场要求，也往往发生在这个阶段。是否需要响应、怎样轮值、有什么补偿，必须在入职或合作前讲清楚，不能把高压日描述成每一天，也不能假设所有 FDE 都没有上线压力。

忙到这里，事情还没结束。最后还得有人说清楚：这东西到底能不能用，谁敢签字让它上线。

这就是公式里的第三项：验收标准。

所以，FDE 的日常不是每天平均分配一点开会、一点写代码、一点实施。

项目在哪个阶段，他就站在结果最容易断掉的地方。

第三层揭秘：同样叫FDE，为什么像四份不同的工作？

我原本想从 34 份 JD 里找一个统一答案。结果越往下看，越发现“FDE”这三个字下面，装着的可能是四份不同的工作。

至少存在四种明显不同的 FDE。

四种常见 FDE 岗位类型

1. 商业化／售前型

这类 FDE 经常和销售、渠道一起见客户，快速判断高价值场景，再搭一个 Demo 或 POC。

POC 就是概念验证：先做出一个小而真的版本，证明方向可行，再决定是否投入更大的实施成本。

这类岗位真正关心的是：商机能不能往前走，客户愿不愿意买，成功的方案能不能拿去服务下一个客户。

风险也很明显：如果成交以后就交给别人，自己不再对上线负责，它很容易变成换了名字的演示售前。

2. AI应用构建型

这类岗位大量使用 Agent、知识库、工作流和 AI 编程工具，把一个业务流程快速做成应用。

它不一定要求你研究多深的底层算法，但你得能写、能改、能调试，最后拿出一个业务人员真的可以操作的东西。

风险是只会调几段提示词，Demo 看起来聪明，真实数据一变就失效。

3. 集成交付型

这类 FDE 更接近很多人想象中的“部署”：接 API、开权限、处理数据、配置私有环境、联调、测试、上线和排障。

对这类岗位来说，把软件装好只是开头。系统能稳定运行，客户敢签收，才算交代得过去。

风险是项目越来越重，最后变成传统实施团队，只顾着赶工期，没有把客户现场的问题带回产品。

4. 行业解决方案型

医疗、制造、金融、教育、零售等行业，都有大量藏在流程和经验里的知识。

这类 FDE 未必是技术最深的人，但要能快速听懂行业语言，再把它翻译成数据、权限、规则和应用。

风险是只懂行业不会实现，或者只懂技术听不懂现场，两边都说得很热闹，最后没有人能把事情做成。

这四种岗位没有谁更“正宗”。如果你正在招人，真正要讲清楚的是：他主要面对什么问题，责任到哪里结束，背后还有谁和他一起干。

否则，一个人可能以为自己应聘的是 AI 工程师，入职以后却发现主要任务是陪销售见客户；也可能以为自己做轻量应用，最后一年大部分时间都在客户现场处理集成问题。

如果你在招人，怎样判断是不是真的FDE？

我一般不先看岗位名称，而是问三个很直接的问题。

判断 FDE 完整责任链的三个问题

第一，他会不会去真实业务现场？

不是拿到一份已经写好的需求，而是接触业务人员、流程、数据和限制，判断问题是否真实、是否值得做。

第二，他会不会亲手把东西做出来？

不是只写 PPT，也不是只把问题转发给研发，而是能搭原型、改代码、配工作流、接数据，至少把关键链路跑起来。

第三，他会不会陪到上线以后？

不是演示结束就离场，而是继续处理测试、采用、风险、验收和复盘。

这三个问题只要有一个回答是否定的，岗位性质就可能已经变了：

• 只负责服务器和推理性能，更像模型部署或基础设施工程师；
• 只负责方案和演示，更像解决方案售前；
• 只负责配置、培训和按期上线，更像传统实施；
• 只负责采用率和续约，更像客户成功。

这些岗位都很重要，只是不能因为名字里放了 FDE，就默认工作内容相同。

FDE不是一个时髦称呼，而是一条完整责任链。

你可能会问：这不就是把五个人的活塞给一个人吗？

老实说，有些 JD 确实写得像一张许愿单。

既要懂业务，又要会写代码；既要陪销售见客户，又要负责上线；最好还能培训、做项目管理、总结方法。

但把玩笑放一边，这种岗位会出现，也有很现实的原因。

传统软件项目习惯分工。

销售听客户的问题，售前写方案，产品经理整理需求，研发排期开发，实施负责上线，客户成功再看使用情况。

当问题清楚、产品成熟、需求变化慢时，这种分工可以运行。

但 AI 应用刚好相反。

客户一开始往往说不清真正的问题。模型能不能回答，只能拿真实资料测试。工作流是否可用，要让一线员工操作以后才知道。权限、成本、速度和错误边界，也必须在运行过程中不断校准。

如果每发现一个问题，都要沿着五六个岗位传一圈，反馈还没回来，需求已经变了。

我自己做过工程师、CTO 和 PMO，最近也以 CAIO Lead 和 FDE 的角色进入过其他企业。CAIO 就是 Chief AI Officer，首席 AI 官，负责帮企业梳理 AI 流程、选场景、推动跨部门协作；FDE 继续往下，把具体场景做出来、接进系统并完成验收。

这些位置都站过以后，我最深的感受是：一个问题只要在几个角色之间多传两次，最后做出来的往往就不是最初要解决的东西。

FDE 的作用不是取消分工，而是缩短反馈回路。

他把客户现场的事实直接带进构建过程，再把运行中的失败直接带回产品和工程团队。

这也是为什么很多 JD 同时要求沟通、业务理解、代码、交付和复盘。当然，不排除有些公司是真的想用一个编制解决五个人的问题。但一个成熟的 FDE 设计，找的应该是能减少交接损耗的人，而不是一个包办一切的超人。

当然，这种设计也有代价。

如果公司没有给 FDE 明确的范围、优先级和否决权，他就会迅速变成一个万能接口：销售承诺什么，他就补什么；客户临时想到什么，他就做什么；研发不愿处理的问题，也全部丢到现场。

最后，人很忙，客户很多，真正可复制的东西却没有留下。

好的FDE缩短反馈，坏的组织只会压缩一个人。

这份工作真正难在哪？

不是代码写不出来，而是身边每个人都可能往他身上加一点需求。

34 份 JD 里反复出现的压力，主要来自六个地方。

需求会不断变大

客户看到第一版以后，很自然会继续加功能。如果没有明确的范围和优先级，POC 很快就会变成没有终点的定制项目。

演示成功，生产失败

演示用的数据通常比较干净。进入真实系统以后，权限不一致、字段缺失、接口不稳定、历史资料冲突都会一起出现。

销售承诺超过边界

为了赢得项目，前期可能把模型效果、上线时间或集成难度说得过满。真正到了现场，FDE 要面对这些承诺留下的落差。

做完一次，无法复制

每个客户都从零开始，意味着团队永远只能靠堆人扩张。成熟的 FDE 必须把共性沉淀成模板、组件、测试集、操作步骤和产品需求。

上线以后，没人使用

系统能运行，不等于业务已经改变。用户是否采用、人工是否愿意接管、业务指标是否变化，都需要明确的负责人继续观察。

一个人承担了整个小队

行业知识、全栈开发、售前表达、项目管理、培训、客户关系，任何一项都可以单独成为一个岗位。

我甚至在 JD 里看到“会开车”也成了加分项，因为驻场时可能要往返客户现场。

有些岗位写到最后，真的像在招一支队伍，只是编制只有一个。

成熟公司会让 FDE 作为小队的责任接口，背后仍有产品、研发、数据、安全和客户成功支持。把所有缺口都压给一个人，不叫敏捷，只叫岗位失控。

如果你是老板，怎么判断这个项目真的做完了？

“Agent 已经搭好了”不算完成。

“客户看过 Demo 了”也不算完成。

最简单的判断不是“技术团队说做完了”，而是业务人员真的用过，而且知道正常时怎么用、出错时找谁、最后谁愿意签收。

一个边界清楚的项目，至少应该达到这样的标准：在约定的真实样本和运行环境中完成核心任务；通过双方事先确认的测试；异常情况有人工接管路径；指定业务负责人完成验收；客户团队能够按文档继续使用。

同时，FDE 应该交出一份可以复核的证据包：

• 原来的问题是什么；
• 根因和限制是什么；
• 修改或搭建了什么；
• 用什么样本和方法验证；
• 有哪些截图、录屏或运行记录；
• 还存在什么风险；
• 最后由谁签收、谁授权上线。

AI 可以负责生成、检查、测试和整理证据，但是否符合业务要求、风险是否可以接受、能不能进入生产环境，必须由有权限的人决定。

我也不会在没有调研之前承诺固定效率倍数、固定裁员比例，或者直接把整套旧系统全部重写。场景、数据、接口、团队能力和风险不同，先建立基线，再谈目标。

拒绝这些听起来漂亮的承诺，不是保守，而是对交付负责。

如果你真想把FDE用起来，前30天做什么？

第一周，先别急着搭 Agent。

FDE 落地项目的前 30 天路径

先选一条真实流程，找业务负责人和一线使用者访谈，画出现状流程、系统、数据、权限和风险。最后只留下一个值得优先解决的问题。

第二周，把边界定下来。

明确输入是什么、输出是什么、哪些情况不做、使用什么测试样本、谁负责验收。能拿到的数据和接口现在就确认，不把关键依赖留到上线前。

第三周，拿真东西跑一次。

做一个能够被真实用户操作的版本，用正常样本、异常样本和边界样本测试。问题要被记录，结果要能复现，不用一场精心准备的演示代替验证。

第四周，看证据，再作决定。

完成培训、验收、证据整理和风险复盘。然后决定继续扩大、调整方向，还是停止投入。

前 30 天的目标不是证明 AI 什么都能做。

而是让企业第一次看清：一个真实问题怎样被选择、怎样被做成、怎样被验收，以及哪些能力值得留下。

你该自己招FDE，还是先找外部团队？

如果你已经有稳定的 AI 产品，也有大量持续出现的客户场景，而且能够给 FDE 配产品、研发、数据和交付支持，那就应该认真考虑建立内部团队。

因为现场经验需要长期反哺产品，不能永远留在外部服务商手里。

但如果你连第一个场景是什么都还说不清楚，先招一个“全能 FDE”，多半只是让新人替整个公司承受混乱。

这时更需要的可能是 CAIO Office：先从经营目标确定优先级、负责人和验收方式，再决定哪些场景值得实施。

如果场景已经很明确，只是缺 Agent、数据、系统集成和上线能力，那就适合先做一个边界清楚的 FDE 落地项目。先把第一个闭环跑通，再判断要不要组建长期团队。

CAIO 与 FDE 的责任分工

CAIO 负责决定为什么做、先做什么、怎样组织。

FDE 负责进入现场，解决怎样实现、怎样证明、怎样移交。

这两种能力可以由内部人员承担，也可以在早期由外部角色进入。

所以别先纠结头衔。

你先问：这件事从问题到结果，到底有没有人真正接住？

结语：别先问他会什么，先问他负责到哪里

拆完这 34 份 JD，我最大的感受不是 FDE 要会很多。

而是企业正在重新寻找一种久违的责任感：看见问题的人，也参与解决；做出结果的人，也面对使用者；完成交付的人，也留下下一次可以复用的东西。

FDE不只是部署系统，而是部署结果。

Demo交给会议，结果要交给业务。

别先问他会什么，先问他负责到哪里。

如果你正在招聘 FDE，或者准备启动一个 AI 落地项目，不妨先把三件事写下来：你最想改变哪一条真实流程，现在由谁负责，以及拿什么证明它真的变好了。

这三个问题有答案，你需要什么样的人、要不要自己组建团队，通常也就清楚了一半。

---

研究说明：本次研究于 2026 年 9 月 14 日进行。研究者逐个核验北上广深各 15 个明确包含 FDE 的招聘链接，共 60 个。