01 · FDE 知识体系
1. 定义
依据官网公开定义，FDE 是客户现场的 AI 交付负责人：统筹场景、技术、治理和采纳，推动 AI 系统进入生产运营；衡量标准不是“功能做完”，而是生产采纳、业务影响和复用资产。[S2][S3]
这一定义包含四层责任：
- 现场责任：理解真实角色、任务、流程、约束和例外。
- 价值责任：把“想要 AI”改写为有基线、指标和证据口径的业务假设。
- 系统责任：定义人机协同、数据/工具接口、权限、异常和验收边界。
- 采纳责任：推动试点、运营反馈、管理层决策和资产沉淀。
FDE 不必独自实现所有工程工作；其价值是“前台串联与结果闭环”，后台由 AI、数据、工程、安全、运维和平台团队提供专业支撑。[S3][S5]
2. 为什么 FDE 会出现
官网对企业 AI 失败的判断是：组织往往不缺能做原型的人，而缺少把战略目标、管理层预期、一线流程、异常处理、人机协同和工程交付统一起来的人。[S1]
典型断层如下：
| 断层 | 表面现象 | 实质问题 |
|---|---|---|
| 需求断层 | 客户说“做个智能体” | 没有真实任务、角色和触发条件 |
| 价值断层 | 只说节省时间 | 没有连接收入、质量、风险或组织能力 |
| 流程断层 | 把 AI 塞进旧流程 | 没重设责任、确认、升级和回退 |
| 评测断层 | Demo 看起来不错 | 没有真实样本、失败分类和上线阈值 |
| 治理断层 | 功能可运行 | 权限、审计、数据用途和责任边界缺失 |
| 采纳断层 | 系统上线 | 用户不改变工作方式，反馈不进入迭代 |
| 资产断层 | 项目结束 | 连接器、评测集和行业模板没有沉淀 |
因此，FDE 的问题域不是“模型能力”单点，而是：
现场事实 × 业务价值 × 人机协同 × 工程系统 × 评测治理 × 组织采纳
任何一项接近零，整体结果都可能失败。
3. FDE 与传统岗位的边界
| 角色 | 典型中心任务 | FDE 对其补充的部分 |
|---|---|---|
| 售前/解决方案 | 方案、演示、商务推进 | 把表层需求推进为可验证的生产闭环 |
| 咨询顾问 | 诊断、建议、治理推动 | 对可运行系统、评测证据和持续采纳形成闭环 |
| 产品经理 | 需求、优先级、产品规划 | 覆盖模型不确定性、异常流程、评测和生产治理 |
| 项目经理 | 范围、进度、成本、交付 | 对业务假设、采纳效果和复用资产同步负责 |
| 架构师/工程师 | 架构与系统实现 | 把真实现场、价值指标和工程边界连接起来 |
| 数据/算法团队 | 数据、模型、效果 | 把模型输出嵌入受控 Action 和业务结果反馈 |
官网明确强调：FDE 不是更技术的售前，也不是更商业的顾问；区别在于以现场和待验证价值假设为起点，以生产采纳和资产复用为结果。[S1][S3]
4. FDE 的工作对象
FDE 管理的不是一张“需求列表”，而是一个相互约束的交付系统：
- 人：Sponsor、管理层、业务 Owner、一线用户、产品、工程、安全、运维。
- 事：任务、决策、审批、交接、异常、反馈、复盘。
- 物：客户、订单、设备、合同、知识、文档等业务对象。
- 数：基线、状态、指标、样本、模型结果、行动轨迹。
- 权：身份、用途、最小权限、人工确认、审计、回退。
- 果：采纳、效率、质量、风险、增长、复用率和学习速度。
5. 成功标准
建议把“成功”分成四级，不用单一模型准确率代替项目结果：
- 可演示：功能链路跑通。
- 可验证：真实样本上达到预设阈值，失败可分类。
- 可生产：满足权限、稳定性、监控、审计、人工确认和回滚要求。
- 可采纳/可复用：真实用户持续使用，业务指标改善，产物能被下一项目复用。
官网最终把成功标准集中为三个结果：[S2][S5]
- Production Adoption：进入真实工作流并被持续采用。
- Workflow Impact：对业务流程和经营结果产生可测影响。
- Reusable Assets：形成连接器、模板、评测集、手册和平台能力。
6. FDE 的核心原则
- 共识早于方案。
- 价值必须可定义、可证伪、可归因。
- 先看现场事实，再抽象产品与系统。
- AI 介入意味着重构流程和责任，而不是给旧流程加按钮。
- 模型只是系统组件；数据、工具、权限、HITL、评测和运营共同决定结果。
- 每个高风险 Action 都必须可授权、可审计、可回退。
- POC 验证最大风险，不以做全功能为目标。
- 上线不是终点，采纳和反馈循环才是结果。
- 每个项目都应沉淀可复用资产。
- 结论必须由证据支持，失败与停止也是有效学习。