QUOTE
项目交付了什么，只能证明一次结果。项目留下了什么，才决定它是产品还是人力生意。
星阙运营小助手
FDE 火起来以后，一个质疑也跟着出现。
工程师进驻客户现场，听需求、改流程、写代码、赶上线。项目结束以后，团队撤走，再去服务下一家客户。把职位名称遮住，这套工作方式和传统外包很像。
于是有人问，FDE 会不会只是外包换了一件更适合 AI 时代的衣服？
这个问题并不刻薄。许多公司嘴里说着 FDE，实际交付时依然按项目派人。客户提需求，工程师接单，项目经理盯进度。客户的问题解决了多少没人继续追，现场发现的共性问题也没有进入产品。
如果工作停在这里，FDE 确实很难证明自己和外包有什么区别。
可把所有客户现场工作都归为外包，也会错过 FDE 最有价值的部分。两者在项目现场很相似，项目结束以后才会逐渐拉开差距。
本文看点
01
真假边界
02
经验去向
03
四问判断
01
BOUNDARY
### FDE和外包为什么越来越像
这场争论先要承认一个事实。FDE 与外包本来就有大片重合区域。
两者都要面对客户，都要处理标准产品覆盖不了的问题，也都可能为某个客户写定制代码。它们还会遇到同一类麻烦。需求反复变化，客户内部意见不一，旧系统缺少接口，数据质量差，管理层又希望尽快看到结果。
企业购买普通软件，厂商可以交付账号、功能和培训。企业购买 AI 能力，交付边界没有这么整齐。模型要接进知识库、业务系统和审批流程，权限、安全、评测与人工复核都要重新安排。
OpenAI 对 FDE 的岗位描述覆盖需求发现、技术范围确认、系统设计、构建和生产上线。Scale AI 的类似岗位也要求工程师进入客户环境，从原型一直负责到稳定生产。
这些工作与技术咨询、解决方案工程和定制开发都会相遇。仅凭驻场、写代码和对接客户，很难划出一条干净的分界线。
所以，“FDE 到底是不是外包”有时会变成一个假命题。它把两种并不互斥的东西放在了对立面。
外包描述的是一种交易和用工关系。企业把一部分工作交给外部团队完成。FDE 描述的是一种交付责任。工程师进入现场，参与定义问题，做出系统，并对使用结果负责。
一家外部服务公司可以采用 FDE 的工作方式。一家自称产品公司的团队，也可能把 FDE 做成按人天收费的驻场外包。名称决定不了业务。
02
AFTER DELIVERY
### 区别藏在项目结束以后
真正能拉开差距的时刻，往往出现在验收之后。
传统项目交付很容易在验收单上结束。需求清单做完，系统上线，款项收回，双方的责任暂时告一段落。团队在客户那里踩过的坑，最多留在项目经理的复盘文档里。
FDE 如果想成为产品公司的一部分，还要多走一步。它要判断现场遇到的问题有没有共性，能不能进入平台，下一位客户是否可以直接使用。
假设三家制造企业都需要把设备告警接入 AI 助手。第一家缺接口，第二家权限混乱，第三家要求每条建议都经过工程师确认。
项目团队当然可以分别完成三套定制方案。可当第三个项目结束，产品里依然没有通用连接器、权限模型、人工确认机制和评测方法，下一家客户仍要从头再来。这支团队交付了三个项目，却没有让产品前进一步。
相反，如果现场团队把反复出现的问题整理出来，产品团队再把它们做成可配置的能力，第四个项目就会变短。工程师可以把时间用在新的业务问题上，不必重新解决前三次已经见过的麻烦。
这才是 FDE 模式能够扩大规模的地方。
Palantir 一位从事 FDE 工作多年的员工曾在官方社区解释，Forward Deployed Engineering 更接近一种工作方式。团队深入客户现场，对结果负责，再把现场学到的东西持续带回核心平台。
这里的关键词是“带回去”。没有这个动作，前线与产品之间只剩一条单行道。产品把工程师派出去，客户把需求和问题交进来，经验却停在个人手里。
人员一离开，组织又从头学习。
03
PRODUCT
### 经验都要回到产品吗
说到这里，另一个假命题又出现了。如果经验没有变成功能，FDE 就算失败吗？答案未必。客户现场产生的信息，大致有三种去处。
第一种适合进入产品。多个客户反复遇到同一个问题，解决办法也相对稳定，例如数据连接、权限控制、人工复核、运行监控和回退机制。这些内容做进平台以后，可以降低后续交付成本。
第二种适合进入交付方法。有些问题无法变成一个按钮，却可以写成需求访谈表、评测流程、安全检查单和上线步骤。它们没有改变软件功能，却能让下一支团队少走弯路。
第三种只能留在客户现场。企业的内部审批、利益关系、特殊政策和历史系统往往高度具体。强行把这些内容塞进通用产品，最后得到的可能是一套谁都难用的复杂系统。
要求所有现场经验都产品化，本身就是一个假命题。好的 FDE 需要做筛选，决定什么值得复用，什么应该保持定制，什么只是一次偶然情况。
这项判断比“做完一个功能”难得多。它要求工程师同时理解客户业务与公司产品，也要求产品团队愿意接住来自一线的反馈。
04
ORGANIZATION
### 很多问题不该只怪FDE
现实里，经验回不到产品，责任经常被推给 FDE。
管理层会问，你们天天在客户那里，为什么没有总结共性需求？产品团队会问，为什么带回来的全是某个客户的特殊要求？前线工程师也会抱怨，现场已经忙到半夜，哪还有时间写文档和说服产品改路线？
三方都可能说得有道理。
经验从现场进入产品，需要一套组织安排。谁负责收集，谁判断共性，谁决定优先级，谁投入研发资源，谁验证新能力能否服务下一位客户。这些责任如果没人承担，靠 FDE 的个人自觉很难长期维持。
有些公司的考核也会把事情带向另一个方向。FDE 只对项目收入、上线日期和客户满意度负责，产品团队只对版本计划负责。一个人越快满足客户的定制要求，短期成绩越好。他若停下来推动通用能力，当前项目反而可能延误。
在这种机制下，公司一边要求经验进入产品，一边奖励所有人继续做定制。最后经验没有回去，并不奇怪。
因此，“FDE 有没有把经验带回产品”虽然是重要标准，却不能只用来评价个人。它也在检验一家公司的产品战略、协作方式和收入选择。
公司若主要靠项目费赚钱，定制交付本来就是生意。公司若宣称自己卖标准产品，却长期依靠大量 FDE 为每个客户重新开发，就要面对一个更难回答的问题。
它卖的究竟是产品，还是被产品包装起来的人力？
05
CHECKLIST
### 四个问题看清FDE还是外包
岗位名称容易包装，工作结果不太容易。
判断一支团队有没有做 FDE，可以连续追问四件事。
问题由谁定义。团队只是接收客户列出的功能，还是会进入工作流程，重新确认要解决的问题。
结果由谁负责。项目做到上线就结束，还是继续观察使用率、准确率、时间节省和业务变化。
经验去了哪里。它留在某个工程师的电脑里，还是进入产品、交付方法和团队培训。
下一次有没有变快。公司做完多个同类项目以后，后续交付是否更稳定、更便宜，也更少依赖少数高手。
前两个问题决定团队有没有超出执行外包。后两个问题决定这套模式能不能从项目生意走向产品生意。
如果四个问题都答不上来，FDE 很可能只是一个更漂亮的职位名称。
如果团队能够定义问题、对结果负责，又能让下一次交付少走一段旧路，那么它即使来自外部服务商，也已经具备了 FDE 的核心能力。
∞
THE END
### FDE是不是假命题
FDE 作为一个新职位，确实存在被过度包装的成分。
有些公司需要的是售前，有些需要项目经理，有些需要驻场开发，还有些只是缺人，却把所有岗位都装进 FDE 这个名字里。概念越热，边界越容易变宽，最后任何靠近客户的技术工作都能叫 FDE。
从这个角度看，FDE 可能是一个假命题。市场把几种早已存在的工作重新组合，再给它一个更有吸引力的名字。
可企业 AI 交付面对的难题并没有因此消失。模型能力、客户数据、业务流程和组织责任之间仍有大量空隙。总要有人把含糊需求变成可运行的系统，也总要有人把现场发现带回产品。
FDE 这个名称会不会长期存在，还很难确定。它承担的工作已经真实存在，而且会继续存在。
最终，区分 FDE 与外包的标准不会写在名片上。项目结束以后，再回头看一眼就知道了。
客户得到了一套能用的系统。产品有没有因此变得更好，下一支团队有没有因此走得更快，公司有没有减少对人肉定制的依赖。
如果答案始终是否定的，那些被称为 FDE 的人，做的可能仍是一门熟悉的外包生意。
参考资料
• OpenAI 前线部署工程师岗位说明
• OpenAI 前线部署相关职位列表
• Scale AI 前线部署工程岗位说明
• Palantir AI FDE 产品说明
• Palantir 社区关于 FDE 工作方式的讨论
END
我是星阙运营小助手，星阙是一个专注于 OPC（一人公司 / 超级个体）的投资与孵化平台。