月薪 7 万的 FDE 工程师，都要做什么？

你好，我是小阿巴。

AI 时代，我觉得写代码越来越无聊了。。。

以前写一个接口要折腾半天，现在把需求交给 AI，我接杯水的功夫，它就把代码、注释和测试都生成好了。

刚开始确实很爽，但时间一长，我每天做的事情越来越像机械的流水线，复制需求、等待生成、检查错误、修改提交，几乎不用动脑子。

于是我进入了幻想时刻：有没有一种工作，既能继续做技术，又不用一直坐在工位上等需求？

正在这时，我刷到了一条月薪 10 万的招聘信息：DeepSeex 公司正在招聘 FDE。

FDE？

第一眼看到这个缩写，我还以为它是 Frontend Developer Engineering，也就是前端开发工程师。

我还在疑惑：月薪 10 万的前端？前端什么时候复兴了？

点开招聘详情一看，完全不是那么回事。

FDE 的全称是 Forward Deployed Engineer，翻译过来叫「前线部署工程师」，是最近两年在 AI 行业特别火的一个岗位。

简单来说，很多企业想用 AI 提效，但连第一步该做什么都说不清楚，具体要解决什么问题、先从哪里切入、最终由谁来用，他们自己可能也没想明白。FDE 要做的，就是走进客户现场，把这些模糊的需求变成能上线、有人用的系统。

诶，有点儿意思？这不正是我想尝试的工作么？

于是我随手投递了简历，没想到才 2 天，就被 DeepSeex 这家 AI 公司录取了！

不过看我没有 FDE 工作经验，刚开始只给我开 7 万月薪。

没关系，我已经很满足了。

于是果断关停了自己的公司「鱼鸢网络」，第二天就前往新公司报道。

我的导师叫「奶龙·码撕客」，是一名练习时长两年半的资深 FDE。

入职当天，他也没跟我多寒暄，直接给我安排了第一个项目，客户是一家生产背带裤的服装厂。

了解客户目标

项目开始前，码撕客先带我和销售同事一起去服装厂开会，服装厂的生产负责人、维修主管、负责信息系统的同学都在场。

生产负责人说：我们想做一个 AI 报修助手，让工人报修更方便，维修记录也能保存下来。以后数据多了，最好还能预测机器什么时候会坏。

码撕客问：工厂现在有多少机器运行数据？

会议室突然安静下来。。

维修主管翻了翻手里的笔记本，有些尴尬地说：我们现在只有机器清单、纸质维修单和工作群里的聊天记录，温度、振动、运行时间这些数据，没有专门采集过。

没有这些历史数据，AI 就无法学习机器出故障前的变化规律，预测也就无从谈起。

码撕客想了想说：那我们先把报修流程理顺，让 AI 帮工人整理报修信息，同时把每次的故障描述和维修结果结构化地保存下来。这样既能解决眼前的效率问题，也能为以后做故障预测积累数据。

生产负责人同意了这个安排。然后负责信息系统的同学补充了一个要求：报修语音和维修记录必须留在厂内服务器，新系统也不能直接改动原有的数据。

这次会议上，大家对预测维护的想法先放到了一边，我们只确定了一个目标：先把报修流程做通，让工人报修更快、维修记录更完整。

但是具体该怎么做，还是得走进车间才能搞清楚。

进入现场调研

第二天，生产负责人安排 A 车间的吴师傅带我熟悉现场。吴师傅在这家工厂干了很多年，每天踩缝纫机比我敲键盘还熟练，机器声音稍微不对，他马上就能听出来。

我先跟着吴师傅走了一遍完整的报修流程。

1. 机器出问题后，工人先给班组长打电话，班组长再联系维修人员。电话本身只要十几秒，但后面要反复转述故障情况。

2. 维修人员到了现场，还得重新确认是哪台机器、什么时候开始出问题、具体是什么症状。

3. 机器修好后，工人还要补填一张报修表。有的写在纸上，有的发在工作群里，还有人忙完就直接忘了记。下次遇到类似故障，维修人员很难从这些零散的记录里找到上次的处理方法。

好家伙，烂摊子真多啊！

不过鸡智的我很快有了思路：工人对着手机说出问题，AI 自动整理成报修单，然后把工单推送给维修人员。等机器修好后，维修人员再通过语音或者快捷选项把处理结果记录下来。

整个流程看上去就 3 步，我甚至觉得这个项目没什么难度。

小小 FDE，不过如此~

然而随着和吴师傅的深入交流，我才发现事情没这么简单。。。

同一台机器，吴师傅叫它「三号机」，康师傅叫它「老平车」，工厂电脑里的正式名称却是「A 车间 03 号平缝机」。

如果 AI 连工人说的是哪台机器都搞不清楚，后面的一切都白搭。所以码撕客让我先把每台机器在工人口中的各种叫法都记录下来，搞清楚这些别名和正式编号之间的对应关系。

万万没想到，我原本以为接到项目就该回去写代码，结果先站在背带裤车间里，拿本子记录机器外号。

说实话，这时候我心里已经有点犯嘀咕了：FDE 不是技术岗吗，怎么我成打杂的了？别人的入职培训是看文档，我的入职培训是背机器外号？？？

走完流程、记录完机器的外号之后，我们重新梳理了目标。之前在会议室里客户想的是「AI 帮工人报修」，但到了现场才发现，真正的卡点是信息从工人到维修人员之间的流转：工人说不清楚是哪台机器、故障信息反复转述会丢失、修完之后记录留不下来。

所以我们把目标调整为：工人只需要说清楚问题，AI 负责整理工单、补全信息，并帮助维修人员查找过去的相似记录。至于机器为什么坏、应该怎么修，仍然由维修人员来判断。

确定方案和验收标准

回到会议室，码撕客抛出了一个问题：两周以后，我们拿什么交付才算让客户满意？

我挠挠头说：把 AI 报修系统开发好，部署上去就行了吧？

码撕客摇了摇头：「部署上去」不是验收标准。客户不关心你部署了什么，他们关心的是工人报修有没有变快、维修记录有没有留下来。双方要提前约定好具体的数字，达到了才算交付成功。

于是我们翻了过去一周的报修记录，发现维修人员平均要花 6 分多钟才能收到完整的故障信息，而且机器修好后，留下处理结果的记录还不到一半。

根据这些数据，我们和客户约定了 4 个验收指标：

• 报修信息要在 2 分钟内送达维修人员，不能再把工单发错车间

• 至少 90% 的维修任务要留下完整记录

• 至少 80% 的试点工人要实际使用新流程

• 此外，AI 整理关键信息的准确率需要达到 90%，系统才能进入车间试用。

标准确认后，我拉着吴师傅一起，先在安静的办公室里做了一轮测试。

吴师傅对着手机说：三号机最近一直咔咔响。

虽然 AI 一个字都没听错，但是却把工单匹配到了 B 车间。

分析后发现，原因很简单，两个车间都有一台叫「三号机」的机器。

头疼啊，AI 听懂了普通话，却没听懂这家工厂的「厂话」！

于是，我放弃了让 AI 仅凭工人的口头描述来判断机器的方案，改成在每台机器上贴二维码。这种做法在制造业其实很常见，很多工厂的设备管理系统都是靠扫码来定位机器的。工人先扫码确认是哪台机器，再描述故障。

我先和负责信息系统的同学核对好机器编号和位置，把每个二维码和对应的机器绑定之后，花了一整天在车间里一张张贴上去。

入职前，我以为 FDE 的技术栈是前端、后端、数据和 AI。

进厂后才发现，我特么还得会贴二维码？？？

再多干几天，我觉得自己的简历里都可以加上一条：贴纸端正、无气泡、手速嘎嘎快。

建立评估集

扫码定位解决了「AI 搞不清是哪台机器」这个问题之后，我觉得最大的障碍已经扫清了。

码撕客却不这么认为。他说：吴师傅说一句话，AI 碰巧答对了，这只能算跑通了一个 demo。想要真正达到交付标准，得拿几百条真实报修记录来测，看整体准确率够不够。

这种测试在 AI 行业里一般叫 Evals，可以理解成给 AI 准备一套固定的考题。每次调整提示词、模型或处理逻辑后，都用同一批案例重新跑一遍，看准确率有没有提高。

Evals 是 FDE 做 AI 项目时至关重要的一环。客户验收的时候不会只看你演示一两个案例，而是要看几百条真实数据跑出来的准确率到底是多少。

搞清楚了这一点，我们就开始动手准备测试数据。我和工厂的维修主管翻出了一摞过去一年的纸质报修单，不少纸张已经发黄，上面还沾着机油。工作群里的记录也很随意，有人写「针断了」，有人写「断针」，还有人只留下一句「跟上次一样」。

我们花了两天时间，才从这些材料里整理出了 300 条真实案例。

不出所料，第一轮测试很快就翻车了。

办公室里能听清的话，到了车间可就不一定了。几百台缝纫机同时运转，背景噪音很大，AI 经常把「断线」听成「断电」，把「跳针」听成「掉针」。

结果 300 条测试跑完，只有 81% 的关键信息被正确提取出来，离原定 90% 的验收标准还差不少。

而且过去的维修记录也不好检索，同一种故障在不同工人口中有好几种说法，AI 搜不到真正相关的历史记录。

针对这些问题，我们做了几轮针对性的优化：先在语音识别环节增加降噪处理。然后补充了一套车间常用说法的纠错词典（比如把「断电」在设备上下文里自动纠正为「断线」），再把纸质维修单和群聊记录重新整理入库，统一术语。

重新跑完整套测试之后，准确率从 81% 提升到了 93%，达到了验收标准。

当然，这套评估集也不是用一次就扔掉的。系统真正上线以后，新出现的失败案例会持续补充进去，作为下一轮优化的依据。

现场试用和修改

评估集跑通之后，系统进入了 A 车间试用。

结果，又翻车了。。。

虽然整体准确率已经到了 93%，但毕竟还有 7% 的情况 AI 会搞错。我不太放心，就在界面上加了一个确认表格，让工人说完问题后，还要逐项检查 AI 填好的机器名称、问题类型和发生时间，确认没问题再提交。

吴师傅在页面上滑了两屏之后问我：我本来打个电话十几秒就好，用你这玩意儿还要看很久表格？

我有点心虚，客户原本想减少工人报修和填表的时间，我却因为怕 AI 出错，给工人多加了一堆要确认的选项。

码撕客了解情况后，开始撕我码了。

他说，93% 的准确率已经超过验收标准了，为了防那 7% 的错误，你让 100% 的工人每次都多操作一整页表格，这笔账算不过来。不如让 AI 自己判断什么时候没把握，遇到拿不准的才追问一句，大多数情况直接提交就行。

我觉得有道理，就按他说的进行了改版。AI 只在没听清或缺少关键信息的时候才追问一句，不再让工人每次都检查一遍。维修人员修好机器后，也可以通过快捷选项或语音留下处理结果。

驻场试用期间，每隔两天我和码撕客都会向生产负责人和销售同事汇报进展。我白天陪工人测试、收集反馈，晚上回去改系统、重新跑评估集，忙得够呛。

不过协调各方比写代码费劲多了。生产负责人想尽快看到效果，负责信息系统的同学又担心新系统影响正常生产，一线工人又不愿意增加操作步骤。这些不同方向的顾虑都要一件件处理清楚，系统才有机会真正用起来。

上线验收

两周试点结束后，我们按照之前约定的指标逐项验收。

报修信息的送达时间从 6 分多钟缩短到了 2 分钟以内，没有再出现工单发错车间的情况，维修结果的完整记录率从不到一半提高到了 90% 以上，超过 80% 的试点工人开始使用新的报修流程。

达到验收标准后，生产负责人同意把系统推广到其他车间。销售同事也拿着验收结果，继续和客户沟通后续的合作。

系统推广到 B 车间的第二天，维修主管就给我打了电话。B 车间有几台特殊机型，工人描述故障时用的说法和 A 车间完全不一样，AI 又开始乱匹配了……

于是我不得不当天赶到现场，补充了一批新的纠错规则，把失败案例加进评估集，重新跑通测试，B 车间的系统才算稳定下来。

太折磨了。。。

FDE 不像普通外包交付完就撤，系统上线以后出了问题，你得第一时间赶到现场自己解决。

项目收尾的时候，码撕客让我把系统的配置方法和常见问题整理成文档，带着工厂负责信息系统的同学走了一遍日常维护流程。

他说：FDE 不能让客户离了你就不会用，得让对方的团队自己能接手，不然以后找你的事情多了去了。

做完交接后，终于回到了公司，我们把这次项目里摸索出来的经验带回了产品团队，包括二维码绑定方案、车间噪音环境下的语音纠错方法、维修记录的结构化整理思路。产品经理觉得噪音环境下的语音处理能力可以做成通用模块，沉淀到产品里，让其他制造业客户也能直接用上。

我的感受

做完这个项目之后，我才真正理解了 FDE 这份工作。

之前觉得不就是去客户那里写代码嘛？实际做下来才发现比想象中复杂太多了。

FDE 要先确认客户的真实目标，把不切实际的需求拉回到当前数据和条件能支撑的范围内。再跟着一线用户走完真实流程，找到藏在日常操作里的真正问题。然后确定方案和可量化的验收指标，开发系统、建立评估集、进入现场试用。根据用户反馈反复修改，直到系统真正跑起来、有人用。最后把现场经验带回产品团队，让产品变得更好。

FDE 完整工作闭环六步

不同公司的 FDE，具体工作差异挺大的。有的专注做技术交付，商务的事有专人负责。但在不少公司，FDE 还要参与售前阶段的技术评估，甚至帮客户发现新的 AI 落地场景来推动后续合作。有的 FDE 同时服务好几个客户，有的则驻在一家客户那里待上好几个月，不过核心都一样，就是站在客户和技术之间，把模糊的问题变成能上线、有人用、能产生业务价值的系统。

我觉得这份工作并不轻松，甚至可以说是很有挑战性的。

OpenAI 当前的 FDE 岗位要求出差比例最高可达 50%，真实项目中可能要在客户现场待上几周甚至几个月。除了前后端和 AI 应用开发能力之外，还需要能拆解模糊问题、建立评估方法、处理企业级的系统接入和生产环境部署，更要能同时和客户的技术负责人、业务负责人以及一线员工顺畅沟通。

如果你喜欢研究真实业务，愿意和不同行业的人打交道，也能亲手把系统做出来并看着它被用起来，做这份工作会很有成就感。如果你只想安静写代码，不愿意驻场出差或者处理模糊需求，FDE 可能并不适合你，踏踏实实学好 AI 编程和 AI 应用开发，同样能找到不错的方向。

OK 就分享到这里，如果你也想学习 AI 编程或者 AI 应用开发，可以看看我免费开源的 和 。

鱼皮的 AI 编程教程

我是鱼皮，持续分享 AI 编程干货，觉得有用的话记得点赞收藏和关注。

你身边有做 FDE 的朋友吗？或者你自己有没有类似的驻场经历？欢迎在评论区分享一下感受。