1. FDE 模式到底在解决什么问题第一次听到 FDE 这个词是在一个做企业数字化交付的朋友群里。有人甩了张截图说他们团队新设了前线共创工程师这个岗位问我有没有听过。我当时的第一反应是这不就是售前加实施加产品经理的混合体吗但仔细聊下来才发现FDEField Development Engineer前线开发工程师这套模式跟传统的售前支持或实施顾问有本质区别它解决的是一个存在了很多年、但一直没被真正解决的问题——产品能力与客户真实场景之间的最后一公里断层。做过 To B 产品的人都知道一个尴尬的现实产品团队在办公室里打磨出来的功能到了客户现场往往水土不服。客户说我要的是 A产品做出来的是B实施团队硬着头皮把 B 包装成 A 交付客户用了一段时间发现不对劲回头再提需求产品团队又觉得这不是我们规划的方向。这个循环转上几圈客户流失、团队疲惫、产品方向也越来越模糊。FDE 模式的核心思路就是把能写代码、懂产品、又泡在客户现场的人直接放到前线去让需求的翻译和验证在同一个角色身上完成而不是在三个部门之间来回踢皮球。这个模式最早在硅谷的一些 AI 基础设施公司里跑通后来随着 AI Agent 和 Skill 生态的爆发被越来越多的团队借鉴。我观察下来FDE 模式之所以在这个时间点被频繁讨论跟 AI 应用落地的特殊性有很大关系。传统 SaaS 产品的需求相对确定客户知道自己要什么产品照着做就行。但 AI 类产品不一样客户往往只知道我想用 AI 提效具体怎么提、提哪个环节的效、用什么形态提他自己也说不清楚。这时候就需要一个既懂技术边界、又能跟客户一起摸索的人在前线把模糊的需求一点点变成可运行的原型。FDE 就是干这个的。注意FDE 不是高级售前的换皮也不是驻场开发的升级版。它的核心差异在于交付物——传统售前交付的是方案 PPT驻场开发交付的是定制代码而 FDE 交付的是可复用的产品能力沉淀。如果只是把人派到客户现场写一次性代码那本质上还是外包不是 FDE。2. FDE 角色的能力模型拆解2.1 技术侧能独立跑通一个 Agent 原型FDE 的技术门槛不低但跟纯研发的要求方向不同。纯研发追求的是代码质量、架构合理性、性能指标FDE 追求的是快速验证可行性。我见过几个做得好的 FDE他们的技术栈通常长这样Agent 框架层能熟练使用至少一种主流 Agent 开发框架理解 ReAct、Plan-and-Execute、Multi-Agent 协作等基本范式。不需要从零手写调度器但要知道什么场景该用哪种范式。Skill 编排层能把客户的具体业务动作拆解成 Skill并且知道怎么组合这些 Skill 完成一个完整任务。这里的关键是拆解粒度——拆太细编排复杂度爆炸拆太粗复用性差。数据接入层能快速对接客户的数据库、API、文档系统。这一步往往是项目卡壳最多的地方因为客户的数据环境千奇百怪文档里写的和实际跑起来的经常对不上。快速原型能力能用低代码或脚本方式在半天到一天内搭出一个可演示的 Demo。注意是可演示不是可上线。FDE 的原型是用来对齐认知的不是用来直接交付的。我个人的经验是FDE 在技术侧最需要培养的能力不是写更多代码而是判断什么代码不用写。客户提了十个需求可能只有两个是真正核心的剩下八个用现有能力组合一下就能覆盖。FDE 的价值就在于快速识别出那两个核心需求然后用最小成本验证它。2.2 业务侧能把行业黑话翻译成技术语言这一块是很多技术背景的 FDE 最容易翻车的地方。客户说我要一个智能风控你如果直接问你要什么模型、什么特征、什么阈值客户大概率答不上来还会觉得你不懂业务。正确的做法是先跟客户聊他的业务流程一笔业务从进来到出去中间经过哪些人、哪些系统、哪些判断节点哪个节点最容易出问题、最耗时、最依赖老师傅的经验。聊完这些你心里大概就有数了——客户要的可能不是风控模型而是一个辅助判断的 Agent把老师傅的判断逻辑沉淀成 Skill新人用的时候有个参考。我总结了一个简单的翻译对照表在实际沟通中很管用客户原话真实需求技术落点我要一个智能助手某个高频重复环节想省人力单点 Skill 简单 Agent 编排我要全流程自动化多个环节都有痛点但优先级不同先做最高频环节跑通后再扩展我要能学习我的经验想把个人经验变成团队可用的资产经验结构化 Skill 封装 检索增强我要能对接所有系统数据孤岛严重想统一入口先接最核心的 1-2 个系统验证价值后再铺开这张表不是万能的但它能帮你在第一次客户沟通时不至于被带偏。关键是不要被客户给的方案带跑要回到他的业务场景里去。2.3 沟通侧能在产品和客户之间做双向翻译FDE 最独特的能力是同时向两个方向翻译。向客户方向要把技术边界翻译成客户能理解的能做什么、不能做什么、为什么向产品方向要把客户的真实痛点翻译成可复用的产品需求而不是某个客户的定制要求。这里有个很微妙的平衡点FDE 如果太偏向客户就会变成定制外包做出来的东西产品团队没法复用如果太偏向产品就会忽略客户的真实场景交付的东西客户不用。做得好的 FDE会在每次客户沟通后问自己一个问题这个需求如果换个客户还成立吗如果成立就往产品需求池里放如果不成立就用 Skill 组合的方式在前线解决掉不往产品团队传。3. 从零搭建一个 FDE 工作流的实操记录3.1 环境准备别在工具选型上纠结太久我见过不少团队在 FDE 工作流的工具选型上花了大量时间最后发现工具换来换去核心问题还是没解决。我的建议是先用最小工具集跑通一个完整闭环再根据实际卡点补工具。最小工具集包括一个 Agent 开发框架选你团队最熟悉的不要追新。如果团队没人有偏好选文档最全、社区最活跃的那个。一个 Skill 管理方式初期用文件夹加配置文件就够了不需要上复杂的 Skill 注册中心。等 Skill 数量超过 50 个再考虑治理。一个客户现场可用的演示环境最好是能一键部署的容器化方案避免在客户内网环境里折腾依赖。一个需求记录和回溯工具简单的表格就行关键是要记录客户原话、我的理解、最终实现、客户反馈这四个字段。提示不要在初期引入太多自动化工具。FDE 的工作本质是人对人的理解工具是辅助不是核心。我见过一个团队花了两个月搭了一套自动化需求流转系统结果 FDE 们还是用微信跟客户沟通系统成了摆设。3.2 第一次客户共创会的完整流程第一次共创会的目标不是拿到需求而是建立共同语言。我通常会按这个流程走第一步让客户讲他的日常不要一上来就问需求让客户讲他一天的工作流程。从早上打开电脑开始到晚上下班结束中间哪些环节他觉得顺、哪些觉得烦、哪些觉得浪费时间。这一步大概花 40 分钟你只需要听和记不要打断不要提方案。第二步复述并确认痛点把客户讲的痛点按频率和痛苦程度两个维度复述一遍让客户确认。比如您刚才提到每天要花两个小时整理报表这个是最耗时的另外每周要手动核对一次数据这个虽然频率低但一出错就很麻烦。我理解得对吗这一步的目的是让客户感觉到你听懂了这是后续所有合作的基础。第三步现场画一个理想状态的草图拿一张白纸画一个简单的流程图把客户提到的环节串起来然后在最痛的那个环节旁边画一个框写上如果这里有个助手它应该做什么。这一步不需要任何技术细节就是帮客户把模糊的期望具象化。第四步约定一个最小验证目标不要承诺我回去做个方案而是约定我下周带一个能跑的小东西来咱们一起看看方向对不对。这个小东西不需要覆盖所有痛点只需要覆盖最痛的那一个点让客户能亲手操作一下。我自己的经验是第一次共创会如果能做到客户觉得你懂他这个项目就成功了一半。剩下的技术实现反而是相对确定的部分。3.3 原型验证阶段的三个关键动作原型阶段最容易犯的错误是闷头做做完再给客户看。正确的节奏是小步快跑频繁对齐。我通常会做三个关键动作动作一半天出一个可点击的流程 Demo不需要真实对接数据用假数据把流程跑通就行。目的是让客户看到这个东西长什么样、怎么用。很多客户在没看到实物之前是不知道自己真正想要什么的。看到实物之后他才会说对对对就是这个但是这里能不能改成那样。动作二让客户亲手操作一次不要自己演示让客户自己点。你在旁边观察他哪里卡住了、哪里犹豫了、哪里点错了。这些观察比客户嘴上说的反馈更有价值。我遇到过一个客户嘴上说这个功能很好但实际操作时每次都绕过那个功能后来一问才知道他觉得那个功能太复杂了我记不住步骤。动作三记录客户改口的瞬间客户在原型阶段改口是常态不要觉得挫败。关键是记录下他为什么改口——是看到了实物才发现原来的想法不对还是因为操作太复杂想简化还是因为想到了新的场景。这些改口原因是产品迭代最宝贵的输入。4. 双向赋能FDE 如何同时喂饱产品和客户4.1 向产品侧沉淀什么该传回去什么该在前线消化FDE 最容易被诟病的一点是做了很多定制但产品没进步。要避免这个问题关键是建立一套前线到产品的过滤机制。我的做法是给每个前线需求打三个标签通用性这个需求换个客户还成立吗如果三个以上客户都提了类似需求就是通用需求。实现成本在前线用 Skill 组合解决的代价大不大如果代价小就在前线解决如果代价大就传回产品。战略匹配度这个需求跟产品当前的主航道一致吗如果一致优先传回如果不一致先在前线用临时方案顶着。这三个标签组合起来就能决定一个需求是前线消化还是传回产品。我见过做得好的团队FDE 每周会跟产品团队开一次 30 分钟的同步会只讲三件事本周遇到的新需求、哪些已经在前线解决了、哪些需要产品支持。这个会的关键不是汇报而是对齐判断标准。4.2 向客户侧赋能让客户团队能自己跑起来FDE 的终极目标不是帮客户做完而是让客户自己能做。如果 FDE 走了之后客户团队又回到原来的工作方式那这个项目就是失败的。所以 FDE 在交付时必须做一件事把能力留在客户团队里。具体做法包括Skill 使用培训不是教客户写代码而是教客户怎么用现有的 Skill 组合出自己需要的流程。这就像教人用乐高不是教人造积木而是教人拼积木。问题排查手册把常见问题、排查步骤、联系渠道写成一页纸贴在客户团队的工作区。不要写成长篇文档没人看。一个种子用户在客户团队里找一个愿意折腾的人重点培养他让他成为内部的 FDE。这个人不需要技术很强但要有好奇心、愿意试错、在团队里有影响力。我自己的体会是客户团队里有没有这样一个种子用户决定了项目交付后能不能持续运转。有种子用户的项目三个月后客户还在用甚至自己扩展了新场景没有种子用户的项目一个月后就没人打开了。4.3 一个真实案例的完整复盘去年我参与了一个制造业客户的 FDE 项目客户的需求是用 AI 辅助设备故障排查。这个项目从第一次共创会到最终交付大概用了六周时间中间经历了三次方向调整。第一周第一次共创会客户说想要一个能自动诊断故障的 AI。我们聊了两个小时发现客户真正的痛点是老师傅排查故障的经验没有沉淀下来新人遇到问题只能打电话问老师傅经常在忙新人就只能等。所以真实需求不是自动诊断而是把老师傅的经验变成新人能随时查的助手。第二周第一个原型我们做了一个简单的对话式助手把老师傅常见的 20 个故障场景和排查步骤整理成 Skill新人用自然语言描述现象助手给出排查建议。客户看了之后说方向对但新人不知道怎么描述现象。第三周方向调整我们把交互方式从自由对话改成引导式选择——先让新人选设备类型再选现象类别再选具体表现最后给出排查步骤。客户看了之后说这个好新人不用想怎么描述跟着点就行。第四周数据对接把客户的设备手册和历史维修记录接进来让助手在给出排查步骤时能引用具体的文档段落。这一步花了最多时间因为客户的文档格式不统一有的 PDF 是扫描件有的 Word 是手写体转的清洗数据花了不少功夫。第五周种子用户培训在客户团队里找了一个刚入职半年的新人重点培训他怎么用、怎么改 Skill、怎么反馈问题。这个小伙子后来成了客户内部的AI 助手管理员现在还在维护和扩展这个助手。第六周交付和复盘交付时我们只留了三样东西一个可运行的助手、一份 Skill 维护指南、一个种子用户的联系方式。客户后来反馈新人上手时间从原来的三个月缩短到了三周老师傅的电话量减少了大概六成。这个案例让我最深的体会是FDE 的价值不在于技术多先进而在于对场景的理解多深。我们用的技术都是现成的没有自研模型没有复杂架构但因为我们花了很多时间在客户现场理解了新人不知道怎么描述现象这个细节才做出了真正有用的东西。5. FDE 模式落地时最容易踩的五个坑5.1 坑一把 FDE 当售前用这是最常见的坑。公司高层觉得 FDE 就是能写代码的售前于是让 FDE 去陪销售见客户、写方案、做 PPT。结果 FDE 的时间全花在售前支持上真正在客户现场做共创的时间被压缩到几乎没有。这个坑的根源是组织定位不清——FDE 的考核指标如果是支持了多少个售前项目那它必然变成售前。正确的考核指标应该是交付了多少个可复用的产品能力和客户团队是否真正用起来了。5.2 坑二原型做完就撤有些 FDE 团队把原型验证当成终点验证完就撤了后续的落地和推广交给实施团队。结果实施团队不理解原型的设计意图客户用着用着就放弃了。我的建议是FDE 至少要跟到客户团队能独立运转为止这个周期通常是原型验证后的两到四周。这两到四周不是在做新功能而是在做能力转移——培训、答疑、调优、建立反馈机制。5.3 坑三Skill 拆得太细或太粗Skill 的拆解粒度是个技术活。拆太细比如打开文件是一个 Skill、读取内容是一个 Skill、关闭文件是一个 Skill编排起来会非常繁琐而且复用性差。拆太粗比如处理文档是一个 Skill内部逻辑太复杂改一处影响全局。我的经验是一个 Skill 应该对应一个业务动作比如从合同 PDF 中提取关键条款是一个 Skill根据条款生成风险提示是另一个 Skill。判断标准是这个 Skill 能不能用一句话说清楚它做什么而且这句话客户能听懂。5.4 坑四忽略客户的数据环境FDE 在办公室做原型时用的都是干净的数据。到了客户现场数据可能是 Excel 里带合并单元格的、PDF 是扫描件的、数据库字段名是拼音缩写的。这些脏数据会消耗大量时间。我的做法是在第一次共创会时就要求看客户的真实数据哪怕只看一个样本。提前知道数据长什么样比到了现场再发现要主动得多。5.5 坑五没有建立前线到产品的反馈闭环FDE 在前线看到的需求如果传不回产品产品就会越来越脱离实际。但反馈闭环不是建个群、发个周报就完事了。关键是产品团队要有人对前线反馈负责——有人看、有人判断、有人回复。我见过一个团队FDE 每周发反馈产品团队从来不看三个月后 FDE 就不发了。反馈闭环的核心不是通道而是响应。6. 关于 FDE 模式的一些个人判断FDE 模式不是万能的。它适合的场景是产品能力有一定通用性、但客户场景差异大、需要深度共创才能落地。如果产品本身已经非常标准化客户拿来就能用那不需要 FDE。如果客户需求完全是定制化的每个客户都要从头做那 FDE 也救不了那是项目制外包的活。我观察下来FDE 模式在 AI 应用落地领域特别有效因为 AI 的能力边界是模糊的客户不知道 AI 能做什么、不能做什么需要有人在前线一起摸索。但随着 AI 能力的标准化程度提高FDE 的角色可能会分化——一部分变成更偏产品的场景架构师一部分变成更偏交付的AI 实施工程师。对于想入行 FDE 的人我的建议是不要只盯着技术也不要只盯着业务要练翻译的能力。能把客户的一句模糊抱怨翻译成可执行的技术方案能把技术的一个限制翻译成客户能理解的替代方案这种能力比会写多少代码都值钱。技术会过时框架会迭代但理解场景、翻译需求、验证价值这套能力在哪个时代都是稀缺的。最后分享一个我自己的小习惯每次从客户现场回来我会花 15 分钟写一段今日最意外的一件事。可能是客户的一句话、一个操作习惯、一个我没想到的用法。这些意外往往就是产品迭代的种子。攒上几个月回头看会发现很多有价值的方向都是从这些意外里长出来的。