FDE 这个词最近很热，但如果放到我们的业务里，不能照搬硅谷语境。
对软件公司来说，FDE 可能是把模型、Agent、数据和客户流程接起来的人。对我们来说，更准确的说法应该是：把合同、设计、供应链、现场、商务全部翻译成项目交付系统的能力。
这不只是懂 AI。
它首先要懂设备工程交付。
我们的项目经理、方案工程师、交付负责人、供应链负责人，其实天然就有一部分 FDE 能力。因为他们每天面对的不是抽象需求，而是实物交付：
客户要什么业务能力。
方案配置怎么定。
图纸怎么出。
BOM 怎么拆。
供应商怎么交。
生产怎么排。
设备怎么发。
现场怎么装。
KPI 怎么跑。
客户怎么验。
款怎么收。
利润怎么保。
能把这些线串起来的人，比很多只会讲 AI 的人更接近真正的企业 AI 落地。
但这里也有一个风险：我们很容易把这种人用成救火队。
客户现场有问题，去现场。
设计和采购对不上，去协调。
生产缺料，去催。
发货计划变了，去解释。
安装调试出问题，去盯。
KPI 跑不出来，去想办法。
验收卡住，去沟通。
回款慢了，去补材料。
如果只是这样，再强的人也会被项目消耗掉。
所以我们需要的 FDE，不应该只是“谁都找他”。更准确地说，我们需要把 FDE 能力沉淀成系统能力。
第一，项目对象定义能力。
合同签了以后，不能只靠项目经理脑子里知道这个项目是什么。系统里必须有清楚的项目对象：客户、场景、配置、设备数量、格口数量、上包台、扫描方式、定制料箱、现场限制、KPI 指标、验收节点、收款节点。
这个对象定义不清，后面所有线都会乱。
设计觉得自己出了方案。
采购觉得自己按 BOM 买了。
生产觉得自己按计划做了。
现场觉得自己按设备安装了。
商务觉得自己按合同节点收款。
每个人都可能是“对的”，项目却仍然是错的。
第二，边界定义能力。
设备工程项目里，边界非常重要。
什么是标准配置，什么是客户定制。
什么变更属于合同范围内，什么要走商务变更。
什么替代料可以接受，什么必须重新评审。
什么现场条件由客户提供，什么由我们负责。
KPI 测试前置条件是什么。
验收失败是设备问题、现场条件问题、操作问题，还是业务流程问题。
这些边界如果不清楚，项目会变成无止境的“再帮客户处理一下”。
软件项目需求边界不清，会拖进度；设备工程项目边界不清，会同时拖进度、拖成本、拖库存、拖人员、拖回款。
第三，沉淀能力。
一个项目救火成功，不等于公司能力提升。
真正有价值的是把这次项目里的经验沉淀下来：
某类客户场景适合什么配置。
某类项目 BOM 容易漏哪些物料。
某类供应商交期风险大。
某类现场条件必须提前确认。
某类 KPI 验收容易卡在哪里。
某类配置变更会影响哪些成本。
某类海外项目运输和安装需要提前准备哪些材料。
这些内容如果只停留在个人经验里，公司下一次还是从零开始。
所以我会把我们的 FDE 能力分成四层。
第一层，方案翻译。把客户业务场景翻译成设备配置和交付边界。电商、零售、快递、3C、冷链，每个场景的分拣对象、吞吐要求、准确率、占地、上包方式、格口设计、扫描方式都不同。
第二层，工程拆解。把方案配置翻译成图纸、BOM、采购、生产、测试和发货计划。这里不能只会讲方案，必须理解配置变化如何影响实物链。
第三层，现场闭环。把安装调试、KPI、验收问题翻译成可追踪的任务和责任，不让现场问题只停留在微信群和个人经验里。
第四层，模式沉淀。把项目经验反哺到产品、配置模板、BOM 模板、供应商策略、安装 checklist、验收标准和商务报价模型。
如果我们要做 AI，最有价值的不是做一个“AI 项目经理”取代人，而是做一个能增强这些 FDE 型人才的系统。
AI 可以帮项目经理看风险，但不能替项目经理承担承诺。
AI 可以帮工程师比对配置和 BOM，但不能替工程师确认最终方案。
AI 可以帮供应链识别缺件影响，但不能随便替换物料。
AI 可以帮现场总结调试问题，但不能替代安全和验收责任。
AI 可以帮商务识别损益异常，但不能替公司决定让利。
这种边界很重要。
我们不是要把人拿掉，而是要把人的判断放到系统里，让它可见、可复用、可复盘。
设备工程公司的核心竞争力，不只是设备本身，也包括项目交付能力。很多客户最后记住的不一定是某个功能参数，而是你能不能按期交付，能不能跑通 KPI，出了问题能不能解决，验收和回款能不能顺利。
所以我们需要的 FDE，不是驻场救火的人。
它应该是一种组织能力：把客户场景、设备配置、供应链齐套、现场安装和商务回款串成一个交付系统。
如果 SCS 能成为这类人的工具，而不是又一个让他们填表的系统，我们的 AI 化才会有真正的根。