FDE 前沿部署：从“驻场交付”到组织能力的工程化路径

一、范围锚定：先定义“什么叫成”，再写第一行代码

FDE 项目最常见的失败模式不是技术跑不通，而是跑通了一个客户并不真正需要的方向。OpenAI 的 FDE 岗位描述反复强调同一个动作：discovery 在 build 之前。FDE 需要“拥有从发现、技术范围界定、系统设计、构建到生产上线的全流程”，而不是接到需求就开始写代码。

Cresta 的 FDE 团队在一年内从 1 人扩展到 50 余人，他们总结的核心经验是：客户不为 demo 付费，他们为“demo 到生产之间的距离”付费。原型达到 80% 的生产就绪度可以很快，但剩下 20% 需要领域语言、边界用例、标注数据、真实测试集、权限和合规。这 20% 才是 FDE 真正的工作量所在。

实操上，范围锚定需要回答三个问题：数据从哪来、谁有权访问、系统产出最终由谁做出什么动作。OpenAI 金融服务的 FDE 岗位要求工程师“将模糊的业务问题转化为假设驱动的问题框架、系统需求和可衡量的交付计划”。这意味着 FDE 不能只做技术翻译，必须参与定义“什么算成功”。

一个被低估的动作是：把“不做什么”写得和“做什么”一样清楚。嵌入客户现场时，每个用户都有功能请求，如果 FDE 像 PM 一样对一切说“是”，聚焦的解决方案就会膨胀成一团乱麻。一页纸的任务简报，比任何口头共识都更能在三周后防止范围失控。

二、评测驱动：没有评估集的功能，不算完成

AI 交付与传统软件交付的根本区别在于验收标准。传统功能的验收是“逻辑是否正确”，AI 功能的验收是“效果是否可接受”。而“可接受”是一个需要被量化的模糊词。

Cresta 有一条被明确写出的纪律：“我们永远不会在没有评估的情况下发布”。原因很直接：一个在某个垂直领域表现良好的提示词，换一个场景可能完全失效。在医疗场景中始终表达同理心可能是对的，但在金融催收场景中，当用户欠款 4000 美元时，智能体过度共情会让客户产生复杂的感受。

OpenAI 的 FDE 岗位同样将评估置于核心位置：成功通过“生产采用率、可衡量的工作流影响，以及改变产品和模型路线图的评估驱动反馈”来衡量。金融服务方向更具体：需要定义和执行“与风险和性能挂钩的评估基准和验收阈值”。

评估集的构建方式通常是“专家轨迹”：让真正做这件事的人演示他们如何完成一次判断或操作，FDE 把这些操作序列转化为可自动运行的测试用例。国内 FDE 岗位的职责描述中也出现了对应要求：定义任务完成率、工具调用准确率、上下文命中率、人工节省时间等指标，推动项目从演示型 Demo 走向可验收试点。

一个容易犯的错误是样本量不足就放行。三个测试用例全部通过就上线，是 AI 交付中的经典事故来源。评估闸门应该设置最低用例数门槛和通过率阈值双重条件。

三、资产化：项目结束时，带走的比留下的更重要

FDE 与驻场外包的分水岭在项目收尾时最为清晰。Palantir 模式的精髓是双向沉淀：面向客户，把散落在员工脑中的业务经验固化为系统逻辑；面向公司，把现场遇到的通用问题剥离客户信息后沉淀为平台能力。Cresta 的 FDE 直接坐在产品工程组织内，可以向产品直接提交 pull request，一个 FDE 在项目上学到的东西会成为平台的永久部分，下一个客户从更强的基线出发。

对于不具备 Palantir 规模的团队，可操作的资产化粒度可以更细。腾讯 WorkBuddy 的 FDE 交付能力检验覆盖“交付能力、知识资产、机制组织”三个领域，关注现场经验能否沉淀为可复用的组织资产。国内 FDE 岗位的职责中也明确要求：将项目中形成的业务流程、场景模板、上下文模板、Prompt 模板、Agent 角色配置、Skill 模板、评测指标沉淀为可复用资产。

关键判断标准是：下一个同类客户进来时，交付周期的哪个环节可以缩短。如果答案是“没有”，这次交付就只是一次外包。Cresta 的 FDE 在多个客户身上看到相同的任务模式后，会将其转化为内部工具或产品能力，部分 FDE 甚至设计并构建了全新的产品线。

四、一段可嵌入交付流水线的评估闸门代码

以下代码实现一个最小化的评估闸门，用于在每次交付版本发布前自动检查效果是否达标。它不依赖特定框架，可直接嵌入 CI 流程。核心逻辑是：读取评估集，逐条跑过当前系统，统计通过率，仅在用例数足够且通过率达标时放行。

import json

def delivery_gate(eval_path: str, predict_fn, threshold: float = 0.85, min_cases: int = 30):
    """
    FDE 交付闸门：验证系统在客户确认的评估集上是否达到发布标准。
    eval_path: JSON 文件，格式 [{"input": "...", "expected": "..."}, ...]
    predict_fn: 接受单条输入，返回系统输出字符串。
    """
    with open(eval_path, "r", encoding="utf-8") as f:
        cases = json.load(f)

    if len(cases) < min_cases:
        return False, f"评估集仅 {len(cases)} 条，低于最低要求 {min_cases} 条，拒绝放行"

    passed, failures = 0, []
    for case in cases:
        output = predict_fn(case["input"])
        if case["expected"] in output:
            passed += 1
        else:
            failures.append({
                "input": case["input"][:120],
                "expected": case["expected"][:120],
                "actual": output[:200]
            })

    rate = passed / len(cases)
    if rate < threshold:
        return False, f"通过率 {rate:.1%} 低于阈值 {threshold:.0%}，{len(failures)} 条未通过：{failures[:3]}"

    return True, f"闸门通过：{passed}/{len(cases)}（{rate:.1%}）"

# 接入 CI 示例：
# ok, msg = delivery_gate("client_eval.json", lambda x: call_your_system(x))
# if not ok:
#     raise SystemExit(msg)

这段代码的关键不在实现复杂度，而在两个参数的纪律性：min_cases 防止小样本侥幸通过，threshold 提供可量化的发布标准。评估集中的 expected 字段应由客户的领域专家确认，而非 FDE 自行填写。Cresta 的经验是：FDE 不花所有时间和客户待在一起，单次客户差旅不超过五天，大部分时间在远程构建和评估。评估集就是远程工作的“客户代理”。

五、交付负责人真正需要盯住的三件事

回到管理视角，FDE 交付的成败很少取决于工程师的编码水平，而取决于三件更前置的事。

第一，FDE 坐在哪个组织里。Cresta 将 FDE 放在产品工程组织内，向工程汇报，而非向 GTM 或客户成功汇报。这个结构决定了 FDE 能否直接向产品提交代码、能否把现场经验变成平台能力。如果 FDE 汇报给交付部门，资产化就缺少组织动力。

第二，评估集是否在开发启动前就绪。如果评估集是在系统“基本做完”之后才拼凑出来的，它反映的是系统的现有行为，而非业务的真实要求，闸门形同虚设。OpenAI 的 FDE 岗位将“评估驱动反馈”写入成功衡量标准，意味着评估不是交付的附属品，而是交付本身的产出之一。

第三，差旅节奏是否服务于关键节点。Cresta 的做法是差旅集中在 discovery 和 launch 两个阶段，因为这是最有价值的学习发生的时刻。中期的大部分工作在远程完成，FDE 同时运行两到四个项目。这种节奏既控制了成本，也避免了“驻场等于陪伴”的误区。

FDE 模式在 AI 时代被重新定价，根本原因是模型能力越强，“把能力装进客户真实流程”这件事反而越贵。交付团队的价值不在于让模型跑起来，而在于让模型在客户的约束条件下持续跑对，并且下一次跑得更快。这个判断标准，比任何岗位描述都更值得放在交付流程的第一行。