1. 从一个反直觉的现象说起1.1 模型能力暴涨为什么交付反而更难了过去两年我参与过不少把大模型能力落到真实业务场景里的项目。有一个现象反复出现而且越来越明显模型越强项目反而越容易在“最后一公里”翻车。这不是错觉而是我观察到的普遍规律。早些年做模型落地大家的预期很低。一个分类模型准确率能到 85%业务方就觉得“挺智能了”。那时候的交付逻辑很简单把数据清洗好、把模型训好、把 API 封装好剩下的交给前端调用就行。模型能力是瓶颈所以所有人的注意力都在模型本身。但现在情况完全反过来了。Claude、GPT 系列、DeepSeek、智谱这些模型的能力已经强到可以处理非常复杂的任务Agent 框架也日趋成熟API 调用成本还在持续下降。按理说交付应该更简单才对。可实际项目里我看到的却是另一番景象模型在 demo 里表现惊艳一进真实业务环境就各种水土不服项目周期一拖再拖最后交付的东西和最初承诺的相差甚远。问题出在哪我的判断是模型能力越强它对“现场信息”的依赖就越深而现场信息恰恰是坐在办公室里的人最拿不到的东西。这就是 FDEForward Deployed Engineer前线部署工程师这个角色越来越被重视的根本原因。1.2 FDE 到底是个什么角色FDE 这个词最早在 Palantir 这类公司被大量使用指的是被派到客户现场、直接和业务人员一起工作的工程师。他们不是传统意义上的售前也不是纯后端的研发而是介于两者之间的一种复合角色既懂技术又懂业务现场能把模型能力翻译成业务能用的东西。我理解的 FDE 核心职责有三块。第一是现场诊断去搞清楚业务真正的问题是什么而不是客户嘴上说的那个问题。第二是快速原型在现场用最短的时间搭出一个能跑的东西让业务方看到效果。第三是反馈闭环把现场发现的模型缺陷、数据问题、流程断点带回给研发团队推动产品迭代。这三块里最容易被低估的是第一块。很多技术团队觉得“需求调研”是产品经理的事工程师只管实现。但我的经验是模型类项目的需求产品经理往往问不出来因为业务方自己也不知道模型能干什么、不能干什么。只有懂技术的 FDE 到了现场才能问出真正关键的问题。1.3 这篇文章想解决什么问题这篇内容不是要讲 FDE 的定义和理论而是想把我自己在实际项目里踩过的坑、总结出的方法系统地梳理一遍。具体来说我会讲清楚几件事为什么模型越强越需要人进现场FDE 在现场具体做什么怎么把现场信息转化成可落地的技术方案以及有哪些常见的坑可以提前避开。适合读这篇内容的人包括正在做 AI Agent 落地的工程师、负责模型交付的技术负责人、想转型做 FDE 的开发者以及任何对“模型能力如何转化为业务价值”这个问题感兴趣的人。不管你是刚接触这个领域还是已经做过几个项目我相信都能从中找到一些有用的东西。2. 为什么模型越强越离不开现场2.1 强模型的“能力幻觉”陷阱我先讲一个真实的案例。之前有个团队做一个合同审核的 Agent用的是当时最强的模型在测试集上表现非常好能准确识别出合同里的风险条款。团队觉得这事成了直接打包交付。结果客户用了两周就反馈说“不好用”。问题出在哪团队去现场一看才发现客户的法务人员看合同的方式和模型完全不一样。法务不是逐条判断“这条有没有风险”而是先看合同类型、再看对方是谁、然后结合历史合作情况最后才看具体条款。模型给出一堆风险提示法务觉得“这些我早就知道”真正需要提醒的地方反而没提。这就是我说的能力幻觉模型在封闭测试环境里表现出的能力和它在真实业务流里能发挥的价值是两回事。模型越强这种幻觉越危险因为团队会更容易相信“模型已经够好了问题不在模型”。但实际上问题从来不在模型本身而在于模型和业务现场之间的那道鸿沟。2.2 现场信息的三层结构我把 FDE 需要获取的现场信息分成三层这个框架是我在多个项目里慢慢总结出来的。第一层是显性信息就是业务方自己能说清楚的东西他们用什么系统、走什么流程、有哪些角色、每天处理多少单。这些信息通过访谈和文档就能拿到相对容易。第二层是隐性信息是业务方自己意识不到、但实际在影响他们决策的东西。比如前面说的法务看合同的习惯顺序比如客服在处理投诉时对某些关键词的敏感反应比如运营在调整策略时依赖的“感觉”。这些信息不会写在任何文档里只有到现场、坐在他们旁边看他们干活才能捕捉到。第三层是环境信息是业务现场的技术和物理约束。比如网络环境怎么样、数据能不能出内网、现有系统是什么年代的、业务人员用什么设备、他们的操作习惯是什么。这些约束直接决定了技术方案能不能落地但往往在需求阶段被完全忽略。模型越强它对第二层和第三层信息的依赖就越深。因为强模型能处理复杂任务所以业务方对它的期望就越高越希望它能“像人一样”理解现场。而“像人一样”的前提就是模型得拿到人拿到的那三层信息。2.3 一个公式交付价值 模型能力 × 现场适配度我习惯用一个简单的公式来理解这件事交付价值 模型能力 × 现场适配度。这个公式的意思是模型能力再强如果现场适配度是零交付价值就是零。而现场适配度这个东西不会因为模型变强而自动提升反而可能因为模型变强、业务期望变高而变得更难满足。举个例子。模型能力从 60 分提升到 90 分如果现场适配度只有 0.3交付价值是从 18 分变成 27 分提升有限。但如果 FDE 把现场适配度从 0.3 提升到 0.8交付价值就从 18 分变成 72 分提升是巨大的。这就是为什么我说在模型能力已经足够强的今天FDE 的价值不是被削弱了而是被放大了。2.4 模型越强Agent 越需要“接地”现在大家都在做 AgentAgent 和传统模型应用最大的区别是Agent 要自主决策、要调用工具、要和多轮环境交互。这意味着 Agent 对现场信息的依赖比传统模型更深。一个 Agent 如果不知道现场的工具怎么用、数据格式是什么、异常情况怎么处理它就会做出看起来很合理、实际上完全错误的决策。而且 Agent 的错误往往比传统模型的错误更难排查因为它是一连串决策的结果你很难定位到底是哪一步出了问题。我见过一个做客服 Agent 的项目模型能力很强能理解复杂的用户诉求。但上线后频繁出现“答非所问”的情况。FDE 到现场一看发现客服系统里的工单状态字段有十几种Agent 只认识其中三种遇到其他状态就懵了。这个问题在测试环境里根本发现不了因为测试数据都是理想化的。只有到了现场看到真实的工单数据才能发现这种“接地”问题。3. FDE 在现场具体做什么3.1 现场诊断找到真问题FDE 到现场的第一件事不是讲方案而是看和听。我自己的习惯是前三天基本不动手就是坐在业务人员旁边看他们怎么工作问他们为什么这么做。这个阶段有几个关键动作。第一是跟单完整地跟一个业务流程走一遍从开始到结束记录每个环节谁在做什么、用什么工具、遇到什么问题。第二是追问业务人员说“这里很麻烦”你要追问“麻烦在哪”“现在怎么解决的”“如果解决了会怎样”。第三是记录异常正常流程大家都能说清楚真正有价值的是异常情况怎么处理。我踩过的一个坑是第一次去现场太急于展示技术能力业务人员说一个问题我马上说“这个模型能做”。结果后来发现我理解的“能做”和他们需要的“能用”差得很远。后来我学乖了现场诊断阶段只问不答把问题带回去想清楚了再说。3.2 快速原型用最小成本验证假设现场诊断之后FDE 要快速搭一个原型出来。这个原型的目的不是交付而是验证假设。你要验证的是你对业务问题的理解对不对模型能力能不能解决这个问题业务方愿不愿意用。原型的原则是快和糙。不要追求代码质量不要追求界面美观能用就行。我通常用 Claude 或者 DeepSeek 的 API 直接写个脚本把现场拿到的真实数据跑一遍让业务方看结果。如果业务方说“这个不对”那太好了你马上就知道自己的理解哪里有问题。这里有个经验原型一定要用真实数据不能用测试数据。测试数据是理想化的真实数据里全是脏东西。用真实数据跑你才能发现模型在实际场景下的真实表现。我见过太多项目原型用测试数据跑得很好一上真实数据就崩了。3.3 反馈闭环把现场信息带回研发FDE 不是一个人在战斗他背后要有研发团队支持。现场发现的问题要能快速反馈给研发推动产品迭代。这个闭环的关键是信息传递的保真度。FDE 在现场看到的问题经过层层转述到研发那里往往已经变形了。我的做法是尽量用原始数据说话。比如发现模型对某个类型的输入处理不好不要只说“模型对 XX 处理不好”而是把原始输入、模型输出、期望输出都整理好直接给研发看。另外FDE 要建立问题优先级的判断能力。现场问题很多但不是所有问题都值得马上解决。我的判断标准是这个问题影响多少用户、影响多大、有没有 workaround。影响大、没 workaround 的马上反馈影响小、有 workaround 的记录下来慢慢优化。3.4 一个 FDE 的典型一天我拿自己做过的一个项目举例说说 FDE 在现场的一天大概是什么样。早上九点到客户现场先花半小时看昨天的系统日志看看 Agent 有没有报错、有没有异常调用。然后参加业务团队的晨会听他们昨天遇到了什么问题。上午十点到十二点坐在客服旁边跟单看他们怎么用 Agent记录哪些地方卡壳。中午和业务人员一起吃饭这种非正式场合往往能听到很多正式访谈里听不到的东西。下午两点到四点根据上午的发现调整原型用新数据跑一遍。四点到五点和研发团队开个短会同步现场发现的问题。五点到六点整理当天的记录更新问题清单。这个节奏不是固定的但核心逻辑是上午获取信息下午验证假设晚上同步反馈。FDE 的时间要花在现场而不是花在写代码上。写代码是研发的事FDE 的价值在于把现场信息转化成研发能理解的需求。4. 把现场信息转化成技术方案4.1 从业务语言到技术语言的翻译FDE 最核心的能力是翻译。业务人员说的是业务语言研发听的是技术语言FDE 要在两者之间做转换。举个例子。业务人员说“这个 Agent 回答得太啰嗦了”。这是一句业务语言研发听了不知道该怎么改。FDE 要把它翻译成技术语言Agent 的输出长度超过了业务场景的合理范围需要加一个输出长度约束或者调整 prompt 让模型更简洁。再比如业务人员说“这个 Agent 有时候会瞎说”。翻译过来就是模型存在幻觉问题需要在关键环节加事实校验或者引入 RAG 让模型基于检索结果回答。翻译的关键是具体化。不要停留在“好”“不好”“快”“慢”这种模糊描述上要追问到具体的场景、具体的输入、具体的期望输出。我通常会用这样的句式来追问“你能给我举个例子吗当时你输入的是什么Agent 回了什么你期望它回什么”拿到具体例子翻译就成功了一半。4.2 现场约束下的方案设计现场约束是 FDE 必须面对的现实。你在办公室里可以随便用最新的模型、最贵的 API但在现场约束可能完全不一样。常见的约束包括网络约束客户内网不能访问外部 API数据约束敏感数据不能出内网成本约束客户对 API 调用成本有严格预算性能约束业务要求响应时间在多少毫秒以内合规约束某些行业对数据存储和传输有特殊要求。这些约束直接决定了技术方案。比如网络约束下你可能要用本地部署的模型而不是调云端 API。数据约束下你可能要做数据脱敏或者用联邦学习。成本约束下你可能要选更便宜的模型或者做缓存减少调用。我的经验是约束不是障碍而是设计输入。好的 FDE 会把约束当成方案设计的一部分而不是抱怨约束太多。而且约束往往能逼出更好的方案。比如成本约束逼着你做缓存和批处理反而提升了系统性能。4.3 一个可复用的 FDE 工作流基于多个项目的经验我总结了一个可复用的 FDE 工作流分五个阶段。第一阶段现场 immersion一到两周目标是理解业务、建立信任、发现真问题。产出是一份现场诊断报告包含业务流程、关键角色、核心痛点、技术约束。第二阶段原型验证一到两周目标是用最小成本验证核心假设。产出是一个能跑的原型用真实数据验证过业务方确认过。第三阶段方案设计一周左右目标是把原型转化成可交付的方案。产出是技术方案文档包含架构设计、模型选型、数据流、接口定义、部署方案。第四阶段迭代开发两到四周目标是和研发团队一起把方案实现出来。FDE 在这个阶段的作用是持续提供现场反馈确保开发方向不偏。第五阶段上线支持一到两周目标是确保系统在真实环境里稳定运行。FDE 要现场支持处理突发问题收集用户反馈。这个工作流不是线性的很多阶段会重叠和循环。但核心逻辑是现场信息驱动技术方案技术方案回到现场验证。4.4 工具选型的现场考量FDE 在现场经常要做工具选型的决策。选什么模型、用什么框架、怎么部署这些决策不能只看技术指标还要看现场条件。我通常从几个维度来评估。模型能力能不能解决业务问题这个不用多说。调用成本按 token 算还是按调用次数算有没有免费额度超了怎么计费。响应速度首 token 延迟和整体延迟是多少业务能不能接受。部署方式云端 API 还是本地部署本地部署对硬件有什么要求。数据安全数据会不会被用于训练有没有合规认证。这几个维度里数据安全往往是一票否决项。很多客户对数据出内网非常敏感这时候就只能选本地部署的方案。本地部署又带来硬件成本又要重新评估。FDE 的价值就在于能在这些约束之间找到平衡点。5. 常见问题与排查技巧5.1 现场诊断阶段的典型问题问题一业务人员说不清楚需求。这是最常见的。业务人员习惯了现有流程反而说不清楚哪里有问题。我的应对方法是观察代替询问不要问“你有什么需求”而是看他们怎么工作从他们的操作里发现痛点。问题二业务人员有抵触情绪。有些业务人员觉得 AI 是来抢饭碗的不愿意配合。我的经验是先建立信任不要一上来就谈技术先帮他们解决一个小问题让他们看到 AI 是来帮忙的不是来替代的。问题三关键信息拿不到。有些信息涉及商业机密或者部门利益业务人员不愿意说。这时候要找对的人往往一线操作人员比管理层更愿意分享真实情况。5.2 原型验证阶段的典型问题问题一原型效果不好。这太正常了原型的目的就是发现问题。我的做法是记录所有失败案例分析失败原因是数据问题、模型问题还是方案问题。然后针对性调整。问题二业务方期望过高。业务方看了 demo 觉得“太厉害了”期望值拉满。这时候要管理期望明确告诉业务方原型和产品的差距哪些能实现、哪些不能、需要多少时间。问题三真实数据质量差。真实数据往往有缺失、格式不一致、标注错误等问题。我的做法是先做数据质量评估把数据问题量化让业务方知道数据质量对效果的影响。5.3 上线支持阶段的典型问题问题一性能不达标。测试环境跑得好好的上线就慢。常见原因是并发量上来了、数据量大了、网络延迟高了。排查思路是分段计时把请求链路拆开看哪一段慢。问题二模型输出不稳定。同样的输入有时候输出好有时候输出差。这通常是 prompt 设计问题或者模型本身的不确定性。应对方法是加约束用结构化输出、加校验规则、做结果缓存。问题三用户不会用。系统做得再好用户不会用也是白搭。FDE 要做培训手把手教用户怎么用收集使用反馈持续优化交互。5.4 一个排查速查表问题现象可能原因排查方法解决方向模型答非所问输入理解偏差检查输入格式和 prompt优化 prompt加 few-shot 示例响应速度慢网络延迟或模型推理慢分段计时定位瓶颈换更快的模型加缓存输出不稳定模型不确定性多次调用对比输出加约束用结构化输出数据出不去网络或合规约束确认约束条件本地部署数据脱敏用户不用交互复杂或价值不明显观察用户操作简化交互突出价值成本超预算调用量或模型选型问题统计 token 消耗换便宜模型加缓存批处理5.5 几个我踩过的坑坑一太相信测试数据。我早期做项目测试数据跑得好就以为成了结果上线就崩。后来我坚持用真实数据做原型哪怕数据脏一点、少一点也比测试数据有价值。坑二忽略非技术约束。有一次方案设计得很好但忽略了客户的采购流程导致硬件迟迟不到位项目延期。后来我学会了提前确认所有约束技术约束、商务约束、合规约束一个都不能少。坑三反馈链条太长。现场发现问题经过产品经理、项目经理、研发 leader到研发那里已经变味了。后来我坚持直接和研发沟通用原始数据说话减少信息损耗。坑四原型太完美。有一次原型做得太完整业务方以为这就是最终产品结果正式开发周期比预期长业务方觉得“你们退步了”。后来我学会了原型故意留粗糙明确告诉业务方这是验证用的不是最终产品。6. 给想转型 FDE 的开发者的一些建议6.1 技术能力之外你还需要什么如果你想从纯研发转型做 FDE技术能力是基础但不是全部。我观察下来做得好的 FDE 往往具备几种非技术能力。沟通能力是第一位。你要能和业务人员聊天能听懂他们的话也能让他们听懂你的话。这不是说要你变得油嘴滑舌而是要有同理心能站在对方的角度想问题。好奇心也很重要。FDE 要不断问“为什么”为什么这个流程是这样、为什么这个字段要这么填、为什么用户会这么操作。没有好奇心的人到了现场也发现不了问题。抗压能力不能少。现场情况复杂业务方催得急研发资源不够各种意外情况。FDE 要能在压力下保持冷静分清轻重缓急。快速学习能力是刚需。每个行业、每个客户都不一样FDE 要能快速学习新领域的知识理解新业务的逻辑。6.2 怎么积累现场经验现场经验不是看书能看来的必须实际去做。我的建议是从小项目开始先跟一个简单的项目跟着有经验的 FDE 学看他们怎么和业务方沟通、怎么发现问题、怎么设计方案。然后主动争取去现场。很多研发不愿意出差觉得浪费时间。但我的经验是去现场学到的东西比在办公室写一个月代码还多。哪怕只是去旁听也能学到很多。再就是复盘。每次从现场回来花时间整理记录总结哪些做得好、哪些做得不好、下次怎么改进。我自己的习惯是每天写现场日志项目结束后整理成案例库。6.3 FDE 的职业发展路径FDE 的职业发展有几个方向。一是深耕某个行业成为这个行业的 AI 落地专家比如金融 FDE、医疗 FDE、制造 FDE。二是转向产品把现场经验转化成产品设计做更懂业务的产品经理。三是转向管理带 FDE 团队培养更多前线工程师。不管哪个方向FDE 的核心竞争力都是现场理解力。这个东西不会过时因为不管模型多强业务现场永远有模型理解不了的东西永远需要有人去现场把它翻译成技术语言。6.4 最后分享一个实用技巧如果你刚开始做 FDE我建议你准备一个现场工具箱。里面包括一个轻量的原型开发环境能快速跑模型一套数据采集脚本能快速处理现场数据一个模板化的诊断报告能快速整理现场发现还有最重要的一个开放的心态准备好接受现场的一切意外。我在实际项目里最大的体会是FDE 的价值不在于你懂多少技术而在于你能把技术和现场连接起来。模型越强这个连接就越重要。因为强模型能做的事很多但做什么、怎么做、做到什么程度这些问题的答案不在模型里在现场里。