FDE 方法论：从现场问题到产品化
FDE 的五步循环：驻场观察、快速原型、真实数据验证、沉淀模块、回流产品，及产品化判断标准。
五步循环：一个可复制的骨架
前沿部署工程师（Forward-Deployed Engineer, FDE）的工作看起来杂乱——每天面对的都是没见过的问题——但成熟的 FDE 团队背后有一套稳定的循环。我把它总结为五步：驻场观察 → 快速原型 → 真实数据验证 → 沉淀可复用模块 → 回流产品。它不是瀑布流程，而是一个螺旋：每转一圈，现场方案离产品能力更近一步。
第一步：驻场观察——区分症状与根因
驻场观察不是「坐在旁边看一天」。它的核心动作是区分症状与根因：一线员工说「我们需要一个自动分类的工具」，这是症状陈述；FDE 要追问的是——分类错误的真实代价发生在哪个环节？现有流程里谁在人工兜底？兜底的判断依据是什么？
实用技巧：跟随一次完整的业务事件（一个工单从出现到关闭的全过程），记录每一个「手工小动作」和「口头约定」。这些从不出现在需求文档里的环节，才是模型真正要接入的位置。产出物是一份「现场问题清单」，每条标注：现象、根因假设、影响面。
第二步：快速原型——当天可用的粗糙版本
拿到问题清单，FDE 不写设计文档，而是直接做原型：把模型的输出接进真实流程的最小片段，越快让一线用户摸到越好。关键动作有三个：
- 只做最小闭环，砍掉一切「以后会用到」的功能；
- 接口从简，先用真实流程中最脏的那个环节验证；
- 当天部署、当天收集反馈——FDE 的迭代单位是天，不是周。
产出物是一个能跑的原型加一份「反馈日志」：用户在哪个输出上犹豫了、哪个结果被直接复制进了正式系统。
第三步：真实数据验证
原型跑在脱敏样例数据上不算数。这一步的关键动作是把方案放进客户的真实数据与真实权限环境里跑一段稳定周期，重点盯三件事：错误率在最差的一天有多差（不是平均表现）、失败时的兜底成本、以及一线用户是否真的在用（不是被要求用）。产出物是一份带真实场景截图的验证报告——它同时是向客户证明价值和向产品团队证明必要性的材料。
第四步：沉淀可复用模块
验证通过的方案，下一步不是「交付结项」，而是抽象：这次为某客户写的工单意图识别流程里，哪些部分是行业通用的？数据接入层、提示词模板、评估集，能否脱敏后沉淀为可复用模块？产出物是模块代码 + 适用边界说明——明确它「在什么条件下可用」，比模块本身更重要。
第五步：回流产品
最后一步是把现场发现带回组织：哪些问题在多个客户处重复出现（产品信号）、哪些是单点定制（服务收入）、哪些暴露了产品能力的真实缺口（路线图输入）。这一步的组织保障往往比技术更难——需要 FDE 与产品团队之间有固定的回流通道，而不是靠个人热情。
哪些问题不该产品化
不是所有现场问题都值得沉淀。两类问题应该明确拒绝产品化：一次性问题（客户的临时性数据迁移、特殊时期的专项处理）和强定制问题（深度绑定客户独有流程与系统，抽象后无人可复用）。强行产品化会制造出维护成本远超收益的「伪产品」。FDE 的纪律之一，是坦然承认「这是一个服务，不是产品」。
小结
好的 FDE 交付物有一个共同的终局：让客户不再需要这个一次性方案。它要么被产品能力吸收（客户升级后直接使用标准功能），要么问题本身被消灭。如果三年后客户还在依赖你当年写的那个定制脚本，那不是长期关系的证明，而是产品化失败的账单。