这张卡给「驻场」正名：它描述位置，不描述能力，更不等于 FDE。
核心拆解：驻场只覆盖物理位置与协作密度两个变量，交付手段与责任结构是另外两个独立变量。最容易误用的判断是「天天驻场，所以我已经是 FDE」——国内大量实施顾问、驻场运维、外包开发都驻场，但解空间是产品配置、责任是工时交付，与 Forward Deployed Engineer（FDE）的责任闭环并不相同。
增量判断：多数讨论聚焦硅谷 AI 公司，这张卡把驻场放回国内 toB 二十多年的驻场传统里看：驻场不新鲜，新鲜的是驻场者手里有代码与评测权。差旅成本、人员单点、边界管理等驻场老问题在 FDE 模式下同样存在，而且常被低估：这些问题要在结构上解决，靠个人自律靠不住。
行动建议：写 JD 或自我介绍时，把「驻场」从能力描述里删掉，换成你交付什么、对什么负责。面试时这也是检验对方交付成熟度的好问法。记住这个判断次序：先看责任结构，再看工作地点，顺序反了就会误判。
—— FDEChina编辑部 · 实战派
定义
驻场交付指工程师长期在客户办公场所工作、以客户环境为主要工作现场完成系统建设与上线的协作方式；Embedded Engineer（嵌入式工程师/驻场工程师）是强调这种嵌入状态的英文说法。
展开
驻场只描述「人在哪」，不描述「怎么交付、对什么负责」。国内 toB 行业有二十多年的驻场传统：实施顾问、运维外包、定制开发人员都长期驻场。Forward Deployed Engineer（FDE）与驻场角色的相似只在物理层面——真正差异是工程手段（用代码、评测与自动化解决问题，而非产品内配置）与责任结构（对业务结果闭环负责）。把「驻场」写进 JD 就以为招到了 FDE，是当前招聘市场最常见的误用。
驻场交付本身的管理难点也不因 FDE 名号而消失：客户临时需求缺乏闸门导致范围蔓延、差旅与人力成本核算、单人单点带来的知识孤岛与流失风险。实践上，驻场安排应与影子期、知识转移和明确的升级路径配套，否则嵌入越深，交接越难。