2
0FDE的价值，不止是驻场把项目做完，还要把客户现场的发现变成产品能力。今天讲清楚：企业建这个岗位，到底该交付什么。FDE是前向部署工程师，关键不是这个名字有多新，而是它有没有把业务现场和产品迭代接起来。
### p02 同一个岗位名，可能是不同工作
Vinoo Ganesh在介绍自己的经历时提到，不同公司都叫FDE，工作却可能完全不同。有的是售前工程师，有的是能写代码的销售，有的是驻场做定制交付的人。所以你不能只抄一个岗位名称。先问清楚：这个人对什么结果负责，能改什么，以及项目结束后要留下什么。
### p03 产品与现场之间，断在哪里？
传统模式里，产品团队在总部，客户团队在现场。需求经过几次转述，常常只剩下功能列表。真正影响交付的，可能是数据里的空值、夜间的例外审批，或者员工依赖的一张表。原文里的银行案例就是这样：系统符合设计要求，却没有在真实生产数据中跑过。缺口在设计与日常运行之间。
### p04 Project Frontline：让产品工程师走进现场
一个具体参照是Palantir的Project Frontline。作者说，约二百五十人参加过这个轮岗项目，把软件工程师带到客户现场。值得学的并不是人数，而是机制：产品工程师亲自接触真实问题，再把发现带回产品团队。这个数字来自作者的经历回顾，不能用来证明所有公司照做都会成功。
### p05 FDE 怎样形成产品反馈回路？
我会把这套工作拆成一个回路。先在现场观察操作和例外，再做出能运行的结果。接着区分哪些是客户个性配置，哪些暴露了产品的共性缺口。最后，把共性能力放回平台，并在新的部署里验证。只解决这一次问题，是完成了一项交付；让下一次交付也受益，才产生了产品积累。
### p06 归哪个部门，取决于服务谁
这里要区分两种情况。对于对外卖产品的公司，作者建议FDE成为产品团队的延伸，而不是只围着签单转。对于传统企业自己的AI转型，我更建议业务负责人牵头，技术团队共同承担责任。不能简单规定所有FDE都归同一个部门。真正要明确的是：谁负责业务结果，谁有权改产品或流程，以及反馈往哪里去。
### p07 考核时，同时看结果与积累
考核也要跟着变。除了项目有没有交付，还要看流程周期和质量有没有改善，业务人员是否真的在用。再看共性规则有没有被整理，组件能不能复用。最后，检查这些改进在后续项目里是否成立。如果只考核驻场天数和交付数量，团队很容易忙着救火，却没有时间建设长期能力。
### p08 今天就能启动的一个小试点
今天可以先找一位懂核心业务的人，再找一位懂数据或AI的技术骨干。一起观察一个卡住的流程，画出实际步骤，记录规则、数据和例外。试点开始前写清楚两项交付：业务问题要改善什么，哪些经验要留下来复用。先把这个小回路跑通，再决定要不要建团队。关注AI落地实践，我们继续拆解企业里的具体问题。
