企业说想要一个 AI 系统时，需求往往还没有成形。有人希望少做重复录入，有人想更快响应客户，也有人只是发现旧流程已经跟不上业务。FDE 要处理的，正是这些想法与可运行软件之间的距离。
先理解这个角色
FDE 是 Forward Deployed Engineer，通常译作前线部署工程师。Palantir 对相近职位 FDSE 的介绍强调：工程师贴近客户，把平台能力组合成可用的解决方案，同时把现场经验反馈给产品团队。这个描述来自特定公司的实践，并不是所有 FDE 岗位的统一定义。[1]
在 Terriva 的理解中，这种工作方式值得借鉴的部分，是让理解问题的人持续参与交付。需求访谈、接口设计、原型验证和上线后的反馈，不应成为彼此断开的几段工作。工程师需要知道用户为什么需要这个功能，业务负责人也需要看见技术边界在哪里。
把“做什么”写成一个可观察的结果
假设车辆运营团队提出“做一个智能客服”。这句话可以指知识问答，也可以指行程查询、回复草稿或自动处理异常。项目真正需要的第一份材料，是一张结果说明：谁在什么时刻遇到什么问题，现在怎么处理，系统介入后希望发生什么变化。
例如，将目标收窄为“客服打开一条咨询时，可以同时看到正确的行程资料和有出处的回复建议”。这个目标对应了明确的界面、数据和验收动作。它不承诺自动处理全部问题，却能让双方快速判断第一版是否值得继续。
让技术决定接受业务检验
如果每次查询都要等待很久，即使答案正确，也可能打断服务节奏。如果资料更新慢，界面再流畅，员工仍然会回到原有系统核对。FDE 需要把模型质量、数据新鲜度、操作成本和人工责任放在同一张桌面上讨论。
我们建议每个重要技术选择都附上一句业务理由。例如，保留人工确认，是因为回复涉及费用争议；先接只读接口，是因为当前阶段需要验证资料是否匹配。这样做能避免团队用工具名称代替判断，也让后续调整有依据。
现场经验需要留下来
一次项目结束时，除了能运行的代码，还应留下三种可以复用的东西：经过确认的业务规则、能够重放的测试样例，以及清晰的故障处理路径。它们分别回答系统依据什么工作、如何判断改动是否有效、发生异常时谁来接手。
FDE 的价值可以从这些细节衡量：业务人员能否独立使用，接手的工程师能否解释系统行为，下一次相似需求能否少走弯路。贴近现场是一种工作方法；最终交付的系统，应当逐渐减少对某一位工程师的依赖。
项目启动时，先共同写下一句话：哪一位使用者，在什么场景下，能够完成哪一件以前难以完成的事。
参考资料
本文结合公开资料与 Terriva 的方法建议整理。文中的假设场景用于说明设计思路，不代表客户实绩。