FDE 不是驻场救火：怎样把企业 AI 从 Demo 推进到真实工作？

企业 AI 项目最容易出现的错觉，是把“系统已经做出来”当成“业务已经开始使用”。Demo 能回答问题、工作流能成功跑一次、页面能生成报告，都只是技术成立；真实落地还要继续回答：结果能不能被核对，谁会在日常工作里使用，使用以后改变了哪个动作，后续又由谁维护。

FDE（Forward Deployed Engineer）可以被理解为连接业务现场、产品能力和持续采用的落地角色。它不是单纯驻场写代码，也不是替客户长期救火。它要把现场里反复出现的问题变成可验证的小闭环，再把有效做法沉淀为下一次能复用的交付资产。

FDE 解决的是四个断点

很多企业并不缺 AI 工具，缺的是工具与真实工作之间的连接。这个连接通常断在四个位置：

1. 问题没有被定义： 大家都说要“提效”，但没有具体流程、当前基线和验收人。
2. 结果不能被验收： Demo 看起来顺畅，却说不清正确、完整和可用分别怎样判断。
3. 产品没有进入工作： 员工要离开原来的工作台、重复录入，或者不知道什么时候应该使用。
4. 经验没有被沉淀： 每个项目都靠现场人员临时处理，下一次仍然从零开始。

FDE 的工作，就是逐个关闭这些断点。项目价值不是四项工作的简单相加；任何一项接近零，最终落地效果都会迅速缩小。

第一次转换：从“想做 AI”到一张真实问题卡

不要从功能清单开始。先找到最近一次真实发生的任务，把业务现场还原出来：谁收到什么材料，做了哪些判断，在哪一步等待或返工，最后把结果交给谁。

一张可以开工的问题卡，至少要写清：

项目	要回答的问题
业务触发	什么事件启动这项工作，多久发生一次
当前动作	人现在怎样完成，最耗时或最不稳定的是哪一步
输入与依据	使用哪些数据、文档、规则和历史样本
可用结果	交付物是什么，谁会拿它继续工作
验收方式	谁验收，正确、完整、及时分别怎样判断
风险边界	哪些动作不可逆，哪些承诺必须由人决定
长期负责人	谁维护规则、处理例外并决定是否扩大

如果这些问题暂时无法回答，先做流程访谈、数据归拢或知识整理，比立刻搭 Agent 更接近落地。

第二次转换：从 Demo 到最小业务闭环

最小闭环不是“功能最少”，而是结果第一次能够进入下一步工作。一个合格的小闭环应该使用真实但经过授权和脱敏的材料，产生可以核对的结果，并让业务人员据此完成一个后续动作。

例如，货代询价的第一版不需要自动向客户报价。它可以先完成字段提取、缺失信息识别、规则来源检索、冲突标记和复核材料准备，再由商务人员决定外部承诺。这个范围虽然窄，却能同时暴露数据、规则、接管和验收问题。

可以用四个问题检查闭环是否成立：

• 结果是否来自真实输入，而不是演示样例？
• 业务人员能否指出哪里正确、哪里需要修改？
• 这份结果是否改变了下一步动作，而不只是被浏览一次？
• 人工修改是否能回到规则、样本或评估集合？

只完成前两个问题，通常仍然是 Demo；四个问题都能稳定回答，才开始接近可运营的工作流。

第三次转换：从交付完成到持续采用

落地不能只记录“上线了多少功能”，还要观察采用证据。比登录人数更有价值的信号包括：

• 同类任务中有多少比例真正经过新流程；
• 业务人员是否愿意把真实材料交给系统；
• 人工复核是在确认少数例外，还是重新完成全部工作；
• 出错以后能否暂停、交接并恢复；
• 一周或一个业务周期后，团队是否仍然主动使用。

采用问题往往不是培训不足，而是工作设计不合理：入口太远、需要重复录入、结果格式不能继续使用、责任边界不清，都会让一个技术上可用的系统被日常工作排斥。

FDE 因此需要同时看产品和组织。产品要尽量进入员工已有的工作表面；组织要明确验收人、流程 owner、例外接管和维护节奏。

第四次转换：从现场项目到可复用能力

如果每个客户都依赖同一个人长期驻场，服务会变成昂贵的人力外包。FDE 是否形成护城河，取决于现场经验能否被转化。

建议至少沉淀五类资产：

1. 场景筛选标准：什么问题值得做，什么问题应该拒绝或延后。
2. 问题卡与节点卡：怎样把模糊需求变成可执行范围。
3. 样本与评估集：哪些输入、期望结果和失败情况需要长期回归。
4. 接管与复盘记录：哪些例外由谁处理，处理后更新了什么。
5. 上线与采用清单：权限、培训、监控、维护和扩面条件怎样检查。

这些资产不是为了把所有行业做成同一个模板，而是把重复判断标准化，让下一次现场工作更快进入真正需要行业判断的部分。

AI 服务可以按四个阶段设计

阶段	对客户的交付	进入下一阶段的证据
诊断	业务地图、候选场景、问题卡	有具体流程、负责人和可观察基线
试点	真实样本上的最小闭环	结果可验收，失败可发现并回退
采用	接入工作台、培训、运营和复盘	团队持续使用，人工工作确实发生变化
产品化	模板、评估集、组件和行业方法	新场景不再完全从零交付

这种设计也帮助服务商避免用“AI 能做很多事”销售。每个阶段都对应一个明确决策：要不要开始、要不要继续、要不要扩面、哪些部分值得复用。

FDE 不应该替代企业内部 owner

FDE 可以推动问题定义、搭建闭环、组织验收和沉淀方法，但不能永久代替企业对业务结果负责。规则取舍、外部承诺、风险接受和长期资源安排，仍然需要企业内部的业务 owner 与流程 owner 决定。

更健康的结果是：FDE 在现场把方法跑通，同时让内部团队逐步接住规则维护、异常复盘和日常运营。外部服务留下的不是一个无人维护的工具，也不是对个人的长期依赖，而是一套能继续工作的组织能力。

证据与适用边界

• 本文是结合公开行业讨论、社区实践样本和站内既有现场观察形成的工作框架，不是 FDE 职业认证标准。
• 文中没有复述任何单一案例的客户数据、收入结果或专有步骤。
• 对数字化基础薄弱、数据分散的企业，第一阶段可能是数据归拢和流程可视化，而不是直接部署 Agent。
• 对高风险、不可逆流程，小闭环也必须保留人工审批和审计记录。

接下来可以用试点优先级评分表筛选第一条流程，阅读垂直行业 AI 服务怎样形成价值，或进入组织与服务增长专题查看从学习、试点到长期服务的完整路径。货代场景的边界示例见匿名询价工作流案例。