七个月驻场，六周失准：团队缺的不是 AI，是 FDE

摘要 中国有二十年的驻场开发文化，这既是成熟的交付能力，也是认知陷阱。AI 落地时代，驻场工程师和 FDE（现场部署工程师）之间有一条隐形分水岭——不在技术，在反馈方向。

2024年，杭州某制造企业 IT 负责人李强（化名）经历过这样一件事。 他们买了一套AI质检系统，乙方派了三名驻场工程师，住在工厂里七个月。需求访谈、模型调参、系统集成，流程走得很规范，验收单签了。三名工程师撤离后的第六周，系统的缺陷识别准确率开始悄悄下滑——产线换了一批新供应商的原材料，外观特征略有变化，但没有人更新模型。发现问题的不是IT部门，是一名质检员，她发现这两周系统老是漏判，于是私下恢复了手工核验。 到2025年年初，这套系统还在跑，但质检员已经不信任它了。它成了一个在后台运行、产生日志、没有人真正负责维护准确率的系统。 李强事后这样总结：“这个项目上线了，但没有着陆。”

• 7个月 驻场时间 撤场后无人维护
• 第6周 准确率下滑 无人发现维护
• 0人 负责质量 质检员恢复手工

SERIES MAP · 系列位置

• 1 驻场≠FDE
• 2 四个断层
• 3 怎么建

01 THE GAP · 分水岭 验收单是终点，但AI需要的是起点

传统软件交付的节点设计是合理的：需求确认，开发完成，测试通过，验收签字，项目关闭。这条链条有它的逻辑——产品一旦稳定，就不需要持续更新核心逻辑，维护靠修bug就够了。 AI系统不是这样运作的。模型的表现不是静态的，它跟输入数据、业务场景、用户行为一起变化。工厂换了原材料，金融产品换了客群，政策调整了评分标准——模型不会自动感知这些变化。它需要持续的现场反馈来保持有效。 这意味着一件反直觉的事：AI 项目真正的难关，不在开发阶段，而在验收之后。 驻场工程师的职责设计恰好在验收时结束。FDE 的职责设计从验收时才真正开始。这是两件事，不是一件事的高级版本。OpenAI 在 FDE 岗位说明里写得很直白：现场工程师的工作质量，要以评测反馈是否真正改变了产品和模型路线为检验标准；Palantir 要求工程师把现场发现持续回流成产品功能。两家都把反馈闭环写进了岗位定义——和国内常见的「验收即结项」形成对照，后者很少把验收后的模型维护写进合同或考核。

驻场开发 vs. FDE：三条分界线

02 TRAP · 认知陷阱 二十年驻场文化训练出来的，是错误方向上的正确能力

中国软件行业的驻场开发传统是真实的：ISV、系统集成商、行业解决方案商，很多公司有常驻客户现场的工程师，有时候一待就是两三年。这批人有真实的现场感知，能快速理解业务语言，能在复杂的甲方组织里推动事情往前走。但这个传统同时也把一种工作逻辑固化了：**响应需求，交付功能，完成项目。**这个闭环在传统软件里是对的——客户提需求，工程师做功能，上线了，合同执行完毕。问题进问题单，由下一个版本解决。 AI系统把这个逻辑打穿了。一套AI质检系统，验收通过不等于质检准确，更不等于六个月后还准确。但驻场工程师的合同条款、考核指标、离场时间，都对准的是验收通过，不是六个月后的准确率。 这不是驻场工程师的错，是整个交付逻辑没有设计反馈闭环的位置。

现场观察 · 一个常见误判 很多项目里最误导人的一句话，不是"预算不够"，而是"项目已验收"。验收是交付的终点，不是 AI 能力的终点。把这两件事混为一谈，是国内 AI 落地失败最普遍的根源之一。

03 TEST · 检验方法 一个问题，判断你们有的是哪种

不需要复杂的评估框架。一个问题就够了：

如果你们的 AI 系统下周给出了一个明显错误的结果，谁会在 48 小时内知道，之后又会怎么处理？

如果答案是一线用户提工单、IT 来修——你们有的仍是驻场交付逻辑，维护方式还是「用户报障、IT 响应」那一套。 如果答案是评测系统会在日报里标出异常，产品和业务团队第二天复盘，决定是需要重新标注数据还是调整提示词——你们已经有了FDE思维的雏形。 如果答案是「没想过这个问题」，或者谁该发现、谁该处理，几个部门说法不一——你们还没有反馈闭环，不少项目仍停在「出了问题不知道，知道了也没人管」。

04 REFRAME · 重新定义 从驻场交付到FDE，改变的是一个问题的答案

驻场工程师回答的问题是：这个功能做好了吗？ FDE回答的问题是：这个AI在真实业务里管不管用，怎么让它持续管用？ 这个转变不是招聘问题，是组织问题。一个企业可以有一百个驻场工程师，但如果没有人被授权去设计评测标准、没有人的工作目标和AI的持续准确率绑定、没有渠道把现场发现回流到模型，这一百个人加起来仍然不是FDE。 这个问题还有容易被忽略的另一面：有了FDE，组织有没有人被指定负责接收和处理他们传回来的现场发现？反馈闭环需要两端——FDE负责输出，组织要有人负责接收：有权做决定，有责任推进。缺了这一端，发现到达了，也会在"知道了，我们研究一下"里消失。 反过来，一个只有五人AI团队的企业，如果他们在项目设计阶段就定义了评测体系、把现场异常处理机制写进了产品路线，他们做的就是FDE式的工作。

问题不是你有没有驻场工程师，而是你的 AI 项目里有没有人负责上线之后它还持续管用。

◆ ◆ ◆

驻场开发和FDE的距离，不是技术等级的距离，而是工作目标的距离。前者对准的是合同交付，后者对准的是业务改变。AI落地时代，这个距离的代价，是大量项目上线了但没有着陆。 但这个距离，往往比立项时预想的更难弥合——因为它不只是个人能力问题，而是组织问题。下一篇，我们具体看：国内企业 AI 项目卡住，通常卡在哪四个组织断层上。这四个断层不是技术问题，是问责问题。

如果您也对AI落地与组织建设感兴趣，不妨了解观远数据的相关产品。

观远数据以"让业务用起来 让决策更智能"为使命，致力于为零售、消费、金融、高科技、制造、互联网等行业的领先企业提供一站式数据分析与智能决策产品及解决方案。

观远数据专注智能分析平台，为您提供一站式BI至AI智能分析全链路场景，深耕零售、消费品、电商、金融、先进制造、医疗医药、互联网等行业200+实战业务场景。

🔗 了解更多