FDE 交付：交付物不是软件，是一条能被现场证据证伪的运营闭环

FDE（前线部署工程师）在国内被大量讨论为“驻场写代码的人”，但 Palantir 对 Delta 的定义恰恰相反：“一个客户，调用多种能力”，成败看对客户目标的实际影响，而非交付了多少功能。OpenAI FDE 负责人 Colin Jarvis 的表述更尖锐：FDE 的北极星是“You must leave with product”——必须带着产品离开，而这个产品不是代码仓库，是一条在真实业务中跑通、可观察、可回滚的运营闭环。联想为某大型家电制造企业用三个月交付两个智能体，成品库存降低 70%，其交付过程并非从架构设计开始，而是 FDE 前置客户现场，与业务方共同锁定“产品生命周期及库存挑战”“销售预测及需求计划不准确”两个高价值场景。这组数据的因果链不在模型强弱，而在于交付物被重新定义：不是功能清单，是一条以可验证指标为终点的最小闭环。

闭环的起点：拒绝 86 行需求，锁定一个可运行问题

恒川工业缺料项目的启动会上，需求清单已有 86 行，计划员只用一句话就把它压回一个真实问题：“明天下午排产冻结前，M-1042 再短缺，我能不能看清证据，提交方案，让经理批准，并知道 ERP 和 WMS 到底有没有执行？”FDE 交付的第一项工程动作，不是接数据，而是把模糊的“要 AI”翻译成可判定成功或失败的闭环定义。百度智能云 FDE 团队的做法是“短平快”：上午与客户沟通一两个小时，把模糊需求翻译成 AI 能理解的需求文档，下午做出 Demo 初稿给客户看。这个 Demo 的价值不在于完整，而在于它第一次把“问题是否被解决”变成了可观察的对象。

数据契约：让“现场事实”先于模型存在

FDE 在现场最常见的返工来源，不是模型效果差，而是字段语义在源系统里就没有稳定定义。同一个“库存数量”，在 ERP 里按入库时间计，在 WMS 里按可用量计，在排产系统的 Excel 里按锁定批次计。没有一层机器可检查的契约，任何分析都是在猜谜。数据契约的作用，是把“谁生产、字段代表什么、何时算新鲜、变更如何通知”写成可被 CI 校验的约束，而不是散落在会议纪要里。以下是一个最小化的契约校验片段，字段语义在数据进入管道之前就被机械判定，不合规的数据直接阻断而非带病下游：

from dataclasses import dataclass

@dataclass
class FieldContract:
    name: str
    dtype: str
    required: bool
    semantics: str          # 业务含义，必须非空
    freshness_minutes: int

def validate_contract(sample_row: dict, fields: list[FieldContract]) -> list[str]:
    errors = []
    for f in fields:
        if f.required and f.name not in sample_row:
            errors.append(f"MISSING: {f.name} ({f.semantics})")
        if f.name in sample_row and not f.semantics.strip():
            errors.append(f"SEMANTICS_UNDEFINED: {f.name}")
    return errors

# 管道入口：契约不通过则不进入转换层
contract_fields = load_contract("contracts/orders.yaml")  # Schema + 语义 + SLA
if validate_contract(incoming_row, contract_fields):
    quarantine(incoming_row)   # 隔离，而非静默丢弃

这段代码的工程含义在于：“现场事实”的可靠性不能依赖 FDE 的个人记忆，必须沉淀为代码可执行的边界。契约之外的数据不进入闭环，契约内的字段语义歧义在入口处就被消灭。

最小闭环的验收：回测而不是演示

FDE 交付中最容易被跳过、也最决定成败的一步，是用历史真实数据回测闭环。Demo 能跑通不代表闭环成立；闭环成立的证据是：在已知的历史时段内，系统给出的判断与人工复盘的真实结果之间，偏差可以被量化。联想的 FDE 实践将交付过程拆为三步，其中一步是“与业务方共同梳理高价值场景”，本质上是先确定可回测的判定标准，再构建智能体。以下是一个针对补货闭环的回测骨架，核心不是预测精度本身，而是把“闭环是否值得继续”变成一次可重复执行的代码判定：

def backtest_reorder(sku: str, history: pd.DataFrame, horizon_days: int = 14):
    """
    history: 包含 date, stock, consumption, reorder_fired, actual_stockout
    """
    hits, false_alarms = 0, 0
    for i in range(horizon_days, len(history) - horizon_days):
        window = history.iloc[i-horizon_days:i]
        if not reorder_rule(window, sku):      # 确定性阈值规则
            continue
        future = history.iloc[i:i+horizon_days]
        if future["actual_stockout"].any():
            hits += 1
        else:
            false_alarms += 1
    # 闭环放行的条件由业务方在契约中事先约定，而非事后解释
    return {
        "hit_rate": hits / max(hits + false_alarms, 1),
        "false_alarm_rate": false_alarms / max(hits + false_alarms, 1),
        "decision": "expand" if false_alarms <= 2 and hits >= 1 else "revise"
    }

decision 的阈值不是 FDE 在现场的即兴判断，而是在进入客户现场之前就与业务方写入 thin-slice contract 的阻断条件。回测输出 revise 时，闭环不进入生产；输出 expand 时，闭环从“一个 SKU 的补货判断”扩展为可复用的品类规则。Gartner 的警示在这里尤其适用：如果 FDE 的成功仅仅被定义为“项目交付”，客户购买的不过是专业服务；真正的分水岭是交付物在 FDE 离场后是否仍然被使用、可被修改、能自主运转。

离场条件：客户能独立诊断闭环的失败

FDE 交付完成的标志，不是系统上线，而是客户团队能够独立解释闭环为什么在某一天失效，并知道如何升级或回退。知识转移因此不是最后一周的培训，而是从第一天开始的共同建造：客户参与验收样例的设计、运行手册的编写、事故复盘的定义，本身就是能力建设。一个可操作的离场门禁是：客户运维在没有 FDE 在场的情况下，独立完成一次“注入异常—观察告警—定位到契约字段—执行回退—恢复闭环”的全流程演练，且演练记录作为交付证据归档。没有通过这一门禁的项目，Demo 再流畅，闭环仍然依附于 FDE 的个人在场，而非客户的运营系统。

FDE 交付的专业性，最终不体现在代码量或驻场时长上，而体现在交付物的可证伪性：闭环是否有事先写定的阻断条件，回测是否有可重复执行的判定，契约是否在数据入口处机械生效，客户是否在 FDE 离场后仍能独立诊断失败。当这四件事同时成立，交付的才不是一次项目，而是一条客户可以继续拥有和演进的运营能力。