第一次听到 FDE（Forward Deployed Engineer，前置交付工程师）这个词，很多人的第一反应是“驻场开发”。这个理解只对了一半：驻场说的是人在哪，FDE 说的是责任边界在哪。
一个工作中的定义
我倾向于这样定义：FDE 是带着工程能力进入真实业务现场，对“能不能用”负责的人。
拆开有三层。第一层是现场：需求不在文档里，在某个业务人员每天的工作流里，在他抱怨的那句话里。第二层是工程：听完不能只写一份方案，要能改数据管道、写接口、调提示、部署一个能跑的东西。第三层是结果：不是“交付了文档”，而是“这个流程现在真的跑起来了”。
这三层同时成立时，才会出现 FDE 这个角色。少一层，就退化成别的岗位。
三个容易混淆的角色
不是外包
外包的核心是“按约定范围交付”，范围由甲方定，变更走流程。FDE 恰恰要在范围不清楚的时候进场，把模糊需求切成可验收的小块——这件事本身就是工作内容。外包怕变更，FDE 靠变更把问题问清楚。
另一个差别是决策权。外包通常不参与“做不做、先做哪块”的判断；FDE 必须参与，否则做出来的东西大概率不是现场真正要的。
不是顾问
顾问的产出是判断和建议，交付物是报告；FDE 的产出是能运行的系统。顾问说“建议先做知识库”，FDE 要回答“用哪些文档、切多大、谁来验收、下周能不能演示”。
这不是说报告没价值，而是两者对失败的定义不同：顾问的判断被证伪才算失败，FDE 的系统跑不起来就算失败。
不是驻场运维
驻场运维的目标是“别出事”，FDE 的目标是“让它能干事”。前者优化稳定性，后者优化可用性——把一堆能力拼成一个业务真的会用的东西，然后把它交出去，让别人能维护。
一个简单的判据：做完之后，如果人走了系统就没人敢动，那更像外包；如果人走了团队能自己改，那才像 FDE 该留下的东西。
一天的样本
没有两天是一样的，但节奏通常长这样：
- 上午在现场。看业务人员实际操作一遍，记下他跳过哪一步、在哪一步骂人。这两处通常就是真正的需求。
- 中午对数据。把刚拿到的样本导进来，检查字段缺失、格式混乱、敏感信息。数据不通，后面都是空谈。
- 下午写代码。不追求架构优雅，先打通最短链路：输入 → 处理 → 输出，能演示就行。
- 傍晚做取舍。今天砍掉什么、明天先做哪个、哪些问题要拉客户一起定。写进一页纸，第二天早上发出去。
你会发现，真正难的不是写代码，而是持续做取舍并且让相关的人知道你为什么这么取。
为什么这两年变得重要
模型能力在快速商品化。三年前做一个像样的问答系统要一支算法团队，现在一个有工程经验的开发者加上现成模型，两周能做出可演示的版本。瓶颈从“能不能做”转移到了“能不能接进真实业务”。
而真实业务长这样：数据散在五个系统里，格式不统一；流程有一半在人脑里；验收标准是“领导看着顺眼”。这些东西不会因为模型变强而消失，反而因为预期变高而更突出——大家见过好的演示，就更不能接受一个“技术上成立但没人用”的系统。
所以 FDE 的价值不在模型侧，在把模型能力翻译成现场可用的形状：砍到最小闭环、把脏数据变成可用输入、把“感觉还行”变成可重复的评估。
三项硬功夫
第一，把模糊需求变成可验收的实验。不是写一份大而全的方案，而是提出一个能在两周内被证伪的假设：“如果把这 200 份制度文档接进来，客服能在一个界面里查到答案，就算通过。”
第二，把脏数据变成可用输入。包括清洗、去重、脱敏、建索引，也包括判断哪些数据根本不该进来。这一步没有光环，但决定了后面所有效果的上限。
第三，在现场做取舍并留下可维护的东西。取舍包括范围、精度、延迟、成本；可维护包括部署说明、评估集、已知问题清单。演示结束那一刻，工作才完成一半。
它不适合什么场景
说清楚不适合，比说清楚适合更有用。
- 需求完全确定、边界清晰的标准交付。这种活按范围做更高效，不需要有人反复追问“你到底要什么”。
- 纯研究型探索。目标是验证一个方法是否成立，不要求两周内能用，节奏和 FDE 相反。
- 只需要人力的长期值守。那是运维或支持岗位，硬套 FDE 只会让双方都别扭。
- 组织不允许现场改东西。如果每一次改动都要走一个月的评审，FDE 最核心的“快速迭代”就失效了。
下一篇会写一个具体节奏：如果只有 14 天，一个 PoC 应该怎么排。