FDE 到底是什么：从现场问题到生产工作流

很多企业 AI 项目结束在“模型能回答”“环境装好了”或“演示通过”。真正进入生产还要回答：谁在什么时点使用、输入从哪里来、输出由谁复核、异常怎样处理、系统变更后谁负责。

Palantir 的官方架构说明把 FDE 描述为贴近真实问题、持续把现场反馈送回核心产品的工程方式；OpenAI 的 FDE 岗位说明则把发现、范围界定、系统设计、构建和生产上线放在同一条责任链上。两者都是方法或岗位定义，不是项目效果证明。

适合谁

• 已经有一个高频或高影响流程，但 AI 仍停留在个人试用或 Demo 的团队。
• 数据、权限、系统接口和人工责任相互牵连，无法靠买一个账号解决的企业。
• 愿意提供脱敏样本、指定业务复核人，并按证据验收的项目负责人。

FDE 解决的不是“模型问题”，而是完整工作问题

一个可交付的工作问题至少包含六个部分：触发条件、输入材料、业务规则、工具动作、人工判断和可回读结果。只优化提示词，通常只覆盖其中很小的一段。

和铭把 FDE 的最小闭环定义为：现场发现 → 流程映射 → 数据与权限确认 → 受控原型 → 真实试用 → 人工门禁 → 评测与验收 → 培训交接 → 反馈进入可复用资产。

前置条件

• 一个明确的流程负责人，而不是笼统的“全公司都要用”。
• 一组经过授权和脱敏的真实样本，能够代表常见情况与边界情况。
• 当前流程的操作人、复核人、系统入口和失败处理方式可被访谈或观察。
• 允许把“暂时不自动化”作为正确结论。

从现场问题到生产工作流的八步

1. 写清业务结果

先描述需要减少的等待、遗漏、重复录入或判断负担，再决定是否需要模型。输出是一句可核对的目标和一名结果负责人。

2. 画出当前流程

记录谁收到什么、在哪个系统操作、怎样判断、交给谁、如何确认完成。不要只访谈管理者，还要看一线人员真正怎样工作。

3. 划定数据与权限

逐项标记公开、内部、敏感和高影响数据；确认哪些材料能进入模型、保存多久、谁可访问。边界不清的数据默认不进入试点。

4. 建立基线与评测集

保留当前人工处理结果，选取正常、异常和高风险样本。先写通过条件，再做原型，避免用几张“好看的结果”代替评测。

5. 做最小受控原型

原型只覆盖一个任务和有限动作。模型可以起草、提取、分类或给出建议，但不能绕过人工完成正式提交、付款、删除或高影响决定。

6. 接入真实工作流

把输入、权限、版本、日志、异常和回退接入现有系统。生产上线不是把 Demo 换一个网址，而是明确运行责任和故障路径。

7. 用真实采用证据验收

验收既看输出质量，也看是否重复使用、人工覆盖是否可接受、异常是否被发现、业务人员能否独立操作。一次演示成功不等于采用。

8. 把现场反馈变成复用资产

把规则、评测样本、失败模式、操作手册和接口适配沉淀为版本化资产。OpenAI Academy 的 Agent Activator 资源也强调贴近流程的人与负责人、部署团队和管理员之间的反馈闭环；这是一种组织方法参考，不是统一标准。

检查点

• 每个自动动作是否都有输入来源、责任人和失败处理。
• 高影响输出是否保留人工门禁。
• 评测是否同时包含常见、异常和禁止场景。
• 日志能否回答谁在何时用哪个版本处理了什么。
• 业务人员是否能在工程师不在场时完成标准操作和回退。

失败信号

• 目标是“把 AI 用起来”，却没有具体流程和结果负责人。
• 只用演示样本，不保留人工基线和异常样本。
• 把模型准确率当作唯一验收标准，忽略权限、采用和故障处理。
• 工程师离场后，团队不知道怎样运行、复核或恢复。

可下载模板

使用《FDE 现场流程映射卡》记录触发、输入、规则、人工门禁、证据和回退。它只用于范围澄清，不替代正式安全、合规或项目验收文件。

和铭提供什么

公开内容帮助团队先把问题说清。需要付费的部分，是在具体环境中完成访谈与诊断、数据和权限设计、系统集成、受控试点、评测验收、驻场交接和持续运维。