1. 模型能力越强现场判断反而越值钱很多人第一次听到“FDE”这个词会下意识觉得它只是“技术支援”或者“驻场工程师”的另一种叫法。但真正做过几个项目之后你会发现FDE 的核心价值根本不在于“会调模型”或者“能写代码”而在于当模型能力已经足够强的时候仍然有人能站在现场把那些模型看不见、摸不着、猜不透的东西翻译成可执行的方案。这一讲我想聊的是一个反直觉的现象过去两年模型能力几乎是按季度在跳涨推理、代码、多模态、长上下文每一项指标都在刷新。按理说模型越强人的介入应该越少才对。但实际项目里恰恰相反——模型越强越需要有人进现场。这不是情怀也不是为了保住岗位而是因为模型越强它被部署到的场景就越复杂、越关键、越贴近真实业务而真实业务里那些“脏”的部分模型根本接不住。我先把结论放在前面FDE 不是模型的替代品也不是模型的附属品。FDE 是模型能力与现场现实之间的翻译层、缓冲层和兜底层。模型越强这三层的价值就越高因为一旦模型出错代价也越大。一个只能做 demo 的模型错了就错了一个已经嵌入到客户核心流程里的模型错一次可能就是几十万的损失。这时候现场有没有一个能快速判断、快速止损、快速重构的人就是项目成败的分水岭。这篇文章适合三类人看一是正在做 AI 落地项目、但总觉得“模型明明很强为什么客户还是不满意”的工程师二是准备转型 FDE、但不确定这个岗位到底做什么的技术人三是带团队做交付、需要理解“为什么不能全靠远程支持”的管理者。我会从模型能力的边界、现场信息的不可替代性、FDE 的具体工作方法、以及我踩过的几个真实坑把这件事拆开讲透。2. 模型再强也绕不开的三类现场信息2.1 业务语境里的“默认知识”根本不在训练数据里模型的知识来自公开数据、代码仓库、文档、论文这些内容有一个共同特点它们都是被整理过的、有结构的、去掉了大量背景噪音的。但现场业务恰恰相反现场最核心的信息往往藏在“没人写下来”的地方。举个例子我之前参与过一个制造业的质检项目。模型在实验室里识别缺陷的准确率能到 97%但一上产线就掉到 70% 出头。原因不是模型不行而是产线上有一个“默认知识”每天早班开机后的前 20 分钟因为设备温度还没稳定产品表面会有轻微色差这个色差不是缺陷但模型没见过这个规则。这条规则没有任何文档记录老员工都知道新员工要带两周才明白。模型再强它也不可能从公开数据里学到“这家工厂早班前 20 分钟色差不算缺陷”这种知识。这就是 FDE 要进现场的第一个理由把那些“默认知识”挖出来变成模型能理解的规则、提示词、后处理逻辑或者直接变成人工复核的触发条件。你不进现场你连问什么问题都不知道。2.2 数据管道的真实状态和文档写的完全是两回事做 AI 项目的人都有一个共识数据清洗和管道搭建占掉 70% 的时间。但更麻烦的是文档里写的管道和现场跑的管道经常不是同一个东西。我见过一个典型的案例客户说他们的数据已经“实时同步”到数据仓库了文档上也画了一条漂亮的 Kafka 链路。结果到现场一看所谓“实时”其实是每 15 分钟跑一次批处理而且中间有一个字段在某个版本之后被上游系统改成了 JSON 字符串下游解析一直报错但没人管因为“不影响主流程”。模型拿到的数据里这个字段全是 null但模型不会告诉你“这个字段是 null 所以我判断不了”它会直接给你一个看起来合理的错误答案。FDE 进现场要做的不是重新写一遍管道而是快速摸清数据的真实状态哪些字段是可靠的哪些字段是“看起来有值但其实是默认值”哪些字段的更新频率和文档不一致。这些信息决定了模型输出的置信度到底该怎么设也决定了哪些环节必须加人工兜底。2.3 组织内部的“隐性约束”比技术约束更致命技术问题通常有解组织问题往往无解——但你必须知道它存在。比如客户的数据团队和业务团队是两条汇报线数据团队只负责“把数据给出去”业务团队只负责“用数据做决策”中间没有任何人对“数据质量”负责。这时候你如果只从技术角度提方案说“你们把数据质量监控加上就行了”大概率推不动因为没人愿意接这个活。FDE 要做的是识别出这些隐性约束然后设计一个绕开或者利用这些约束的方案。比如把数据质量检查嵌入到业务团队已有的日报流程里让业务团队自己发现异常而不是新增一个“数据质量看板”然后没人看。这三类信息——默认知识、真实数据状态、隐性约束——有一个共同点它们都不在模型的能力范围内也不在远程支持的可见范围内。只有人进现场才能把它们挖出来、翻译成可执行的方案。3. FDE 进现场到底在做什么四个核心动作3.1 第一动作用“外行视角”重新问一遍业务问题FDE 进现场的第一个动作不是打开电脑看代码而是跟业务人员聊天。但聊天不是随便聊你要带着一个“外行视角”去问那些技术人员觉得“这还用问”的问题。比如在一个客服质检项目里我问业务主管“你们怎么判断一个客服通话是‘好’的”主管说“态度好、解决问题快。”我说“能不能给我三个具体的例子让我听听什么叫‘态度好’”主管放了三段录音第一段客服说了很多“您别着急”但问题没解决第二段客服话很少但直接给了解决方案第三段客服全程很客气但把客户推给了另一个部门。主管说“第二段最好第一段和第三段都不行。”这个信息非常关键“态度好”在业务语境里不等于“说得多”或者“语气温柔”而是“能不能一次把问题解决”。如果我不进现场只按字面理解去设计模型大概率会把“您别着急”这种话术当成正向信号结果模型学出来的“好客服”全是话术漂亮但解决不了问题的。3.2 第二动作把“模型输出”翻译成“业务动作”模型输出的是一个分数、一个标签、一段文本但业务人员要的是一个动作这条数据要不要复核这个客户要不要回访这个工单要不要升级FDE 的核心工作之一就是在模型输出和业务动作之间建立映射。这个映射不是简单的“分数大于 0.8 就通过”因为业务动作的代价是不对称的。比如在金融风控场景里漏掉一个坏客户的代价可能是误杀一个好客户的几十倍。这时候阈值就不能按准确率来设而要按业务损失函数来设。我通常会做一个简单的表格把不同阈值下的业务影响列出来然后跟业务方一起决定用哪个阈值。这个动作看起来很简单但它是 FDE 价值的集中体现模型团队关心的是 AUC、F1业务团队关心的是“这个月坏账率会不会超”FDE 要做的就是把这两个语言翻译成彼此能听懂的话。3.3 第三动作设计“人机回环”的触发条件模型越强越容易让人产生“全自动”的冲动。但实际项目里全自动往往是最危险的因为模型在边缘案例上的表现是不可预测的而边缘案例在业务里往往是最重要的。FDE 要做的是设计一套人机回环的触发条件什么情况下模型自动处理什么情况下转人工什么情况下直接拦截。这套触发条件不是拍脑袋定的而是基于现场观察到的数据分布、业务容忍度和人工处理成本来定的。我一般会建议客户先跑一个“影子模式”模型正常输出但不直接生效而是跟人工判断做对比。跑两周之后你就能看到模型在哪些类型的案例上容易出错然后针对这些类型设置人工复核规则。这个过程听起来很笨但它比任何“一键全自动”的方案都稳。3.4 第四动作把现场知识沉淀成可复用的资产FDE 进现场不是一次性的但也不能每次都靠人肉去挖。所以最后一个动作是把现场知识沉淀下来哪些规则是业务默认知识哪些字段有坑哪些场景必须人工介入这些都要写成文档、做成检查清单、甚至变成自动化测试用例。我自己的习惯是维护一个“现场知识库”每做一个项目就往里加几条。比如“制造业早班前 20 分钟色差不算缺陷”这种规则下次遇到类似场景就能直接复用。这个知识库才是 FDE 最核心的资产因为它记录了模型永远学不到的东西。4. 一个真实项目的完整拆解从远程自信到现场打脸4.1 远程阶段一切看起来都很顺利去年我参与了一个零售行业的库存预测项目。客户有几十家门店想用模型预测未来一周的销量然后自动生成补货建议。远程阶段我们拿了客户提供的历史销售数据跑了一个梯度提升模型验证集上的 MAPE 大概在 12% 左右客户看了 demo 很满意说“比我们人工预测准多了”。这时候团队里有人提议“要不直接上线吧反正模型效果已经达标了。”但我坚持要去现场看一眼。原因很简单库存预测这个场景模型准不准是一回事补货建议能不能用是另一回事。如果模型预测某家店下周某商品销量会涨但这家店的货架已经满了补货建议就是废的。这些约束不在数据里只在现场。4.2 现场第一天发现数据里的“幽灵库存”到现场第一天我跟着店长走了一圈发现一个数据里完全看不出来的问题系统里的库存和实际货架上的库存对不上。系统显示某商品还有 30 件但货架上只有 12 件剩下的 18 件在仓库里但仓库管理员说“那是给线上订单预留的不能动”。这就是典型的“幽灵库存”数据上有实际上不能用。模型如果不知道这个约束就会基于错误的库存数据给出补货建议结果要么补多了积压要么补少了缺货。更麻烦的是这个“预留库存”的规则每个店还不一样有的店预留 20%有的店预留 50%完全取决于店长的习惯。4.3 现场第三天把“店长经验”变成模型约束发现问题之后我们没有急着改模型而是先做了一件事跟五个店长分别聊了一个小时把他们脑子里的补货规则全部挖出来。结果发现除了预留库存之外还有几个关键约束有些商品有“最小陈列量”低于这个量就必须补不管预测销量多少有些商品是“搭配销售”的比如牙膏和牙刷补货要一起补有些商品有“保质期敏感”补多了卖不掉就是损耗所以宁可少补。这些规则没有任何文档记录但每个店长都门儿清。我们把它们整理成一张规则表然后在模型输出之后加了一层“规则过滤”模型先给一个基础建议规则层再根据这些约束做调整。调整之后补货建议的可用率从 60% 出头直接拉到 90% 以上。4.4 复盘如果没进现场会怎样这个项目如果没进现场大概率会是这样一个结局模型上线MAPE 看起来不错但店长们用了几次之后发现“建议不靠谱”然后慢慢就不用了最后项目变成“模型在跑但没人看”的状态。这不是模型的问题而是模型没有接入现场的真实约束。FDE 进现场的价值在这个项目里体现得非常具体把那些“店长知道但系统不知道”的规则变成模型能执行的约束。这件事远程做不了因为远程你连问什么问题都不知道。5. 模型越强FDE 的门槛反而越高5.1 模型强了之后FDE 不能再靠“调参”吃饭早几年做 AI 项目FDE 的核心技能是调参、特征工程、模型选型。但现在这些工作越来越被自动化工具和更强的基座模型替代了。如果你现在还把“会调 XGBoost”或者“会微调 BERT”当成核心竞争力那确实会感到压力。但模型强了之后FDE 的门槛不是降低了而是转移了。以前你只需要懂模型现在你需要懂模型 业务 组织 数据管道 人机交互。模型越强它被用到的场景就越核心而核心场景里的约束就越多、越复杂、越需要有人去翻译。5.2 现场判断力FDE 最稀缺的能力我观察下来FDE 最稀缺的能力不是技术能力而是现场判断力你能不能在一个陌生的环境里快速识别出哪些信息是关键的哪些问题是伪问题哪些约束是必须尊重的。这种判断力很难从书本上学因为它依赖大量的现场经验。但有一些方法可以加速积累每次进现场之前先列一个“假设清单”你认为现场是什么样然后去验证。验证失败的地方就是你学到东西的地方。跟业务人员聊天时多问“能不能举个例子”抽象的描述往往掩盖了真实的规则具体的例子才能暴露细节。遇到异常时先问“这个异常在业务上意味着什么”技术异常往往对应着业务规则找到那个规则问题就解决了一半。5.3 沟通能力把技术语言翻译成业务语言FDE 另一个核心能力是翻译把模型的能力和限制翻译成业务人员能听懂的话把业务的约束和期望翻译成技术团队能执行的需求。这个能力听起来很虚但实际项目里非常具体。比如模型团队说“这个模型的召回率是 85%”业务人员听不懂。FDE 要翻译成“100 个真正有问题的案例里模型能抓到 85 个剩下 15 个会漏掉。这 15 个漏掉的我们需要用人工复核来兜底。”业务人员马上就明白了。反过来业务人员说“这个建议不靠谱”FDE 要翻译成“是模型预测不准还是规则约束没加上还是数据本身有问题”然后带着技术团队去定位。6. 踩过的坑那些远程看起来没问题、现场一用就崩的方案6.1 坑一用“平均指标”掩盖了“局部崩溃”这是我最常踩的坑。模型在整体数据上 AUC 0.9看起来很好但一上现场就发现某个关键客群上的表现一塌糊涂。比如在一个信贷项目里模型整体表现很好但在“小微企业主”这个客群上因为样本量少、特征分布差异大模型几乎是在瞎猜。而小微企业主恰恰是业务最看重的客群。这个坑的教训是不要只看整体指标要按业务维度拆开看。FDE 进现场之后第一件事就是问业务方“你们最看重哪类客户/哪类订单/哪类场景”然后针对这些维度单独评估模型表现。6.2 坑二忽略了“人工处理成本”这个约束模型给出一个建议人工去执行这个执行是有成本的。如果模型建议的准确率不够高人工执行的成本就会超过收益。但很多模型团队不关心这个他们只关心模型指标。我见过一个项目模型每天给出 500 条“高风险”预警但实际确认下来只有 50 条是真的。业务团队每天要花两个人去处理这 500 条处理完之后发现 450 条是误报很快就没人愿意干了。后来我们调整了策略模型只输出最确定的 50 条剩下的用抽样复核。虽然召回率降了但业务团队愿意用了整体效果反而更好。6.3 坑三把“模型上线”当成项目终点很多技术团队把模型上线当成终点但 FDE 知道上线只是起点。模型上线之后数据分布会变、业务规则会变、用户行为会变模型的表现会慢慢漂移。如果没有人在现场持续观察和调整模型很快就会变成“没人用的摆设”。我自己的做法是模型上线之后至少跟两周每天看一遍模型输出和业务反馈把异常案例记下来每周做一次小调整。这两周的投入比前面几个月的开发都值。7. 如果你要转 FDE我会建议你先做这三件事第一件事找一个真实场景完整跟一遍。不要只做模型部分从数据采集、清洗、建模、部署、到业务使用全部跟一遍。你会发现模型只是其中很小的一环大部分问题都出在模型之外。第二件事练“问问题”的能力。FDE 的核心动作是问问题但问对问题很难。我的经验是多问“为什么”和“能不能举个例子”少问“是不是”和“对不对”。开放性问题才能挖出隐藏信息。第三件事建立自己的“现场知识库”。每做一个项目把遇到的坑、学到的规则、验证过的方案记下来。这个知识库是你最核心的竞争力因为它记录了模型学不到的东西。模型越强越需要有人进现场。这不是因为模型不够好而是因为现场永远比模型复杂。FDE 的价值就是站在模型和现场之间把那些模型看不见的东西变成模型能执行的动作。这件事远程做不了自动化也做不了只能靠人。