夜雨聆风最近， FDE 这个岗位突然热了起来。
FDE ，全称 Forward Deployed Engineer ，常被翻译成前沿部署工程师。名字有点绕，说人话就是：工程师不只在公司里写平台，而是直接进入客户现场，把模型接进真实的数据、权限、工具和业务流程里，直到系统能跑起来。
今年 5 月， OpenAI 专门成立了一家 Deployment Company ，首期投入超过 40 亿美元，还计划通过收购 Tomoro 一次性补进约 150 名有经验的 FDE 和部署专家。 6 月， AWS 也宣布投入 10 亿美元建设 FDE 组织，要让数千名工程师进入客户环境共建智能体系统。
AWS 发布面向合作伙伴的 Forward Deployed Engineering 计划。图源： AWS
模型公司和云厂商同时往现场派人，说明企业 AI 的竞争已经从“谁的演示更聪明”，转向“谁能把东西真正装进公司里”。
但反过来看，这件事也暴露了一个不太好听的事实：很多所谓 AI 产品，离真正的产品化还很远。
如果一个产品每卖给一家客户，都要重新派一队昂贵工程师驻场几个月，我们就得问一句：客户买到的究竟是软件、咨询，还是一个靠人肉维持的半成品？
FDE 不是售前，而是站在产品缺口里的人
先别急着把 FDE 理解成高级售前。
按照 OpenAI 对这个岗位的定义， FDE 负责的是从原型到稳定生产的完整交付：直接写代码，处理跨团队问题，识别可复用模式，再把一线反馈带回产品和研究团队。 Palantir 对 FDE 的描述更形象：工程师贴近客户问题，把现场信号持续反馈给核心研发，像是产品系统里的“人类反向传播”。
FDE 把客户现场信号持续反馈给核心产品。图源： Palantir
这跟传统售前的区别很大。
售前的主要目标，是证明产品能解决问题。 FDE 的目标，是在客户真实的限制条件下把问题解决掉。权限不通，他要处理；旧系统没有接口，他要想办法；模型准确率在演示里不错，进了生产却不能用，他也得把评测和兜底补起来。
所以 FDE 变多，首先说明需求是真的。企业不是不想用 AI ，而是仅有模型还不够。
企业里的知识散落在文档、数据库和员工脑子里；一个审批流程可能穿过五套系统；同一句“可以自动处理”，到了金融、制造和医疗行业，背后对应的权限、审计和失败代价完全不同。
OpenAI 的企业 AI 报告把规模化部署需要的能力归纳为几类：深度系统集成、工作流标准化与复用、数据准备与持续评测，以及组织层面的变革管理。换句话说， API 接通只是开始，后面的活才真正麻烦。
FDE 就站在这堆麻烦中间。
真正的问题，不是“有没有驻场”
看到这里，很容易得出一个简单结论：需要 FDE 的公司不是软件公司，而是咨询公司。
这个判断太早了。
复杂企业软件在新品类早期，本来就需要工程师贴近客户。因为客户经常说不清自己的流程，厂商也不可能坐在办公室里凭空设计出适合所有行业的抽象层。 FDE 能把混乱的现场问题翻译成产品能力，这恰恰可能是产品化的起点。
AWS 在介绍自己的 FDE 方法时，反复强调两件事：客户最终应该能够自给自足；每次项目都要沉淀可复用的“交付底座”，包括领域本体、评测框架、 MCP 服务器、智能体运维工具和架构记录。
注意这个顺序：先靠人解决，随后把人的经验变成产品。
因此，真正的分界线不是“有没有人驻场”，而是：每做完一个客户，下一个客户会不会更容易交付。
如果答案是会， FDE 是产品的学习系统。
如果答案是否，每个客户仍然要从头分析、从头开发、从头救火， FDE 就变成了人肉补丁。公司表面卖软件，实际收入仍被工程师人数锁死。
用五个指标，判断产品到底熟没熟
不管你是买企业 AI ，还是在做企业 AI ，都可以用下面五个指标判断产品化程度。
一、交付周期有没有持续缩短
第一家客户做六个月并不可怕。可怕的是做到第二十家，仍然要六个月。
应该观察同类客户从签约到上线需要多久，随着客户数量增加，这个时间是否明显下降。如果每一次都被解释成“客户情况特殊”，大概率不是客户都特殊，而是产品还没有形成稳定边界。
二、定制代码是在减少，还是越堆越多
定制并不等于失败。真正危险的是，定制代码只对单个客户有效，而且无法进入公共组件。
健康的路径应该是：第一家写代码，第二家把代码改成配置，第三家可以通过模板完成。数据连接器、权限模型、评测流程和异常处理，都应该逐步从项目代码变成标准能力。
三、项目结束后留下了什么
一个项目除了“成功上线”，还应该留下可以复用的资产。
比如行业数据模型、工作流模板、评测集、权限策略、 MCP 工具、监控规则、失败恢复方案。下一个 FDE 团队能不能直接拿来用，比这次项目做了多少酷炫功能更重要。
如果项目结束后只留下几份汇报材料和一堆只有原作者看得懂的脚本，那不是产品资产，只是交付痕迹。
四、客户能不能逐渐离开 FDE
一个成熟产品不一定完全不需要服务，但客户应该越来越能自己完成配置、评测、上线和日常排错。
可以直接问厂商：上线三个月后，还需要多少驻场人力？模型升级后谁负责回归测试？新增一个相似流程，是客户自己配置，还是必须重新排项目？
如果 FDE 永远撤不走，说明系统的可操作性还掌握在少数专家手里。
五、收入增长是否仍依赖同比例增加人头
这是最诚实的一项。
如果收入翻一倍，交付团队也必须翻一倍，这门生意更接近项目服务。如果收入增长远快于部署人力，说明现场经验正在被软件吸收，平台开始产生复用和规模效应。
当然，不能只看 FDE 人数，更不能用“有人驻场”直接判死刑。 Palantir 长期采用 FDE 方法，但其提交给美国证券交易委员会的 2025 年年报显示，公司当年毛利率达到 82%。这个例子至少证明了一点：重现场工程与高毛利软件可以同时存在。
关键仍然是，人在现场创造的是一次性劳动，还是下一轮可以复用的产品能力。
企业买 AI ，也要换一种问法
过去采购软件，企业喜欢问功能清单：有没有知识库，有没有智能体，支持多少模型。
到了 FDE 时代，更重要的问题变成了交付结构。
你可以要求厂商说明：标准产品覆盖多少工作，定制部分占多少；哪些定制会进入公共产品，哪些永远由客户承担；项目完成后如何交接；出现模型漂移、权限变化和业务规则调整时，谁负责维护；相似客户的第二次部署，究竟复用了什么。
这些问题听起来没有模型参数性感，却决定了项目上线之后会不会变成一个长期填不完的坑。
对 AI 创业公司来说，也应该把 FDE 当成一面镜子。
FDE 最有价值的产出，不是又救活了一个大客户，而是发现三个客户背后其实是同一个问题，并把它变成平台里一个所有人都能用的按钮、一套默认评测，或者一个稳定接口。
要是每个大客户都被当成“战略项目”，所有问题都靠最优秀的工程师临场发挥，公司会显得非常忙，案例也会很多，但产品未必真的在进步。
FDE 越火，并不说明企业 AI 没有价值。恰恰相反，它说明大家已经不满足于做演示，开始啃真实流程里最硬的部分。
只是，现场工程不能成为终点。
真正值得买、也值得长期做的 AI 产品，应该让今天驻场的经验，变成明天不必再驻场的能力。