我找了份月薪 7 万的 FDE 工作，结果进厂贴了一天二维码？！

你好，我是小阿巴。

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

原先编写一个接口得持续折腾好长一阵子, 如今把需求投递给予 AI, 在我去接一杯水的这段时间, 它已将代码、注释以及测试全都生成完毕了。

起初的时候, 真的是感觉颇为畅快, 然而当时间持续推移, 长久之后, 我每日所从事的那些事情, 愈发变得如同机械运转那样似流水线一般, 先是复制需求, 接着等待生成, 随后检查错误, 最后修改提交, 差不多完全无需动用脑子去思考。

于是, 我步入了幻想时段, 是不是存在着这样一种工作, 它能够持续去做技术方面的事情, 然而却不需要始终坐在工位之上等待需求浮现?

在这个时间点, 我看到了一条给出月薪十万的招聘消息, 该公司正在招募FDE！

FDE？

刚一看到这个缩写的时候, 我竟然以为它是, 也就是进行前端开发工作的工程师。

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

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

「前线部署工程师 」翻成英文是 FDE, 这是最近两年在 AI 行业特别火的一个岗位。

简言之, 不少企业企图借助AI实现效率提升, 然而对于第一步该如何开展却全然说不清晰, 究竟要去解决哪些问题, 首先应从何处着手切入, 最终又会由谁来使用, 就连他们自身或许都并未思考透彻。FDE所要达成的, 便是深入到客户所处现场, 将这些含混不清的需求转化为能够上线运行、有人实际使用的系统。

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

于是, 我随意地投出了简历, 没料到仅仅过了两天时间, 便被这般的一家人工智能公司录用了！

然而察看我不存在 FDE 工作方面的经验, 最初仅仅给我开出 7 万月薪的薪资待遇。

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

所以, 毅然决然地把自己的公司「鱼鸢网络」给关停了, 在第二天的时候, 就去到新公司去报到了。

那位被称作「奶龙·码撕客」的, 即我的导师, 乃一名有着两年半练习时长的资深 FDE。

迎来入职的那一日, 他并未与我作过多的寒暄交流, 而是径直给我布置安排了首个项目任务, 此项目所涉及的客户乃是一家专门从事背带裤生产加工的服装厂单位。

了解客户目标

处于项目起始之前的阶段, 码撕客率先引领着我以及身为销售岗位的同事, 一同去往服装厂参与会议, 彼时, 服装厂的负责生产的负责人, 还有承担维修工作的主管, 以及负责信息系统相关事务的同学, 均在现场。

负责生产的人员声称, 我们打算打造一个借助人工智能的报修辅助工具, 以此使得工人进行保修的时候更加便利, 并且维修的记录能够留存下来。往后当数据增多的时候, 最好能够对机器何时将会出现故障作出预测。

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

会议室突然安静下来。。

翻了翻手中笔记本的维修主管, 有些尴尬地讲道: 我们目前有的是机器清单, 还有纸质维修单以及工作群里的聊天记录, 但是温度、振动、运行时间这些数据, 未曾专门采集过。

要是没有这般历史数据, 那AI便不能够去学习机器在出现故障之前的变化规律, 如此一来预测就此全然没有可能, 无从而谈起了。

码撕客思索片刻后讲道: 那我们首先要将报修流程梳理顺畅, 让人工智能助力工人去对报修信息予以整理, 与此同时把每次的故障描述以及维修结果结构化地进行保存。此种做法既能够处理当下的效率难题, 又能够为往后开展故障预测积攒数据。

作出同意这一安排行为的生产负责人, 之后负责信息系统的同学做了补充, 提出这样一个要求, 即报修语音以及维修记录都得留存在厂内服务器, 并且新系统也不可以直接对原有的数据进行改动。

在此次会议期间, 把大家针对预测维护所持的想法暂且搁置一旁了, 最后我们仅仅明确了一项目标, 那就是首先要达成报修流程的畅通, 具体表现为让工人们在报修时速度能够更快, 而维修记录也会更加完整。

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

进入现场调研

隔天, 生产负责人把 A 车间的吴师傅安排好, 让其带着我去熟悉现场。吴师傅在这家工厂工作了好些年, 他每日踩踏缝纫机的熟练程度, 要比我敲击键盘更为厉害, 只要机器发出的声音稍有不对劲, 他立马就能够听出来。

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

机器出现问题之后, 工人先是打了电话给班组长, 而后班组长又去联系维修人员。电话本身仅仅只要十几秒, 然而后续却需要反复地去转述故障的情况。

维修人员抵达了现场, 还需要再次去确认究竟是哪一台机器, 是在何时开始出现问题的, 具体呈现的是什么样的症状。

在机器被修好之后, 工人需要去补填一张报修表, 它们有的是写在纸张上面的, 有的是发送在工作群当中的, 另外还有人在忙完事情之后就直接忘记去记录了, 在下次碰到类似故障的状况下, 维修人员很难从这些零散的记录里面寻找到上次的处理办法。

好家伙，烂摊子真多啊！

然而具备鸡智的我迅速想出了办法: 工人正向手机说出问题, AI 自动将其整理成报修单, 接着把工单推送至维修人员处。待机器修复后, 维修人员再凭借语音或者快捷选项把处理结果记录下来。

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

小小 FDE，不过如此~

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

同一台机器, 吴师傅称呼它为「三号机」, 康师傅称呼这件东西为「老平车」, 工厂电脑里所标记的正式名称是「A车间03号平缝机」, 是这样的情况。

假使AI根本弄不明白工人所讲的究竟是哪一台机器, 那后续的所有事情都将毫无意义。故而码撕客要求我先得把每一台机器在工人嘴里的各式各样的叫法都详细地记录下来, 且要弄明白这些别名跟正式编号之间的那种对应关系。

绝对没料到, 我本来想着, 一旦接到项目就应当回去编写代码, 然而事实却是, 首先站在了背带裤车间当中, 手里拿着本子去记录机器的外号。

讲真, 在这个时候, 我的心里已然略微涌起了一些疑虑, FDE 难道不该是技术岗位吗, 为何我却沦为做杂事的了, 其他人参与入职培训是去查看文档, 而我的入职培训却是要去背诵机器的外号, 真是奇怪至极！

我们走完流程, 记录完机器的外号后, 重新梳理了目标。之前在会议室, 客户所想的是「AI帮工人报修」, 等到了现场才发觉, 真正的卡点在于信息从工人那里朝维修人员之间的流转: 工人无法清晰表述是哪台机器, 故障信息经过反复转述会有所丢失, 修完之后也没法留下记录。

于是乎, 我们将目标予以调整, 调整为这般: 工人仅需把问题讲明白, AI专门负责去整理工单, 并且补全相关信息, 还要助力维修人员查找过往的相似记录。而对于机器坏掉的缘由以及应当怎样去修理, 依旧是由维修人员来进行判断。

确定方案和验收标准

返回到会议室, 码撕客抛出了一个问题, 两周往后, 我们凭借什么交付才能够达成让客户感到满意呢?

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

码撕客晃了晃脑袋, 表明“部署上去”并非验收的标准, 客户在意的并非你所部署的内容, 而是工人报修是否变快, 以及维修记录是否留存下来, 双方需提前约定好具体的数字, 只有达到该数字, 才算交付成功。

所以, 我们翻动检视了过去一周递呈上来的报修记录, 发觉维修相关工作人员平均需耗用 6 分多钟方可接收到完整无缺的故障具体信息, 并且在机器被修复之后, 将处理最终结果予以留下记录的情况尚不足一半。

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

经过标准确认, 我拽着吴师傅一块儿, 先是在安静的办公室当中, 进行了一回测试。

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

虽说 AI 没听错任何一个字, 然而却将工单匹配到了 B 车间。

进行分析之后发觉, 缘由是非常简单的, 存在着两个车间, 这之间均配备有一台被称作「三号机」的机器。

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

于是, 我摒弃了让AI仅仅依据工人的口头讲述去评判机器的方案, 进行了更改，变为在每一台机器之上粘贴二维码。这般的做法在制造业之中实际是颇为常见的, 许多工厂的设备管理系统皆是依靠扫描二维码来确定机器的位置的。工人先是扫描二维码以确认是哪一台机器, 随后再去描述故障情况。

先由我, 与负责信息系统的同学核对机器编号以及位置, 之后一个个将二维码与对应的机器进行绑定, 最后耗费一整天时间, 在车间里一张张把它们张贴上去。

在入职之前, 我原本所认为的是, FDE 的技术栈涵盖着前端方面要素, 还有后端相关内容, 更蕴含数据部分以及 AI 领域。

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

再多去干上几天, 我感觉自身的简历之中都能够添加上一条, 那便是贴纸摆放得端正, 不存在气泡, 具备简直快到不可思议好似嘎嘎作响般的手速。

建立评估集

去扫描那个码从而进行定位, 在解决了「AI 弄不明白到底是哪一台机器」这个问题以后, 我感觉最大的阻碍已经被清除掉了。

玛斯柯却持有别样看法, 他讲, 吴师傅表述一番话语, 人工智能恰巧正确应答, 这般仅仅算是成功运行了一个演示示例, 要切实达成交付的标准要求, 需要取用几百条实际的报修记录去开展测试, 查看整体的准确程度是否达标。

在AI行业当中, 有一种测试通常被称作Evals, 它能够被理解为是为AI准备了一套固定的考题。每当对提示词、模型或者处理逻辑做出调整之后, 都会让同一批案例再次进行运行, 接着查看准确率是否有所提高。

在FDE开展AI项目期间, Evals属于极为关键的一个环节。于客户进行验收之际, 并非仅仅观看你所演示的一两个案例, 而是着重查看经由几百条真实数据运作得出的准确率究竟是多少。

明白知悉了这一要点以后, 我们便着手开启动手预备测试数据事宜。由得我以及隶属于工厂的维修主管, 一道翻找出了一叠过往一年的纸质报修单, 好多纸张已然呈现出发黄的状态, 并且上面隐约还沾附有机油。于工作群里所留存的记录也是随性任意的, 其中有的人写下「针断了」, 有的人写下「断针」, 另外还有人仅仅留下了一句「跟上次表现情形同样」。

经历了两天之久的时间, 我们方才从那些材料当中, 整理得出了 300 条真实的案例。

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

在办公室里能清晰听到的话语, 到了车间情况就不一样了。车间里几百台缝纫机一同运转, 背景产生的噪音很大, AI常常会将「断线」听成「断电」, 还会把「跳针」听成「掉针」。

最终, 300条测试全部跑完, 然而, 仅有81%的关键信息被准确无误地提取出来, 距离原本预定的90%的验收标准, 还差了许多。

还有, 以往的维修记录检索起来不太容易, 同样的故障, 不同工人的描述存在好几种说法, AI没办法找到真正与之相关的历史记录。

我们针对这些问题做了几轮具有针对性的优化, 先是在语音识别环节增添了降噪处理, 接着补充了一套车间常用说法的纠错词典, 像把设备上下文里的「断电」自动纠正成「断线」这样, 随后又将纸质维修单以及群聊记录重新进行整理并归入数据库, 以此统一术语了。

再度去跑完全那整套测试, 之后, 准确率由百分之八十一提升为百分之九十三, 达成了验收标准。

当然, 这套评估集并非使用一回便丢弃, 系统切实上线之后, 新涌现的失败案例会持续予以补充, 以此作为下一轮优化的凭据。

现场试用和修改

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

结果，又翻车了。。。

尽管整体准确比率已然达到了百分之九十三, 然而终究仍存在百分之七的情形, 人工智能会出现差错。我心里不太踏实, 于是就在界面上面添加了一个确认表格, 使得工人讲完问题之后, 还得逐一详细检查人工智能填好的机器名称, 以及问题类型, 还有发生时间, 确定没有问题之后再去提交。

吴师傅于页面之上滑动了两屏以后, 向我发问的情况便是, 原本打一通电话十几秒便能够完成的事情, 使用这东西竟然还需要花费很长时间去查看表格。

我心里有点发虚, 客户本来是想着把工人报修以及填表所花费的时间给减少掉, 然而我呢, 却是由于害怕AI出现差错，就给工人增添了数目众多的需要去确认的选项。

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

他讲, 百分之九十三的准确率已然超出验收标准范围了, 为了防范那百分之七的错误情况出现, 你要求百分之百的工人每次都额外去操作整整一页表格, 这样的账可不是很好计算清楚的, 倒不如让人工智能自行去判断什么时刻是没有十足把握的, 碰到犹豫不决拿不准情况时方才追问一下, 在大多数情形下直接提交便可以了。

我觉着挺有道理, 于是就依照他讲的那样开展了改版工作。AI, 仅仅是在没能听清楚或者欠缺关键信息之际才追问那么一句, 不再使得工人每次都去检查一番。维修人员把机器修好之后, 同样能够借助快捷选项或者语音留存下处理结果。

驻场试用那段时间, 每间隔两天, 我跟码撕客, 二者都会给生产负责人以及销售同事去汇报进展情况。我于白天的时候, 陪着工人做测试, 还要收集相应反馈, 到了晚上返回去修改系统, 再重新去跑评估集, 忙得不可开交、疲惫不堪。

然而相互协调各个方面, 可比编写代码要麻烦得多了。生产方面的负责人, 期望能够尽快目睹到成效, 而负责信息系统的那些同学, 却担忧全新的系统会对正常生产造成影响, 一线的工人们呢, 又不情愿增添操作步骤。如此这般, 来自不同方向的种种顾虑, 都需要一项项妥善理清楚, 这个系统才能拥有真正得以投入使用的机会。

上线验收

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

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

验收标准被达到之后, 生产负责人作出同意将系统推广至其他车间的决定。销售同事也手持验收结果, 持续与客户就后续合作展开沟通。

系统被推广到B车间后的第二天, 维修主管就给我打来了电话。B车间存在几台特殊机型, 工人在描述故障时所采用的说法和A车间全然不同, AI又开始进行胡乱匹配了……

所以, 我必须在当日赶到那个地方, 增添了一批全新的纠错准则, 将失败的事例纳入评估集合里头, 再次运作成功了测试, 如此这般, B车间的系统才稳定了下来。

太折磨了。。。

FDE并非如同一般外包那样, 交付完毕便撤离, 在系统上线之后倘若出现问题, 你必须在第一时间赶赴现场自行予以解决。

到了项目收尾阶段, 码撕客要求我把系统配置方法以及常见问题梳理成文档, 之后带着工厂里负责信息系统的同学完整地走了一回日常维护流程。

他讲, FDE 没办法使得客户在离开了你之后就不会去使用, 必须要让对方的团队自身能够接手, 不然往后找你的事儿会多得不得了。

完结交接事宜之后, 最终返回了公司, 我们将此番项目期间探寻得出的经验带回了产品团队, 其中涵盖二维码绑定方案, 还有车间噪音环境之下的语音纠错办法, 另外是维修记录的结构化整理思路。产品经理认为在噪音环境当中的语音处理能力能够打造成为通用模块, 沉淀至产品里, 使得其他制造业客户也能够直接加以运用。

我的感受

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

过往认为, 不就是前往客户所在之处编写代码吗? 然而实际操作之后, 才发觉比预先想象的要繁杂太多了。

FDE 得先去确认客户的真实目标, 将那些不切实际的需求拽回到当前数据以及条件能够支撑的范围之中。接着随着一线用户走完真实流程, 寻觅出潜藏在日常操作里面的真正问题。而后确定方案以及可量化的验收指标, 开展系统开发、构建评估集、进入现场试用。依据用户反馈进行反复修改, 直至系统真正能够运行起来、有人使用。最后把现场经验带回产品团队, 使得产品变得更加出色。

FDE 完整工作闭环六步

各个不同公司的FDE, 其具体工作存在着较大差异, 有的公司专注于进行技术交付, 商务方面的事务由专门人员负责, 然而在许多公司, FDE不但要参与售前阶段的技术评估, 甚至还要协助客户找出新的AI落地场景以推动后续合作, 有的FDE同时为好几个客户提供服务, 有的则在一家客户处驻留长达好几个月, 不过核心要点都是一样的, 即处于客户与技术之间, 将模糊不清的问题转化为能够上线、有人使用且能产生业务价值的系统。

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

当下的FDE岗位, 对出差比例要求甚高, 最高可达百分之五十, 于实际项目里, 或许得在客户现场停留长达几周至数月之久。它不仅要求具备前后端以及AI应用开发能力, 还得拥有拆解模糊问题的本事, 建立评估方法的能力, 处理企业级系统接入与生产环境部署的能力, 更得能够与客户的技术负责人、业务负责人以及一线员工实现顺畅沟通。

假设你对钻研真实业务有着浓厚兴趣, 心甘情愿与不同行业之人展开交流接触 , 并且能够凭借自身能力亲手打造出系统, 亲眼见证其投入实际用途, 那么从事这份工作会让你产生很强的成就感。要是你仅仅期望安静地编写代码 , 不想前往现场出差 , 也不愿应对模糊含混的需求 , 那么FDE可能并不契合你 , 踏踏实实地学好AI编程以及AI应用开发 , 同样能够找到不错的发展方向。

好了, 就分享到这儿, 要是你也打算去学习AI编程, 或者是AI应用开发的话, 要不瞧瞧我免费开源的《AI编程零基础入门教程》, 还有原创AI应用开发实战项目。

鱼皮的 AI 编程教程