AI 时代新岗位 FDE 前线部署工程师
月薪 7 万的 AI 岗位，第一天上班却在车间贴二维码
你好，我是程序员鱼皮。
AI 时代，有些同学觉得写代码越来越无聊了。
以前写一个接口要折腾半天，现在把需求交给 AI，接杯水的功夫，它就把代码、注释和测试都生成好了。刚开始确实很爽，但时间一长，每天做的事情越来越像机械的流水线：复制需求、等待生成、检查错误、修改提交，几乎不用动脑子。
有没有一种工作，既能继续做技术，又不用一直坐在工位上等需求？
有，而且最近两年在 AI 行业特别火，薪资也相当能打，它叫 FDE。
第一眼看到这个缩写，很多人会以为是 Frontend Developer Engineering，也就是前端开发工程师。但 FDE 的全称其实是 Forward Deployed Engineer，翻译过来叫「前线部署工程师」。
简单来说，很多企业想用 AI 提效，但连第一步该做什么都说不清楚。具体要解决什么问题、先从哪里切入、最终由谁来用，他们自己可能也没想明白。FDE 要做的，就是走进客户现场，把这些模糊的需求变成能上线、有人用的系统。
这篇文章我会用一个虚构的项目故事，带你走完 FDE 的一次完整交付过程。你会看到这份工作真实的样子，也能顺便学到几个对做 AI 应用非常有用的方法，比如怎么把模糊需求收敛成可验收的目标、怎么给 AI 建立评估集。
一、了解客户的真实目标
假设你刚入职一家 AI 公司，导师直接给你安排了第一个项目，客户是一家生产背带裤的服装厂。
项目开始前，导师带着你和销售同事一起去服装厂开会，工厂的生产负责人、维修主管、负责信息系统的同学都在场。
生产负责人说：我们想做一个 AI 报修助手，让工人报修更方便，维修记录也能保存下来。以后数据多了，最好还能预测机器什么时候会坏。
导师问：工厂现在有多少机器运行数据？
会议室突然安静下来。维修主管翻了翻手里的笔记本，有些尴尬地说：我们现在只有机器清单、纸质维修单和工作群里的聊天记录，温度、振动、运行时间这些数据，没有专门采集过。
没有这些历史数据，AI 就无法学习机器出故障前的变化规律，预测也就无从谈起。
于是导师给出了新的方案：先把报修流程理顺，让 AI 帮工人整理报修信息，同时把每次的故障描述和维修结果结构化地保存下来。这样既能解决眼前的效率问题，也能为以后做故障预测积累数据。
这一步就是 FDE 的第一项核心工作：把不切实际的需求，拉回到当前数据和条件能支撑的范围内。
客户往往会直接提出他们想要的最终效果，但作为技术方，你得判断这个效果现在能不能实现。做不到就要及时说清楚，并给出一个眼下能落地、又能为未来铺路的替代方案。
会议最后，负责信息系统的同学还补充了一个要求：报修语音和维修记录必须留在厂内服务器，新系统也不能直接改动原有的数据。
于是这次会议只确定了一个目标：先把报修流程做通，让工人报修更快、维修记录更完整。至于具体该怎么做，还得走进车间才能搞清楚。
二、进入现场调研
第二天，生产负责人安排 A 车间的吴师傅带你熟悉现场。吴师傅在这家工厂干了很多年，每天踩缝纫机比你敲键盘还熟练，机器声音稍微不对，他马上就能听出来。
你跟着吴师傅走了一遍完整的报修流程：
- 机器出问题后，工人先给班组长打电话，班组长再联系维修人员。电话本身只要十几秒，但后面要反复转述故障情况
- 维修人员到了现场，还得重新确认是哪台机器、什么时候开始出问题、具体是什么症状
- 机器修好后，工人还要补填一张报修表。有的写在纸上，有的发在工作群里，还有人忙完就直接忘了记。下次遇到类似故障，维修人员很难从这些零散的记录里找到上次的处理方法
看完流程，思路好像很清晰：工人对着手机说出问题，AI 自动整理成报修单，然后把工单推送给维修人员。等机器修好后，维修人员再通过语音或者快捷选项把处理结果记录下来。
整个流程看上去就 3 步，好像没什么难度。
然而随着和吴师傅的深入交流，你才发现事情没这么简单。
同一台机器，吴师傅叫它「三号机」，隔壁康师傅叫它「老平车」，工厂电脑里的正式名称却是「A 车间 03 号平缝机」。
如果 AI 连工人说的是哪台机器都搞不清楚，后面的一切都白搭。所以导师让你先把每台机器在工人口中的各种叫法都记录下来，搞清楚这些别名和正式编号之间的对应关系。
万万没想到，原本以为接到项目就该回去写代码，结果先站在车间里，拿本子记录机器外号。
但正是这一步，让目标发生了重要的调整。
之前在会议室里客户想的是「AI 帮工人报修」，到了现场才发现，真正的卡点是信息从工人到维修人员之间的流转：工人说不清楚是哪台机器、故障信息反复转述会丢失、修完之后记录留不下来。
所以目标被改成了：工人只需要说清楚问题，AI 负责整理工单、补全信息，并帮助维修人员查找过去的相似记录。至于机器为什么坏、应该怎么修，仍然由维修人员来判断。
这就是为什么 FDE 必须去现场。 会议室里听到的是客户以为的问题，车间里看到的才是真正的问题。
三、确定可量化的验收标准
回到会议室，导师抛出了一个问题：两周以后，我们拿什么交付才算让客户满意？
你可能会说：把 AI 报修系统开发好，部署上去就行了吧？
但「部署上去」不是验收标准。客户不关心你部署了什么，他们关心的是工人报修有没有变快、维修记录有没有留下来。双方要提前约定好具体的数字，达到了才算交付成功。
于是你们翻了过去一周的报修记录，发现维修人员平均要花 6 分多钟才能收到完整的故障信息，而且机器修好后，留下处理结果的记录还不到一半。
根据这些数据，和客户约定了 4 个验收指标：
- 报修信息要在 2 分钟内送达维修人员，不能再把工单发错车间
- 至少 90% 的维修任务要留下完整记录
- 至少 80% 的试点工人要实际使用新流程
- AI 整理关键信息的准确率需要达到 90%，系统才能进入车间试用
这套做法其实对我们自己做项目也很有启发。不管是接外包还是做自己的产品，如果目标只是「做出来」，你永远不知道什么时候算做好了。而一旦把目标变成具体的数字，方向和优先级立刻就清楚了。
标准确认后，你拉着吴师傅一起，先在安静的办公室里做了一轮测试。
吴师傅对着手机说：三号机最近一直咔咔响。
AI 一个字都没听错，但却把工单匹配到了 B 车间。原因很简单，两个车间都有一台叫「三号机」的机器。
AI 听懂了普通话，却没听懂这家工厂的「厂话」。
于是你放弃了让 AI 仅凭工人口头描述来判断机器的方案，改成在每台机器上贴二维码。这种做法在制造业其实很常见，很多工厂的设备管理系统都是靠扫码来定位机器的。工人先扫码确认是哪台机器，再描述故障。
你先和负责信息系统的同学核对好机器编号和位置，把每个二维码和对应的机器绑定之后，花了一整天在车间里一张张贴上去。
入职前你以为 FDE 的技术栈是前端、后端、数据和 AI。进厂后才发现，还得会贴二维码。
听起来有点搞笑，但这一步恰恰体现了 FDE 的价值：当模型能力搞不定某个问题时，换个工程手段绕过去，往往比死磕模型更有效。
四、建立评估集
扫码定位解决了「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 产品时，不要为了兜住少数错误，让所有用户都付出额外成本。 更好的做法是让 AI 自己识别不确定的场景，只在必要时打断用户。
改版之后，AI 只在没听清或缺少关键信息的时候才追问一句，维修人员修好机器后，也可以通过快捷选项或语音留下处理结果。
驻场试用期间，你和导师每隔两天就要向生产负责人和销售同事汇报进展。白天陪工人测试、收集反馈，晚上回去改系统、重新跑评估集。
不过协调各方比写代码费劲多了。生产负责人想尽快看到效果，负责信息系统的同学又担心新系统影响正常生产，一线工人不愿意增加操作步骤。这些不同方向的顾虑都要一件件处理清楚，系统才有机会真正用起来。
六、上线验收和交接
两周试点结束后，按照之前约定的指标逐项验收。
报修信息的送达时间从 6 分多钟缩短到了 2 分钟以内，没有再出现工单发错车间的情况，维修结果的完整记录率从不到一半提高到了 90% 以上，超过 80% 的试点工人开始使用新的报修流程。
达到验收标准后，生产负责人同意把系统推广到其他车间，销售同事也拿着验收结果，继续和客户沟通后续的合作。
但事情还没结束。系统推广到 B 车间的第二天，维修主管就打来电话。B 车间有几台特殊机型，工人描述故障时用的说法和 A 车间完全不一样，AI 又开始乱匹配了。
于是你当天赶到现场，补充了一批新的纠错规则，把失败案例加进评估集，重新跑通测试，B 车间的系统才算稳定下来。
FDE 不像普通外包交付完就撤，系统上线以后出了问题，你得第一时间赶到现场自己解决。
项目收尾的时候，导师让你把系统的配置方法和常见问题整理成文档，带着工厂负责信息系统的同学走了一遍日常维护流程。他说：FDE 不能让客户离了你就不会用，得让对方的团队自己能接手。
做完交接回到公司后，你们把这次项目里摸索出来的经验带回了产品团队，包括二维码绑定方案、车间噪音环境下的语音纠错方法、维修记录的结构化整理思路。产品经理觉得噪音环境下的语音处理能力可以做成通用模块，沉淀到产品里，让其他制造业客户也能直接用上。
七、FDE 这份工作适合你吗
走完这一整套流程，你应该能感受到 FDE 的完整工作闭环了：
- 确认客户的真实目标，把不切实际的需求拉回到当前条件能支撑的范围
- 跟着一线用户走完真实流程，找到藏在日常操作里的真正问题
- 确定方案和可量化的验收指标
- 开发系统、建立评估集，用真实数据验证效果
- 进入现场试用，根据用户反馈反复修改，直到系统真正有人用
- 把现场经验带回产品团队，让产品变得更好
不同公司的 FDE，具体工作差异挺大的。有的专注做技术交付，商务的事有专人负责；但在不少公司，FDE 还要参与售前阶段的技术评估，甚至帮客户发现新的 AI 落地场景来推动后续合作。有的 FDE 同时服务好几个客户，有的则驻在一家客户那里待上好几个月。
不过核心都一样，就是站在客户和技术之间，把模糊的问题变成能上线、有人用、能产生业务价值的系统。
这份工作并不轻松，甚至可以说很有挑战性。
OpenAI 当前的 FDE 岗位要求出差比例最高可达 50%，真实项目中可能要在客户现场待上几周甚至几个月。除了前后端和 AI 应用开发能力之外，还需要能拆解模糊问题、建立评估方法、处理企业级的系统接入和生产环境部署，更要能同时和客户的技术负责人、业务负责人以及一线员工顺畅沟通。
写在最后
如果你喜欢研究真实业务，愿意和不同行业的人打交道，也能亲手把系统做出来并看着它被用起来，做 FDE 会很有成就感。
如果你只想安静写代码，不愿意驻场出差或者处理模糊需求，FDE 可能并不适合你，踏踏实实学好 AI 编程和 AI 应用开发，同样能找到不错的方向。
不管你以后会不会做这个岗位，这篇文章里的几个方法都值得记住：先确认真实目标而不是照单接需求、把交付标准变成可量化的数字、用评估集而不是几个 demo 来验证 AI 的效果、不要为了兜住少数错误让所有用户买单。
这些能力才是 AI 时代真正稀缺的东西，因为它们恰好是 AI 现在还做不了的部分。