我在客户机房待了两周，才明白 Demo 和上线之间隔着什么

入职第三个月，我带着一个跑得完美的 Demo 去了客户现场。会议室里，产品经理投屏，我敲命令，数据一条条出来，客户点头。签单。

两周后我人还在客户机房里，蹲在一台没有外网的服务器前面，手动给一个 2013 年的老系统写适配脚本。Demo 里那套东西，一行都没跑起来。

那是我第一次真正理解"部署"这两个字。它不是把镜像推上去、点个启动、看日志变绿。它是你的软件第一次进入一个你无法控制的环境，然后在那里，所有你在自己机器上默认成立的东西，一条一条不成立。

后来我知道这个岗位有个名字：FDE，Forward Deployed Engineer，前沿部署工程师。

一、Demo 环境和客户环境，是两个物种

在我自己的环境里，一切是我搭的：干净的数据库、标准的 JSON、我熟悉的网络、我能 ssh 进去改任何东西的机器。

在客户那里，这些东西全部反过来：

• 数据不是 JSON，是三种编码混在一起的 CSV，还有一列是 Excel 公式生成的；
• 网络不出外网，我的服务要调的外部 API 全部超时；
• 权限不是"我有 root"，是"我申请了三天才拿到一个只读账号"；
• 老系统没有 API，只有一个每天凌晨导出一次的数据库快照。

Demo 演示的是"功能正确"。部署要解决的是"在这一切都不对的条件下，功能还能正确"。

这两件事之间的差距，不是靠更好的代码补上的，是靠有人真的站在那个环境里，一条一条把不对的东西捋顺。这就是 FDE 干的活。

二、FDE 不是售后，是带着编辑器上现场

很多人以为 FDE 就是"高级实施"或者"驻场支持"——客户报问题，你记录、转给研发、等排期。

不是。FDE 的核心特征是：他写代码，而且是在客户现场写代码。

我那次驻场，最后跑起来的东西里，有一半是我在机房里现写的胶水层。产品的主干逻辑没动，动的是它和客户世界之间的那层翻译：

# 客户的老系统每天导出一个"宽表"，字段名带中文、有空值、日期格式不统一
def adapt_legacy_row(row):
    return {
        "id": row["编号"].strip(),
        "amount": float(row["金额"] or 0),          # 空值按 0 处理，和客户确认过
        "date": parse_cn_date(row["发生日期"]),      # 兼容 2024/1/5 和 2024-01-05
    }

这几十行代码没有任何技术含量，但它决定了产品能不能在这个客户这里产生价值。研发在总部写不出来，因为他没见过这张表；客户自己写不出来，因为他不懂产品的数据模型。只有站在中间的人能写。

FDE 就是这个"站在中间的人"。他不是产品的延伸，也不是客户的代理，他是两者之间的翻译层，而且这个翻译层是用代码写的。

三、真正的产出不是代码，是"翻译"

驻场两周，我改的产品代码只有几十行，但我在周报里写了三页。那三页后来变成了产品的三个改动：

• 客户的环境普遍没有外网 → 产品加了一个离线授权模式；
• 客户的日期格式五花八门 → 数据接入层加了可配置的解析规则；
• 客户的权限申请流程要走一周 → 部署文档里补了一份"最小权限清单"，让客户 IT 提前准备。

这三条，没有一条是我在总部能想到的。它们不是我"猜"出来的需求，是我在机房里被现实按着头学会的。

所以 FDE 的真正价值，不在于他现场写了多少代码，而在于他把现场的现实，翻译成了产品能听懂的语言，并且带着证据——那份 CSV、那条超时报错、那个权限申请单——回到研发面前。

没有 FDE，产品团队对"客户环境"的认知永远停留在想象里。有了 FDE，每驻一次场，产品就少一个想当然的假设。

四、AI 时代，为什么 FDE 反而更值钱

有人会说：AI 都能写代码了，现场那点胶水活，让模型生成不就行了？

恰恰相反。AI 让"写代码"变便宜，于是瓶颈从"能不能写出来"转移到了"知不知道要写什么"。而"知道要写什么"，只能靠站在现场。

模型没见过客户那张带公式的 CSV，没见过那个每天凌晨导出的快照，没见过 IT 部门那套三天批一个账号的流程。它可以给你一百种解析日期的写法，但它不知道这个客户的数据里，日期字段有一半是空的、另一半混着两种格式、还有三行是测试数据忘了删。

这些知识不在任何训练集里，只在一个人的现场经验里。FDE 带回来的，正是这种无法被爬取的知识。

所以我的判断是：AI 越强，FDE 越重要。因为标准化的工作被自动化之后，剩下的全是非标准的、现场的、需要有人真的蹲下去看的东西。而"蹲下去看"这件事，短期内没有模型能替。