AI 项目为什么总死在最后一公里？

不是模型不够强，而是工程、现场与组织没有被同一条价值链拉通

一家制造企业做了一套视觉质检系统。POC 阶段，团队挑选了几千张清晰图片，模型指标很好，演示现场也很顺利。到了真实产线，问题开始接连出现：夜班光线变化、镜头沾灰、产品换型、网络抖动、缺陷标签口径不一致。系统仍在运行，告警也不断弹出，但操作员越来越少打开它。三个月后，项目在技术意义上“上线了”，在业务意义上却已经停止。

这不是某一家企业的特殊遭遇，而是一类高度重复的项目轨迹。很多 AI 项目并不是死在训练阶段，而是死在模型离开 Notebook 之后：数据链不稳定、系统接口没人负责、现场人员不信任、业务 KPI 没有闭环，上线之后也缺少持续迭代的 Owner。

图 1：从立项到持续运营，AI 项目会在多个交接点不断流失

一、POC 很漂亮，为什么一到现场就失灵？

POC 的任务，是证明一个方向“可能有效”；生产系统的任务，是在真实约束下长期有效。两者听起来只差一个上线动作，实际上是两种完全不同的问题。

POC 环境通常会主动降低复杂度：数据被清洗、标签被复核、设备状态相对稳定，参与者也愿意配合项目。生产环境则把所有被暂时隐藏的问题一次性带回来。缺失值不会提前通知，设备不会因为模型在推理就暂停换型，操作员也不会为了配合算法团队而改变多年形成的工作习惯。

图 2：POC 与生产环境的差异，不只是数据量不同

1. 数据链比模型更早暴露问题

在工业和企业系统里，模型看到的数据要经过“采集—传输—存储—加工—权限—调用”多层链路。任何一层出现时间戳错位、字段含义变化、传感器漂移或接口超时，模型结果都会失真。Google 研究团队在《Hidden Technical Debt in Machine Learning Systems》中指出，机器学习代码只是完整生产系统的一小部分，真正复杂的是数据依赖、配置、监控、服务基础设施和组织流程。

2. 离线准确率没有回答“谁会使用”

模型可以在测试集上获得很高的准确率，却仍然没有进入现场动作。原因往往不是结果完全错误，而是结果出现得太晚、解释不清、误报太多，或者需要操作员额外打开一个没人习惯的新系统。

例如，质检模型的 Recall 很重要，但业务真正关心的是：漏检造成多少返工和客诉，误报是否会让产线频繁停顿，告警出现后谁来确认，确认需要多长时间，系统不可用时能否立刻切回人工。

3. Demo 验证“能不能做”，生产验证“能不能扛住”

Demo 更像一次受控考试，生产系统则像每天都要参加、题目不断变化的长期考试。生产系统必须面对性能、权限、审计、回滚、人工接管和责任边界。只要其中一项没有设计，模型能力就无法稳定转化为业务能力。

二、真正难跨的不是技术栈，而是组织栈

企业里参与 AI 项目的三方，通常都在解决自己职责范围内的正确问题。算法团队要追求模型效果，IT/OT 团队要保护关键系统，业务和现场人员要保证生产连续。问题在于，三方使用的是不同语言，也承担不同风险。

图 3：算法、IT/OT 与现场之间存在天然的目标差异

算法团队：离业务结果还有两层楼

算法团队习惯用 Loss、AUC、mAP 和离线测试集描述效果。这些指标不可缺少，但它们不能直接说明系统上线后能节省多少钱，也不能说明操作员是否愿意采纳。算法团队可能知道模型在哪些样本上失败，却未必知道一次错误告警会不会导致停机、返工或责任争议。

IT / OT 团队：安全稳定永远排在“智能”前面

MES、ERP、SCADA、PLC 等系统直接承载企业运行。对 IT/OT 团队来说，未经验证的新服务意味着额外的网络、权限和可用性风险。他们问的不是模型有多先进，而是：接口是否只读、GPU 服务挂掉会不会拖累主系统、数据能否出网、出故障到底算谁的。

业务与现场：被过度承诺伤过之后，只相信可控结果

现场人员更关心稳定、可解释和可接管。系统如果连续误报，最常见的结果不是现场人员不断反馈帮助模型改进，而是直接关闭告警。技术团队看到的是“用户不配合”，现场看到的却是“又一个增加工作量、出了问题还要我负责的系统”。

三、一个模型指标，要翻译四次才能变成业务价值

很多项目在立项时只写“准确率提升到 95%”“使用大模型提高效率”，但没有定义指标如何穿过系统和流程，最终落到业务账本。真正可交付的指标链，至少需要四层。

图 4：模型指标必须经过系统、流程和业务口径的连续翻译

模型指标：模型本身做得对不对

这一层包括 Precision、Recall、F1、AUC、mAP 等。它回答的是模型在给定数据集上的性能，但不回答系统是否及时，也不回答结果是否被采用。

系统指标：结果能否稳定送到正确位置

需要关注 P95 延迟、服务可用性、接口成功率、告警送达率、容灾和回滚时间。一个准确率很高、但高峰期经常超时的模型，无法成为生产能力。

流程指标：人是否因此改变了动作

常见指标包括操作员采纳率、人工确认时长、工单关闭时长、建议被修改或拒绝的比例。流程指标是最容易被忽略、却最能判断系统是否真正进入业务的一层。

业务指标：结果是否能够被结算

最后才是企业真正愿意持续付费的结果：漏检损失下降、非计划停机减少、良率提高、库存周转改善、每单处理成本下降。McKinsey 2025 年全球 AI 调研指出，在其测试的组织属性中，端到端重构工作流对生成式 AI 带来 EBIT 影响最为关键。换句话说，把模型塞进旧流程，往往不如重新设计人和系统如何协作。

四、为什么“接力式交付”容易在交接处断掉？

传统项目常按照职责拆分：业务提出需求，算法团队训练模型，软件团队接接口，IT 团队部署，最后交给现场使用。每个团队都完成了自己的任务，但没有一个角色持续保留完整上下文。

图 5：接力式交付与端到端拥有的差异

业务需求在进入算法阶段时会被压缩成数据和指标；模型进入工程阶段时又会被压缩成接口；系统交到现场时，现场只看到一个告警或按钮。每次交接都会丢失一部分背景、假设和责任。

这也是为什么很多项目“没人做错”，最终却没有产生价值。算法团队完成了模型，工程团队完成了服务，IT 团队完成了部署，业务团队却没有得到一个能稳定改变工作结果的系统。

五、FDE 为什么会在这个阶段出现？

Forward Deployed Engineer 并不是一个更会做演示的售前，也不是一个同时替代算法、后端和项目经理的“全能人”。它解决的是端到端拥有问题：有人长期处在客户和产品之间，既能进入代码与系统，也能进入业务现场，并持续对生产采用和业务结果负责。

OpenAI 当前的 FDE 招聘页面把这类工作描述为：与战略客户共同完成前沿模型的复杂生产部署，负责 Discovery、技术范围界定、系统设计、构建和生产发布，并通过生产采用率、可量化的工作流影响和评测反馈衡量成功。Palantir 对 Forward Deployed Software Engineer 的描述同样强调技术与运营结果，而不是单纯交付代码。

图 6：FDE 的核心不是“什么都会”，而是把每一个断点收口

1. 把模糊抱怨翻译成可验证问题

“能不能提高良率”“能不能用大模型做智能助手”都不是可以直接开发的需求。FDE 需要继续追问：具体识别、预测、推荐还是执行什么？谁会使用？结果出现在哪里？什么情况算成功？失败后如何回退？

2. 在建模之前先审计数据与流程

项目是否值得启动，往往在 Data Audit 阶段就能判断。数据是否存在、是否可靠、标签从哪里来、是否覆盖换型和异常状态，比先选择哪一种模型更重要。

3. 亲手构建，但不把一次性交付当终点

FDE 需要能够写生产代码、接系统、做权限和监控，因为许多关键问题只有进入实现细节才能暴露。但它还需要继续推动灰度、培训、SOP、反馈回流和业务复盘，直到系统成为日常动作。

4. 把现场失败沉淀成可复用产品能力

一次项目里暴露的接口、权限、评测和运维问题，不应在下一个客户重新解决。高质量的 FDE 会把现场经验沉淀成连接器、模板、评测集、部署脚手架和产品需求，让组织交付速度越来越快。

六、你的团队是否需要 FDE？

岗位名称并不重要。企业可以叫 FDE、AI Solution Engineer、Delivery Architect，甚至由资深后端工程师或解决方案架构师承担。但只要项目跨越模型、系统、现场与组织，就必须明确谁拥有整条价值链。

图 7：当这些信号同时出现时，端到端 Owner 已经不可缺少

最危险的状态不是团队没有 FDE 这个岗位，而是所有人都以为“最后一公里”属于别人。算法认为上线是工程的事，工程认为采用是业务的事，业务认为效果是算法的事，现场认为出了问题只能恢复人工。

七、结语：企业缺少的，往往不是更大的模型

模型能力仍然重要，但企业 AI 的竞争正在从“谁先用上新模型”转向“谁能把模型稳定嵌入工作流”。一个系统只有在真实数据、真实权限、真实责任和真实用户中长期运行，才算穿过最后一公里。

图 8：从模型到业务价值，是一条不允许在交接处断裂的链