FDE 是 Forward Deployed Engineer 的缩写，中文常译为前线部署工程师。这类工程师靠近实际使用者，将业务问题转成可以运行的软件，并参与验证使用结果。Palantir 的公开岗位实践可以帮助理解这一角色的客户协作与工程属性。不同公司的职责安排会有差别，不能只凭岗位名称判断服务范围。
在小火堆的服务设计中，FDE 对应一种项目共创方式：业务方提供流程、资料和判断标准，交付团队负责方案验证、软件开发、系统接入及约定范围内的上线支持。具体人员、驻场安排和维护周期在项目范围中确认。
用一个售后助手说明工作内容
以下是方案示例，并非客户案例。某电商团队希望让 AI 帮忙处理售后咨询。立项时，要先分清三件不同的事：解释售后政策、查询订单状态、提交退款申请。它们的数据、权限和错误后果不同，不适合用一个笼统的“智能客服”需求统一验收。
第一期可以只开放政策查询与回复草稿。业务负责人确认有效政策，工程人员建立资料版本和查询入口，客服用历史问题检查回答。退款写入则作为后续独立范围，先明确审批人与订单系统能力。这样，企业能够对每一阶段是否值得继续投入作出判断。
企业应当要求哪些交付结果
| 企业的问题 | 应查看的项目材料 |
|---|---|
| 这期到底解决什么？ | 明确使用者、输入、输出及不包含事项的范围说明 |
| AI 回答能不能用？ | 有业务负责人确认的样本和逐条评测记录 |
| 怎样进入现有工作？ | 可访问的应用入口、接口说明和账号权限配置 |
| 出错由谁接手？ | 人工处理入口、问题负责人和恢复步骤 |
| 项目结束后怎么维护？ | 约定的交接清单、维护责任和变更机制 |
这些材料用于让项目可核验，不意味着每个项目都需要同样的文档数量。小范围验证可以用一张任务表起步，但关键结论需要留存。
什么情况下值得采用 FDE 协作
当目标场景依赖本企业的数据、流程和多个系统，且需要一边验证一边调整时，FDE 协作更有价值。例如销售材料需要引用内部产品版本，设备服务需要结合工单记录，教务问答需要区分不同校区的有效政策。
如果采购标准产品就能满足需求，先使用产品并完成必要配置也可以。若数据暂不可访问、没有业务负责人或无法安排试用反馈，应先补齐这些条件，再承诺工程范围。
FDE 是否意味着长期驻场
工作方式应由任务决定。流程观察、集中访谈或复杂联调可以安排现场协作；开发、评审和日常问题跟踪可以远程完成。项目中需要约定的是响应窗口、会议节奏、访问方式与责任人，而不是把到场天数直接当成项目效果。
企业准备合作时，可继续阅读团队职责如何分配和项目范围与预算怎么写，再了解小火堆 FDE 交付服务。