02 FDE 与传统岗位的边界
章节目标
理解 FDE 与开发、算法、售前、实施、咨询、客户成功和运营顾问的差异，明确 FDE 的职责边界和协作方式。
为什么重要
FDE 容易被误解为“会写代码的售前”或“驻场实施工程师”。这种误解会导致组织把 FDE 放错位置：只让他做演示、救火或定制开发，而没有形成可复用产品和可衡量交付。
开篇案例：为什么“会写代码的售前”不够
一个 SaaS 公司在大客户售前阶段安排工程师做 AI Demo。工程师很快接入模型和客户样例数据，演示效果很好，销售顺利签单。但项目进入实施后问题暴露：客户真正要接的是内网系统，知识库有多级权限，审批流程跨三个部门，Demo 里的“自动生成报告”在生产中必须保留人工确认和审计日志。
如果组织只把这个人当售前，他的目标是“演示成功”；如果把他当传统实施，他的目标是“按需求上线”。FDE 的目标不同：他要在售前、PoC、Beta 和生产之间持续追问同一个问题：这个能力是否真正进入了业务流程，并产生可衡量结果？
这也是 FDE 与传统岗位的核心差别：他不是站在某一个职能边界内，而是对跨边界闭环负责。
岗位边界
| 岗位 | 常见关注点 | FDE 的不同 |
|---|---|---|
| 开发 | 按需求实现功能 | FDE 参与定义什么值得做，并对业务采用负责 |
| 算法 | 模型指标和训练效果 | FDE 关注业务结果、系统集成和可运维性 |
| 售前 | 成交前演示和方案讲解 | FDE 负责从原型到生产的交付闭环 |
| 实施 | 配置、部署、上线 | FDE 参与需求共创、架构设计和能力反哺 |
| 咨询 | 报告、诊断、建议 | FDE 交付可运行系统和评估结果 |
| 客户成功 | 使用、续约、满意度 | FDE 关注系统能力是否真正解决问题 |
| 运营顾问 | 流程优化和策略建议 | FDE 把策略落成数据、工具、权限和系统动作 |
FDE 的核心职责
- 发现高价值业务流程。
- 定义技术范围和上线边界。
- 设计 AI 系统架构。
- 编写或审查生产代码。
- 集成客户数据、工具和权限。
- 建立评估和可观测机制。
- 推动用户采用和业务复盘。
- 把客户现场经验反馈到产品路线图。
与 Applied AI Engineer 的关系
Applied AI Engineer 更强调应用 AI 工程能力，FDE 更强调客户现场和端到端交付。两者在许多公司高度重叠。
判断标准不是岗位名称，而是职责是否覆盖 discovery、scoping、system design、build、rollout 和 eval-driven feedback。
FDE 四角色（工作心法）
一个 PoC 周期内，FDE 常同时扮演四个角色——可一人多角，也可在小组中分工：
| 角色 | 核心问题 | 典型产出 |
|---|---|---|
| 业务咨询师 | 什么流程值得改、怎样算成功 | 访谈记录、JTBD、场景卡 |
| 架构操盘手 | 用什么架构、如何集成 | 架构图、工具清单、权限方案 |
| AI 驯化师 | 如何让模型稳定可用 | Prompt、RAG、评估样本、失败分类 |
| 监控运维官 | 如何上线、观测、回滚 | Trace、告警、上线门禁、运营手册 |
四个角色共同构成“懂业务、能搭建、会优化、可运营”的闭环。
FDE + AIBP 敏捷部署小组
AI 项目不宜单人英雄式开发。推荐最小敏捷小组：
| 角色 | 职责 |
|---|---|
| AIBP（AI Business Partner） | 定义业务好结果、Ground Truth、验收口径 |
| FDE | 智能能力交付、集成、评估、Demo 与 rollout |
| Data Engineer | 数据供给、ETL、权限与质量 |
| 业务一线专家 | 真实样本、异常场景、采纳判断 |
场景卡是 FDE 与 AIBP 的共同协议；没有 AIBP，FDE 容易缺 Ground Truth；没有 FDE，业务想法容易停在需求文档。
角色边界的判断题
判断一个岗位是不是 FDE，不要只看 title，而要看 JD 或项目职责是否包含以下信号：
| 信号 | 如果有 | 如果没有 |
|---|---|---|
| 参与客户发现 | 需要理解真实流程 | 可能只是交付开发 |
| 能写或审代码 | 需要亲自搭最小链路 | 可能偏方案/顾问 |
| 负责上线采用 | 关注用户是否真的用 | 可能只负责 Demo |
| 建评估样本 | 能证明效果 | 可能只靠主观验收 |
| 反哺产品 | 将现场经验沉淀为平台能力 | 容易变成一次性外包 |
用这张表看岗位，比纠结“FDE、Applied AI Engineer、AI Solutions Engineer”这些名称更可靠。
实操任务
把你所在组织或目标公司中的 AI 项目角色列出来，标注：
- 谁负责发现需求。
- 谁负责系统设计。
- 谁负责写代码。
- 谁负责验收指标。
- 谁负责用户采用。
- 谁负责上线后的问题。
交付物
- 一张角色边界图。
- 一张 FDE 协作接口表。
- 3 个需要 FDE 介入的关键节点。
常见误区
- 把 FDE 当成售后救火角色。
- 只要求 FDE 定制开发，不要求沉淀产品能力。
- 让 FDE 背商务指标，却不给工程权限。
- 把客户现场经验留在个人脑子里，没有反哺产品。
检查清单
- 是否能说明 FDE 和售前的差异？
- 是否能说明 FDE 和实施的差异？
- 是否能说明 FDE 为什么必须懂业务和工程？
- 是否能判断一个岗位是否真正是 FDE？