FDE 是什么

FDE 是 Forward Deployed Engineer，常译为前线部署工程师或前置部署工程师。它不是单纯的售前、实施、算法或后端岗位，而是一个对真实业务结果负责的工程角色。

OpenAI 的官方岗位说明把职责描述为：与客户共同把前沿模型变成生产系统，负责需求发现、技术定界、系统设计、构建和生产发布，并用生产采用率、工作流效果及评测反馈衡量成功。这是本 Wiki 对 FDE 的基准定义。

一句话心智模型

FDE 在客户问题与产品平台之间工作，把模糊需求变成可运行、可评测、可运营、可移交的系统。

FDE 交付闭环

业务目标
  -> 现场发现与约束确认
  -> 可量化成功标准
  -> 数据与流程接入
  -> 原型和离线评测
  -> 小范围试点
  -> 安全、性能、成本治理
  -> 生产上线与采用
  -> 反馈沉淀到产品和平台

模型只是闭环中的一个组件。FDE 失败通常不是因为少知道一个框架，而是因为没有定义成功、没有可靠数据、没有处理权限边界，或没有把试点变成日常流程。

与相邻岗位的区别

岗位	主要优化目标	常见边界
FDE	客户工作流产生可衡量结果	端到端负责，常直接写生产代码
解决方案架构师	方案合理、产品能力匹配	通常不长期拥有应用代码和上线结果
售前工程师	技术验证与商业推进	交付深度通常止于 PoC 或方案
ML 工程师	模型训练、推理与数据管线	不一定负责客户流程和组织采用
后端/全栈工程师	软件功能、可靠性与迭代	不一定负责模型行为评测和业务发现
产品经理	需求、路线图和跨团队协调	通常不直接实现和运维系统

FDE 可以来自这些岗位，但需要补齐另外两端：工程师要学业务发现与沟通，产品或咨询背景的人要补生产级编码和运维能力。

能力地图

业务与交付

• 访谈用户，找出高频、昂贵、可验证的工作流。
• 把“做一个 AI 助手”改写为输入、输出、责任人、时延、质量和风险指标。
• 管理范围，先交付最小闭环，再扩大权限和自动化程度。
• 让业务、IT、安全、法务和数据负责人共同签署验收标准。

软件工程

• Python 或 TypeScript，HTTP API、队列、缓存、数据库和身份认证。
• Git、测试、容器、CI/CD、日志、指标、追踪和故障处理。
• 了解已有系统的接口、数据模型、权限与失败语义。

AI 工程

• 模型路由、提示词、结构化输出、工具调用和上下文工程。
• RAG 的切分、Embedding、检索、重排、引用和权限过滤。
• 离线评测、线上观测、红队测试、成本和时延优化。
• 开源模型部署、量化、LoRA/QLoRA，以及何时不该微调。

现场判断力

• 能在质量、速度、成本和安全之间做显式取舍。
• 能区分模型错误、检索错误、工具错误、数据错误和产品设计错误。
• 遇到不确定行为时先增加可观测性和最小复现，而不是立即更换模型。

成功标准

一个合格 FDE 项目至少同时满足四类指标：

维度	示例
业务	单次处理时间、自动完成率、采用率、人工复核量
质量	任务通过率、事实准确率、引用正确率、严重错误数
工程	P95 时延、可用性、失败重试率、恢复时间
治理	越权访问数、敏感数据泄露数、审计覆盖率、人工审批覆盖率

只展示几条漂亮回答不算交付。能够被真实用户稳定使用，并且知道系统何时失败，才算进入生产。

你是否适合 FDE

适合：喜欢进入陌生业务、快速建模问题、亲手实现、面对用户反馈，并愿意为上线后的效果负责。

不太适合：只想研究单一算法、排斥需求变化或客户沟通、只完成分配任务而不愿承担结果，或无法接受现场环境的权限与历史系统限制。

延伸阅读

• OpenAI FDE 官方岗位说明
• Anthropic FDE 岗位列表
• Anthropic 与 DXC 的前线部署合作

一个真实项目日是什么样

FDE 的时间很少被单一类型的任务占满。一个上线前工作日可能这样展开：

时间	现场动作	需要留下的证据
09:00	和业务负责人复核昨天的 12 条失败样本	标注后的失败分类与业务影响
10:00	重放请求，定位是检索缺失还是模型未遵循	完整请求、上下文、响应、trace ID
11:30	与安全团队确认新数据源的字段级权限	数据流图与权限矩阵
14:00	修改检索过滤与输出 schema，补回归用例	可审查的代码、配置和测试结果
16:00	用固定流量模型跑容量测试	TTFT、TPOT、吞吐、显存、错误率
17:30	决定是否扩大灰度，并同步风险	决策记录、阈值、负责人和回滚步骤

关键区别是：每次讨论都要落到可以运行、测量或审计的对象，而不是只留下会议结论。

能力自评量表

给每项打 0 到 3 分：0=不了解，1=能在指导下完成，2=能独立完成，3=能设计标准并带人交付。

能力	自测任务	达到 2 分的证据
需求定界	把“知识助手”改写为可验收目标	一页范围、反目标、指标与负责人
API 与集成	接入一个真实业务系统	有超时、重试、幂等、错误处理和测试
模型选择	比较至少三个候选模型	固定数据集上的质量、速度、成本报告
RAG	从文档到带引用回答	检索和生成分层评测，可定位失败
部署	发布一个可持续运行的端点	固定版本、健康检查、监控和回滚
安全	处理权限与提示注入风险	最小权限、审计日志、攻击用例
运营	处理一次模拟故障	告警、分级、止损、复盘和改进项
商业判断	说明为什么值得做	基线成本、预计收益、投入和停止条件

总分不是招聘标准。低分项决定下一次实践项目应该刻意训练什么；如果只有模型和提示词得分高，仍不能独立承担生产交付。

新手最容易遗漏的三类工作

组织工作明确谁拥有数据、谁批准高风险动作、谁在故障时做业务决策。

证据工作保留版本、输入、输出和指标，使每个结论都能被另一位工程师复现。

退出工作在开始时就定义停止条件、人工兜底、降级和回滚，不把上线当作单向门。

本章实践

选一个你熟悉的流程，用 30 分钟写出：当前人工步骤、最昂贵环节、可接受错误、不可接受错误、数据负责人、三项验收指标。然后删除所有无法观测的形容词，例如“智能”“准确”“体验好”。剩下的内容就是项目定界初稿。