企业AI转型最稀缺的，不是模型，而是FDE
企业从来不缺AI想法，真正缺的是愿意走进业务现场，并把结果交付出来的人。
*本篇文章共计5481字，深度探讨我对FDE的思考。内容较长，可以先收藏。
企业从来不缺AI想法，真正缺的是愿意走进业务现场，并把结果交付出来的人。
大家好，我是Sober阿铭。
这几天，我参加了很多场关于FDE的交流，也把自己过去做过的项目重新翻了一遍。
从8年前第一次开启AI学术的项目，到这两年AI商业上相关的咨询、定制、内训。有在企业驻企两个多月，也有自己一个人去新疆待了41天，当然也有仅限于1个小时的咨询。
所以，我就开始思考：FDE在中国化的场景下是否是一个真需求？或者又是一阵风一样的AI热点？
实际上，过去大家可能已经有相似的经历，但不一定会把这些工作叫作FDE。现在回过头看，我们在现场处理的很多问题，本质上又都符合FDE的定义。
客户最开始找到我们时，通常会说自己想做一个智能体、搭一套知识库、把某段流程自动化，或者干脆说，希望公司能够完成AI转型。
这些话都没错，但离一个能够交付的项目还很远。
当你以外脑和推进者的角色，真正进入企业以后，你才会发现，模型往往不是最难的部分。
难的是业务部门和技术部门对同一件事情的理解不一样，管理层描述的是标准流程，一线员工执行的是另一套流程；企业觉得自己的数据都在系统里，真正调用时却发现，重要信息散落在表格、聊天记录和少数老员工的脑子里。
很多工作明明已经写进了SOP，看起来非常清楚。等你坐到员工旁边，看着他实际操作一遍，又会发现大量判断根本没有被记录下来。
有时候，员工宁愿打开五个微信群，也不愿意相信系统里的库存；有时候，一份报价为什么这样出，解释到最后只剩下一句话：“以前一直就是这么做的。”
甚至，你可能还要付出额外的精力，去对抗来自组织框架下的质疑和“抵抗”。
但AI要进入的，偏偏就是这样的业务现场。
所以我现在理解FDE，不太喜欢从岗位名称开始解释。
对我来说，FDE就是那个站到问题发生的地方，陪着企业把业务重新跑通，并且对最后有没有产生结果负责的人。
FDE这个词很新，解决的却是一个很老的问题
过去我们做企业数字化项目，通常会有一条比较完整的分工链路。
老板提出方向，顾问负责梳理需求，产品经理形成方案，开发团队按照功能文档建设，实施人员再推动上线。
当需求稳定、业务边界清楚时，这种分工没有太大问题。
但AI项目有一个麻烦：很多需求在项目开始时，连客户自己也说不清楚。
客户说想做“AI客服”，这句话里可能同时包含降低客服成本、提高回复速度、提升销售转化、统一服务口径和沉淀客户数据。几个目标放在一起，最终会对应完全不同的产品。
服务商如果过早接受“做一个AI客服”这个答案，项目很快就会进入功能开发。等系统做完，模型确实能回答问题，大家才发现客户咨询的信息并不完整，产品价格经常变化，关键问题仍然必须由销售判断，员工也不愿意把客户真正交给系统。
开发完成了，项目却没有完成。事干了，交付完成了，两边却都感觉缺点啥，然后，或许还要被迫去推进这个带着“缺陷”的新架构。
这种情况很有意思。参与项目的每个人可能都做完了自己负责的部分，最后却没有人对业务结果负责。
老板觉得需求已经交代清楚了，业务部门认为技术团队不懂现场，开发人员认为需求总在变化，服务商则会说模型本身存在不确定性。
当开始进行权责对质，每个人都有自己的道理。
FDE要补上的，恰好是这条责任链路中间的断层。
Palantir很早就把Forward Deployed Engineering作为一种核心工作方法。他们有一个我觉得很准确的说法：FDE是“人类版本的反向传播”。工程师尽可能靠近问题现场，把真实反馈带回产品和工程体系，再根据反馈调整系统。
这个比喻为什么准确？
因为企业AI交付不可能只靠最初那份需求文档完成。系统一定要进入现场接受反馈，再根据错误、例外和使用行为不断调整。没有这条反馈链，项目做得越快，可能离真实业务越远。
OpenAI现在对FDE岗位的要求也很直接：从客户发现、技术范围界定、系统设计，一直负责到开发和生产上线。它强调的是端到端负责，而不是在其中某一个环节提供建议。
你看，FDE里面虽然有一个Engineer，但它最重要的部分，未必是写代码。
代码只是把问题解决掉的一种手段。
更难的是先判断：这里到底是不是一个值得用AI解决的问题。
市场缺的不是“懂一点AI的人”
现在会调用大模型API、会搭知识库、会用工作流工具的人，已经越来越多。
Codex、Cursor这一类AI编程工具也在快速降低开发门槛。过去需要一个小团队才能完成的原型，现在一个熟练的个人开发者就有机会做出来。
我非常认可这种变化。它会极大提高AI项目的开发速度。
但开发速度提高以后，企业面临的另一个问题反而会更加突出：当功能越来越容易被做出来，我们究竟该做什么？
这个问题不能交给模型回答。
一家企业提出十个AI需求，理论上可能都能实现，但预算、数据基础、组织意愿和业务价值并不支持十个项目同时推进。谁来判断先做哪一个？判断错了以后，浪费的可能不只是开发费用，还有管理层对AI项目的信任。
——FDE的稀缺，主要就稀缺在这里。
他需要和企业决策者讨论经营结果，也愿意坐在一线员工旁边看他怎么处理一张表；他得理解大模型、RAG、Agent和接口调用，也要知道什么时候不该继续堆技术；项目出现问题以后，不能只把原因归结为“客户需求变化”或者“模型能力有限”。
说实话，这几种能力经常是互相冲突的。
擅长写代码的人，习惯等待明确需求。擅长商业沟通的人，容易低估生产系统的复杂度。传统顾问能够把问题分析得很完整，却不一定能亲手把系统做出来。纯实施人员擅长推动上线，但通常没有权限重新定义项目方向。
FDE刚好被夹在这些角色之间。
他既不能只做一个站在岸上讲方法的人，也不能把自己缩小成客户提出什么就开发什么的执行者。
这也是为什么我不太愿意把FDE简单翻译成“驻场工程师”。驻场只是工作位置发生了变化，FDE真正改变的是责任方式。
2026年5月，OpenAI成立了专门的Deployment Company，并计划通过收购Tomoro，在成立时直接引入大约150名有经验的FDE和部署专家。
同一个月，Anthropic也宣布参与建设新的企业AI服务公司。它给出的背景是，很多中型企业希望把Claude放进核心业务，却缺少自行建设和运行前沿AI系统的内部资源。一个典型项目，会由小团队先进入客户现场，理解哪段工作最值得改变，然后再结合企业实际运营开发系统。
到了2026年6月，Anthropic与DXC的合作中，已经明确提出要培养大量直接嵌入客户组织的FDE，面向银行、航空、保险、制造和政府等复杂行业做部署。
我不认为这些消息能够简单证明“FDE马上会成为最热门职业”。这种结论太快了。
它们至少说明了一件事：当模型能力逐渐标准化以后，头部模型公司已经开始把企业部署能力当成新的战略瓶颈。
模型公司当然希望卖出更多模型，但企业买了模型以后用不起来，模型能力再强也形成不了长期收入。
最后卡住这条链路的，往往是交付。
我现在听到“做一个企业级AI平台”，第一反应通常不是兴奋
因为平台是一个太早出现的答案。
企业还没有跑通第一条AI业务闭环，就开始规划统一入口、统一知识库、统一智能体中心和统一数据底座，方案很容易越来越大。每个部门都希望把自己的需求放进去，项目最后看起来非常完整，却找不到一个明确的使用者。
我做企业AI项目时，现在会先把客户说出来的需求当作线索，而不是直接把它当作答案。
比如，我们之前分析过一家头部DIY电脑定制品牌的需求。它有大约百万的私域用户、近百个企业微信账号，涉及上千个配件SKU。
客户提出的是AI客服和智能推荐。
只看这几个字，做一个对话框并不难。接入商品知识库，再让模型根据用户预算推荐配置，很快就能做出一个效果不错的Demo。
但真正的业务问题没有这么简单。
用户说“给我配一台一万元左右的电脑”，并不意味着系统只要把几个商品凑到一万元。CPU和主板是否兼容，电源能否满足显卡功耗，不同用途对配置的优先级有什么差异，实时库存和促销价格是否发生变化，这些信息共同决定了推荐结果是否可信。
再往后看，推荐完成也不是流程终点。
这份配置由AI直接发给用户，还是先交给销售确认？用户修改预算后，系统能否继承上一次对话中的约束？遇到库存变化怎么办？AI给出错误搭配时，由谁发现？有效线索最后如何回到企业微信和CRM？
走到这里，“做一个AI客服”才逐渐变成一段可以交付的业务流程。
FDE关心的就是这段过程。
他会先看今天这项工作由谁完成，平均花费多少时间，员工依赖哪些信息，最容易在哪个节点出错。然后从中选择一段价值明确、边界相对可控的流程，做出第一版系统。
系统进入真实环境以后，重点也不再是展示模型最好的一次回答，而是观察它最容易在哪些地方失败。
原型证明的是“能做”，生产使用、量化验收和组织采纳才证明“值得做”。
这句话是我现在判断AI项目时很重要的一个标准。
很多Demo只需要准备一组干净的数据，按照设计好的路径演示一遍。真实业务不会按照演示脚本运行。用户会漏掉关键信息，会上传模糊的文件，会提出知识库里没有的问题，企业接口也可能突然返回异常。
一个系统表现正常时有多聪明，并不能决定企业敢不敢使用它。
企业更关心的是，它出错以后会发生什么。
系统是否知道自己没有足够的信息，关键结果有没有人工确认，异常能不能被记录下来，模型升级以后是否可以重新测试，这些看起来没有“AI生成效果”那么吸引人，却决定了它能不能进入生产环境。
FDE交付，往往要先处理AI之外的事情
我在餐饮连锁企业驻企两个月时，一个很深的感受是：企业写在文件里的流程，和真正运行的流程，通常存在距离。
管理层看到的是组织架构和制度文件，一线员工面对的却是每天不断发生的例外。
这个门店为什么可以特殊处理，那位客户为什么需要换一种政策，某项数据为什么月底再统一补录，背后都有一套长期形成的经验和利益关系。
AI进入企业以后，不会自动消除这些问题。
AI会更快的把原本隐藏的问题暴露出来。
企业想建设知识库，才发现内部没有统一版本；希望AI自动生成经营报告，才发现不同部门对同一指标的定义不一致；准备让AI参与审批，又发现很多审批判断依赖领导的个人经验。
所以FDE进入现场以后，有时并不会马上开始写代码。
可能要先帮助企业统一数据口径，把模糊的判断标准说清楚，确认哪些责任可以交给系统，哪些仍然需要人承担。
这部分工作很难被包装成一个炫酷的AI功能，价值却非常实际。
因为AI不会自动让混乱的流程变得清晰。它只会按照企业提供给它的上下文运行。上下文越混乱，AI越有可能用一种听起来很合理的方式，把混乱继续放大。
我现在越来越不认同一种交付方式：服务商把系统搭好，给员工做一场培训，项目就算结束。
员工愿不愿意使用，不取决于他听没听懂培训。
他会判断这套系统有没有增加自己的工作量，AI给出的结果出了问题由谁负责，使用以后会不会影响现有利益，领导究竟是真的要求改变流程，还是只想看看AI项目的演示效果。
这些问题不处理，AI最后就会留在浏览器收藏夹里。
刚上线时大家打开几次，过一段时间又回到微信群、Excel和原来的操作习惯。
这不是员工排斥新技术。很多时候，只是企业没有为新的工作方式建立新的责任关系。
一次好的FDE交付，最终是让FDE离开
这一点我特别想讲。
“驻场”很容易让服务商产生一种错觉：只要客户离不开自己，就说明服务有价值。
但从FDE的角度看，长期依赖某一个人或者服务商，反而可能意味着交付没有完成。
FDE在现场解决的问题，需要逐渐沉淀成企业能够掌握的能力。项目结束以后，企业至少应该留下相对清晰的数据口径、业务流程、评测样本、异常处理方式和内部负责人。
哪些结果必须人工确认，模型出现什么问题需要升级处理，后续替换模型时怎样重新评估，这些内容不能只存在于服务商工程师的脑子里。
现场发现的共性问题，也要被服务团队重新抽象为组件、模板和方法。否则每个项目都从零开始，FDE很快就会变成高成本的定制开发。
我理解的FDE：一边要向下进入现场，把问题做深；另一边还要向上完成抽象，让这一次的经验能够服务下一次交付。
这两件事缺一不可。
只做抽象，容易离业务越来越远。只做定制，团队规模会成为增长上限。
企业决策者在选择FDE服务时，也不必先问对方掌握多少模型、用过多少Agent框架。
这些当然重要，但更值得问的是：
你准备改变哪一段具体工作？这段工作的当前基线是什么？AI最不能犯的错误是什么？项目完成以后，企业内部会留下什么？
如果这些问题没有答案，技术方案写得再完整，项目都可能还停留在想法阶段。
为什么我开始认真看待FDE？
过去几年，我做过云计算、企业数字化、驻场咨询，也做AI Agent、RAG、工作流和GEO这些标准AI解决方案。
这些经历放在一起以后，我发现自己真正感兴趣的，从来不只是某一个模型或者某一种技术。
我更关心的是：一项技术怎样进入企业，怎样从演示变成日常工作，最后怎样对经营产生一点可以被看见的变化。
这也是我和铭文鼎成接下来会持续构建FDE交付体系的原因。
我们不希望只是给企业增加一个AI入口，也不打算把FDE包装成一个听起来更先进的服务名称。
它对我们的要求其实更高。
过去服务商可以对功能负责，FDE还要继续向前走，参与问题定义；也要继续向后走，关注系统是否被采用，结果能不能衡量，项目经验有没有被企业和服务团队共同沉淀下来。
这条路并不轻松。
因为企业AI转型里最难处理的部分，往往没有标准答案。你需要在业务价值、技术可行性、交付成本和组织现实之间不断做判断。有时候还要明确告诉客户，这个需求现阶段不值得做，或者应该先处理流程和数据，再谈AI。
但我觉得，这恰好是FDE的价值。
模型会继续进步，开发工具会继续降低门槛。今天看起来复杂的技术，过一段时间可能就会成为平台里的一个标准功能。
企业现场那些没有被说清楚的问题，却不会自动消失。
总要有人走进去，看清楚这段业务到底怎样运行；总要有人愿意把技术、流程和人接起来，直到系统真的能够工作。
我现在越来越少问：
“这个模型能不能做？”
我更愿意问：
“这段业务，能不能因为AI被重新设计？”
这大概就是我理解的FDE。
它不是站在企业外面描述AI的未来，而是走进今天的业务现场，把未来一段一段接上去。