功能验收很清楚，业务价值却经常无人负责
项目合同里常写完成几个页面、接入几个接口、支持哪些功能。工程团队按清单交付，演示也通过，三个月后员工使用率很低，流程时间没有下降，系统仍然可以被判定为“项目完成”。
FDE 模式强调靠近业务现场，如果最后仍只按功能数量验收，就失去了这一角色的意义。未来更成熟的 FDE，需要和客户一起定义系统在生产中应该保持什么状态，以及何时说明项目没有达到预期。
业务运行指标要从一个具体流程开始
不要给整个企业 AI 项目设一个抽象 ROI。以客服工单为例，可以看首轮处理时间、人工修改量、升级率、错误分类和员工使用率；销售资料助手则可以看准备时间、信息遗漏和跟进及时性。指标必须对应真实流程。
同时设保护指标。速度提高但客户投诉增加，不算成功；自动化率上升但员工每天花更多时间复核，也不算成功。FDE 要帮助客户在效率、质量和风险之间做可见权衡。
- 一个指标对应一个明确业务流程和负责人。
- 结果指标与质量、风险保护指标同时存在。
- 数据口径、来源和检查频率在上线前确认。
指标不是 FDE 单方面替客户决定
工程师可以建议可观测数据，却不能替客户定义业务成功。客服负责人知道哪些投诉不能自动处理，销售主管知道什么才算有效跟进，财务知道哪些节省只是时间转移。目标需要客户承担。
FDE 的作用是把模糊愿望变成可测量运行状态，指出数据缺口和技术限制，并提醒指标可能被误用。例如只追求自动化率，会诱导团队把不适合的任务也交给 Agent。
建立运行门槛，而不是只看月底平均数
平均表现可能掩盖严重波动。系统大多数时间正常，但月底批量任务频繁失败，业务仍然无法依赖。可以为关键指标设置运行门槛，例如连续多少天稳定、失败超过多少必须降级、人工修改高于什么比例要复盘。
门槛不是承诺永远不出错，而是明确何时继续扩大、何时保持、何时暂停。它让业务和技术面对同一套事实，也让迭代决定不再依赖会议里的主观感受。
FDE 的未来价值，会体现在持续影响而非一次交付
OpenAI 当前 FDE 岗位公开把生产采用、可衡量的工作流影响和评测反馈列为成功信号，说明行业正在把前线部署从项目完成推向持续结果。FDE 需要会读数据，也要能解释数据背后的业务变化。
并非所有项目都能产生漂亮增长。有时最有价值的决定是缩小自动化范围、保留人工环节或暂停某个场景。能用运行指标做出这些判断，说明 FDE 真正站在客户结果一边，而不是只为功能数量负责。
要点总结
- 需要，但功能验收只是基础，还应观察生产采用、流程结果、质量和风险。
- 客户业务负责人承担目标，FDE 帮助转成可测量口径并说明技术限制。
- 不一定，应同时看错误、人工复核、客户影响和不适合自动化的边界。
参考来源说明
本文围绕“FDE 交付不能只看功能完成：未来要和客户一起守业务运行指标”展开，结合 9 份公开资料及一路凯歌在“FDE 前线部署工程师”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。