作者高飞在调研中我们发现任何接触FDE概念的人开始都会产生一个疑问。如果岗位的责任已经改变支撑这些人的合同却仍然大多按照项目、人天和交付物计算。一支由资深工程师组成的FDE团队成本不低如果每个客户都需要从头投入相同的人力这种方法越成功厂商背负的交付压力反而越大。所以如何让FDE成为一门可持续的生意这里至少有三本账要同时算得过来。客户先要从应用中得到可以观察的价值节省了多少时间增加了多少收入降低了多少风险。上线、验收和准确率只是中间指标持续使用与业务结果才会决定下一年是否续约。客户持续使用以后厂商才可能获得模型调用、算力供给、数据平台和运维服务带来的长期收入让FDE不必完全依靠一次性项目费存活。与此同时FDE在现场积累的经验、在授权与合规边界内形成的数据反馈以及行业know-how还要反哺模型、Agent平台和相关云产品。产品因现场实践变得更好又可以服务更多客户和行业FDE创造的效益便不再停留在单个项目里后续项目的交付也有机会变得更轻。客户价值、厂商收入和产品复用少了任何一项FDE都很难从一批成功项目变成可持续的产业机制。付费方式也可能随之变化。眼下常见的仍是一次一单双方在合同里写清需求、周期和交付物。可当一个新场景用一两周便能判断是否值得继续重新立项、招标、报价和验收所花的时间可能比试验本身还长。因此按年签订持续服务合同可能会比一次次购买项目更适合FDE客户购买的是一支在约定边界内不断发现、验证和上线高价值场景的团队一个方向失败以后可以把资源转向下一个。再往前一步理想状态是按结果付费即现在讨论很多的Result as a Service。客户购买的不再是工程师投入了多少人天也不只是交付了几个智能体而是周转时间缩短、故障率下降、收入增加或者风险减少。但这一步显然还需要更成熟的条件。企业要有可以比较的业务基线双方也要分清哪些结果来自模型哪些来自流程调整、数据质量和组织配合厂商能够控制多大范围才可能为多大范围的结果负责。安全责任、极端事件和长期收益如何定价也需要更多案例数据。项目费用、长期服务合同和结果付费更像逐步演进的三种关系不会在所有企业中同时完成切换。也正因为这套循环要求前线经验能够迅速回到模型、Agent平台和产品研发中国FDE的落地科技大厂可能是更合适的牵头者。Palantir把这套机制称为 “人类反向传播”。FDE不是为每个客户永远手工解决问题而是要把反复出现的问题带回研发体系。第一个项目里需要工程师处理的缺口如果在第二个项目里变成平台的标准功能现场服务才可能越来越轻。一个企业提出的要求可能只是定制多个行业反复遇到的权限、评测、高可用和数据治理问题才值得被做成标准能力。平台公司既可以跨客户观察这种重复也拥有把它送进产品路线图的研发资源。如果前线只能按照既定范围实施却无法影响产品它所做的工作更接近高级交付。企业AI的生产问题又很少停留在单一层面。一次响应缓慢背后可能是模型推理、算力调度或者数据库的问题一个Agent无法进入流程也可能牵涉数据治理、安全权限和生产运维。FDE不必亲自解决每一层问题但要在组织内找到相应的产品团队。拿阿里云来说它拥有从基础设施、模型服务、AI开发平台到数据库、安全和运维的产品体系现场问题因此有了比较完整的回流路径。全栈的意义并不是向客户方案里塞入更多产品而是跨层问题能够找到责任人也有机会沉淀进模型、Agent平台和云产品在下一个项目中不再重新解决。应用真正运行以后还会持续产生模型调用、Token、算力、数据库和平台服务的需求。云厂商可以用工程服务推动采用再从持续使用中获得回报也就不必完全依靠出售工程师人天覆盖成本。翻看工业革命史、经济史里有一段与今天的AI落地颇为相似。19世纪末工厂开始使用电动机很多厂主最初只是把蒸汽机换成电机厂房里的皮带、传动轴和机器布局却原封不动。经济学家保罗·戴维研究电气化历史时指出更大的生产率提升是后来才出现的每台机器拥有自己的小电机以后工厂不再必须围绕中央传动轴布置机器位置、物料运输和生产流程都可以重新安排。真正的生产力释放不在模型发布那一天而在AI按照业务逻辑重新排列工作流程的那一刻——FDE正是推动这个重新排列的人。