← 返回文章列表
FDE工作方法

FDE 实践：用工程的方式做产品判断

FDE 不是销售前置，也不是工程后置。它的核心是把产品判断变成可验证的工程动作。
发布2026.01
阅读6 分钟
字数约 1,700 字

我做了两年 FDE（Forward Deployed Engineer），这个角色在国内还没有统一的定义。每次有人问我”你到底做什么”，我都得花十分钟解释。后来我发现，与其解释它是什么，不如先说清楚它不是什么。

FDE 不是什么

FDE 不是售前。售前的目标是”让客户买单”，FDE 的目标是”让产品能用”。前者关心的是 PPT 上的故事，后者关心的是线上的结果。我见过太多售前承诺的功能，到了交付阶段根本做不到——因为售前不懂实现成本，FDE 懂。

FDE 也不是交付工程师。交付的目标是”按合同把功能做完”，FDE 的目标是”让业务真的跑起来”。前者对的是合同条款，后者对的是业务指标。合同里写”支持自然语言查询”，交付会说”我们接了 LLM，能查了”；FDE 会说”查询准确率 78%，前 20 类问题覆盖了 85% 的真实流量，长尾问题需要人工兜底”。

FDE 更不是纯研发。研发的目标是”把代码写好”，FDE 的目标是”把判断做对”。代码质量是手段，业务结果是目的。我会花一天时间和客户对齐”什么叫答对了”，因为如果这个判断错了，代码写得再漂亮也没用。

产品判断的工程化

FDE 最核心的能力不是写代码，是把模糊的产品判断变成可验证的工程动作。这件事说起来抽象，我拆开讲。

假设→验证→决策

每个 AI 项目本质上是一连串假设：“假设用户会这样问""假设这个检索策略能覆盖 80% 的问题""假设这个准确率能让业务接受”。

传统的做法是：把这些假设藏在脑子里，直接写代码，上线后看结果。FDE 的做法是：把每个假设显式列出来，为每个假设设计一个验证方式，用验证结果驱动决策。

举个真实例子。一个客户想要”设备故障智能诊断”功能。传统做法是直接开始搭 RAG + LLM。我的做法是先列假设：

  • 假设 1：设备手册的故障排查章节能覆盖 80% 的真实故障。→ 验证方式：采样 50 条历史工单，看有多少能在手册里找到对应章节。
  • 假设 2：维修工程师能看懂 LLM 生成的排查步骤。→ 验证方式：给 3 个工程师看 10 条 LLM 输出，看他们能否直接照做。
  • 假设 3：LLM 不会在故障诊断中给出危险建议。→ 验证方式：把 20 条高危故障场景做成评测集，检查 LLM 输出是否包含安全提示。

这三个假设验证花了一周。结果：假设 1 成立（82% 覆盖），假设 2 部分成立（工程师需要更结构化的输出），假设 3 不成立（LLM 在 4 个高危场景里没给安全提示）。

基于这个结果，决策变得清晰：项目可以做，但要加输出结构化模板和安全规则引擎。如果没有这步验证，我们会花一个月搭系统，然后在高危场景上翻车。

把模糊变可量化

客户说”要准”。什么是准？不同角色的定义完全不同。业务方说”准”是指”能解决我的问题”，工程师说”准”是指”答案和标准答案一致”，运维说”准”是指”不要再给我报假警了”。

FDE 的工作是把”准”这个模糊词拆成可量化的指标：

  • 答案正确率：LLM 输出与标准答案一致的比例。
  • 关键信息完整率：答案是否包含所有必须的信息项。
  • 误报率：系统报告了问题但实际没有问题的比例。
  • 漏报率：系统没报告但实际有问题（这个最危险）。

拆完之后，你会发现不同角色关心的指标不同。业务方关心”正确率 + 完整率”，运维关心”误报率”，安全合规关心”漏报率”。把这些指标对齐后，“准”就不再是吵架的词，而是可以分头优化的工程目标。

一个典型的 FDE 工作流

我接手一个新项目时，第一周从来不写代码。工作流长这样：

  1. 第一天：听。和业务方、运营、一线员工各聊一小时。不提方案，只问”你现在最头疼的问题是什么”。
  2. 第二天：看数据。看日志、看工单、看现有系统的使用数据。找”高频但低效”的环节——那就是 AI 能创造价值的地方。
  3. 第三天：列假设。把”我觉得 AI 能解决这个问题”拆成 5–10 个具体假设，每个假设配一个验证方式。
  4. 第四天：验证假设。用最小成本验证——采样数据、跑几个 case、和一线员工确认。不搭系统，只验证判断。
  5. 第五天：对齐。拿着验证结果和业务方对齐”能做什么、不能做什么、做到什么程度算成功”。

这一周结束后，我会产出一份”项目可行性判断”文档，包含：可量化的成功指标、关键假设及验证结果、推荐的技术方案、风险清单。这份文档不是 PPT，是工程文档——每个结论都有数据支撑。

FDE 的价值不在写了多少代码，在少走了多少弯路。一个”不做”的判断，往往比一个”做出来”的功能更值钱。

FDE 与其他角色的区别

做了两年 FDE 后，我最大的感受是：FDE 是一个翻译者。它把业务方的模糊需求翻译成工程假设，把工程的验证结果翻译成业务语言。

这个翻译能力建立在两个基础上：一是懂业务，能理解业务方”为什么”要这个东西；二是懂工程，能判断”能不能做到、做到什么程度”。

缺前者，你会做出技术上完美但业务上无用的东西。缺后者，你会对业务方有求必应，最后交付不出来。

所以 FDE 不是一个”初级角色”，恰恰相反，它需要同时具备产品判断力和工程判断力。这两样能力都需要项目经验积累，没有捷径。

结语

FDE 这个角色之所以重要，是因为 AI 项目的难度不在技术、不在模型，在判断——判断什么该做、什么不该做、做到什么程度。这种判断不能靠直觉，要靠工程化的验证。

把产品判断变成可验证的工程动作，这就是 FDE 做的事。它不性感，但它能让 AI 项目从”demo 惊艳”走到”生产可用”。中间这段路，就是 FDE 的价值所在。