企业AI大转向：模型公司扎堆把工程师派进客户现场

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看， 传送门https://blog.csdn.net/HHX_01

前言

先说个反常识的事儿。

2026年，最会做AI的那几家公司，像约好了一样，全都开始往客户公司里塞工程师。

5月4日，Anthropic拉着Blackstone、Hellman & Friedman、高盛，成立了一家企业AI服务公司。看这股东阵容，不知道的还以为是来搞并购的。

一周后，OpenAI发布了Deployment Company。新公司由OpenAI控股，初始投资超过40亿美元，还打算把Tomoro那150名FDE连人带经验一起收进来。

6月30日，AWS宣布投入10亿美元，组建Forward Deployed Engineering团队，把几千名工程师派到客户现场。

两天后，微软公布Frontier Company：25亿美元，6000名行业和工程专家，跟客户一起设计、部署、持续改进AI系统。

四条新闻挤在不到两个月里。

你要是还觉得是巧合，那我建议你先去买张彩票，你这运气放哪都亏不了。

要知道，以前模型公司最风光的时候，全在发布会上。参数更大、推理更强、上下文更长、Coding排名又涨了。

发布会一开，股价一涨，PPT一关，睡觉。

到了2026年，最有能力训练模型的公司，开始大规模派人进客户企业。

这事甚至有点反硅谷。

硅谷最喜欢的商业故事，一直是产品化和规模化：代码写一次，服务全世界，边际成本一路往下掉，最好销售和交付都能省掉。

FDE偏偏走了一条最重的路：工程师进现场，面对客户攒了十年的系统、乱成一团的数据，还有部门之间永远说不清的责任边界。很多问题，连需求文档都写不明白。

模型越强，现场的人反而越多。

这账到底是怎么算的？

1. Palantir很早就把这条路走了一遍

1.1 坐在办公室里的工程师，只能靠猜

FDE全称Forward Deployed Engineer，部署在现场的工程师。Palantir的正式叫法更长一点：Forward Deployed Software Engineer。

这套模式，是Palantir创业早期一点点长出来的。

它最早服务情报和国防机构。那里的用户完全不按互联网公司的流程出牌：没有PRD，没有评审排期，任务一天三变，安全权限多到能写一本书。

分析员手里一堆割裂的数据，判断全靠现场经验，很多需求根本没法提前写清楚。

工程师坐在Palo Alto的办公室里，靠几场视频会议，只能猜。猜错了怎么办？这么说吧，人家的"测试环境"，可能是真现场。

于是，他们被送进政府办公楼、军事基地和一线运营环境，跟真正用系统的人一起干活。

Palantir后来回顾这段历史时写得很直白：只有贴近操作者，才知道软件到底有没有用。

1.2 现场交付，主要靠三拨人

第一拨人叫Echo，对应Deployment Strategist，先把问题找对。

他要跟业务负责人、一线操作者一起捋任务，找到影响结果的关键环节，再定成功标准。

很多企业项目，第一步就偏了。客户说要个大屏，其实缺的是异常处置流程；客户说要做知识库，真正卡住的是信息散落、权限混乱、责任不清。

翻译成人话：客户以为要买的是块屏幕，实际要的是"出了事有人管"。

Echo的价值，就是把"客户想买什么"，追问到"业务到底要解决什么"。

第二拨人叫Delta，就是Palantir内部对FDSE的称呼，在现场把系统跑起来。

接数据、配平台、写代码、做集成、搭应用，跟最终用户一起反复试。

项目成没成，不看交付文档写了几页，只看业务目标有没有变化。

这岗位的边界宽到什么程度？数据工程、后端、前端、产品判断、客户沟通，一个人全包。

在普通公司，这叫"一人多岗，年底多发点"；在Palantir，这叫"一人多岗，这是成长"。

现场情况一变，他还得当场拍板：先修哪个、拒绝哪个、哪个能力值得回传给产品团队。

说白了，这是个随时要"现编需求"的岗位，需求文档是现场长出来的。

第三拨人叫Dev，是总部的核心产品和工程团队。

他们建设Foundry、Gotham、AIP、Apollo这些产品，还有Ontology、连接器、权限、安全、持续交付这些底座。

Delta在一个客户现场踩的坑，可能几十家企业都会再踩一遍。

Dev就把其中可复用的部分抽出来，做成平台能力，再还给更多现场团队。等于别人把学费交了，你直接看答案。

1.3 一个循环，叫"人的反向传播"

这三层转起来，长这样：

现场发现问题
 ↓
现场交付结果
 ↓
总部沉淀能力
 ↓
能力重新回到现场

Palantir管这个叫"人的反向传播"。

名字听着挺高级，内核其实特别朴素：一线工程师尽量靠近问题，把真实反馈传回总部，平台再根据反馈持续进化。

跟训练模型唯一不同的是，这个"损失函数"是客户当场给的，一点情面不留。

1.4 怎么判断一家公司有没有真FDE能力

看三件事：

1. 现场是不是围着可衡量的业务结果转；
2. 总部有没有够硬的平台和产品能力；
3. 项目经验能不能回流，下一次交付是不是站在更高的起点上。

少了后两条，现场团队很容易退回传统驻场开发：每个客户从头定制，经验全留在个人脑子里，人一走，能力也跟着走。

职位名换成FDE，交付方式没变，价格倒是可以先涨一轮。

这招我熟，跟简历里把"熟练"改成"精通"一个原理。

2. 为什么到2026年，AI把这笔账算通了

2.1 工程师这边：脏活累活终于有人搭把手了

现场交付有大量"脏活累活"：分析陌生代码、写系统适配器、整理数据、补测试、查接口、生成迁移脚本、梳理文档。

以前一个小团队要忙好几周。

现在，一个经验丰富的工程师配上Coding Agent，很多任务可以并行推进。

AI给优秀工程师加了一个很大的杠杆——顺便也给他们的错误判断加了个更大的杠杆。

这大概就是传说中的：大力出奇迹，也大力出事故。

这岗位也因此更挑人。

只会写明确需求的人干不了：现场经常没有完整需求，甚至没人知道问题到底出在哪。

FDE需要项目经验、工程能力、业务判断，还得手勤。

AI能把他的想法快速变成系统，也能把他的错误判断放大得更快。

不过这里其实藏着一条给资深工程师的新路。

你攒了十年的系统经验、踩坑经验、业务理解，以前在算法面试卷上根本体现不出来。

到了客户现场，这些经验恰好决定项目能不能落地。

面试官不认的东西，客户认。三十年河东，三十年河西，该你翻盘了。

2.2 企业AI项目这边：调API容易，进流程难

调用模型API，三分钟。

把一个Agent接进企业核心流程？麻烦才刚刚开始。

它得知道数据在哪、能调哪些工具、谁有权限批、失败怎么回滚、输出谁检查、操作怎么审计。

它还要面对十年前的老系统、没人敢动的数据库、写了一半的接口文档，以及各部门之间永远说不清的责任边界。

这些问题，没有通用Prompt。

你prompt写得再花，权限矩阵也不会因为你写得好就自动消失。

Anthropic在介绍企业AI服务公司时举过医疗机构的例子：工程师要和医生、IT团队坐在一起，先找到医生每天的时间消耗在哪，再把Claude嵌进他们已经习惯的流程。

OpenAI对Deployment Company的描述也很具体：FDE会连接客户的数据、工具、控制体系和业务流程，再把系统放进日常工作。

说到底，模型能力要穿过一长串现实约束，最后才能进入财务报表。

中间哪一环断了，前面全部白干。

2.3 模型公司这边：光卖Token，看不到反馈

只卖Token，模型厂商看不到客户内部最关键的反馈。

一个Agent在演示环境里人模人样，进了生产系统，可能因为权限、数据质量、延迟和组织流程当场翻车。

FDE进现场以后，模型厂商才能看见能力缺口到底在哪：工具调用不稳定、长任务容易跑偏、权限粒度不够、评测体系覆盖不到实际风险，还是用户压根没改工作方式。

这些反馈，会进模型、进平台、进产品路线图。

对模型公司来说，FDE同时承担两种功能：帮客户产生结果，也帮自己理解下一轮产品往哪走。

派出去的是工程师，收回来的是情报。这笔买卖怎么算都不亏。

3. 为什么连OpenAI都愿意做这么重的生意

商业上的账，其实很直接。

单纯卖模型，收入来自调用量。

客户用AI多赚了几千万，模型厂商最后拿到的，可能只是一小部分Token费。

这感觉就像你开饭店，客人靠你的招牌天天爆满，你只能收个茶水钱。

进入业务现场以后，定价逻辑就变了。

客户关心的是销售转化提升了多少、客服成本下降了多少、供应链周转快了多少、一个流程从几天缩到几小时。

项目围着这些指标转，预算也更容易进入业务部门和管理层的视野。

这也解释了，OpenAI的Deployment Company为什么要引入大量私募股权机构、咨询公司和系统集成商。

技术只是其中一段，后面还有流程改造、人员培训、激励调整、持续运营。一个人的活，总得有人一起干。

OpenAI出模型和部署能力，合作方出行业关系、组织改造和规模化渠道。

Anthropic、AWS、微软选的路径略有差异，方向却很接近：把工程师放进客户的真实约束里，盯着可衡量的业务结果做交付。

企业AI的竞争，已经从"谁的模型更聪明"，打到了"谁能把聪明变成产出"。

4. 别急，这个词马上就会被用烂

任何概念火起来之后，第一批出现的永远是改名。

驻场开发改名FDE；做一个聊天框，也叫企业AI转型；给客户装几个开源组件、配几个Skills，项目就算交付了。

FDE的下限确实很低，甚至比传统外包更好包装，因为AI自带一层新鲜感。

就像换了个发型，就觉得自己换了个脑子。

想知道一家公司是不是真走通了这条路，问四个问题：

1. 项目目标是谁定义的，IT负责人还是业务负责人？
2. 交付团队能不能直接碰生产数据、真实流程和一线用户？
3. 现场发现的共性问题，能不能进入平台和产品？
4. 项目结束后，客户获得了持续运行的能力，还是继续靠人肉驻场？

这四个问题答不上来，FDE就只是一张新名片。

放心，这种名片一般还印得特别高级。

Palantir的壁垒，也从来不是一群能驻场的工程师。

它有现场角色，有硬平台，有持续回流的产品机制，还有攒了多年的行业经验。

Echo、Delta、Dev三层同时转起来，才把重交付做成了可以复利的生意。

5. 发布会定情绪的时代，过去了

2023年，模型发布会决定行业情绪。

2026年，部署能力开始决定企业订单。

OpenAI、Anthropic、AWS、微软大规模投入FDE，说明企业AI已经走过了"接一个模型试试看"的阶段。

接下来要处理的是数据、系统、流程、权限、组织和利益。每一项都很具体，每一项都很难靠远程售前解决。

FDE+AI的价值也在这：AI放大现场工程师的生产力，FDE把模型嵌进业务，现场经验再推动平台迭代。

这个循环一旦转起来，交付速度和产品能力会同时增长。

当然，派工程师进企业并不保证成功。

模型公司能给更强的能力，FDE能把手伸进业务现场，企业内部照样可能把项目做砸。

老板的预期、项目由谁负责、员工为什么愿意配合，这些问题往往比技术难处理得多。

技术问题有标准答案，人的问题没有。

下一篇聊聊：企业AI落地成功率为什么不到50%，以及最常见的三个坑。

先把瓜子准备好。

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01