企业上AI项目，FDE到底在做什么？

随着人工智能技术的普及，FDE（现场开发工程师）这一职位逐渐受到关注，许多企业已开始招聘FDE或要求其驻场工作。

职位名称听起来颇为专业，但实际工作内容相当务实：前往客户现场、了解业务流程、接入数据、构建原型、调试系统、协助上线。

核心差异在于：责任的终点在何处。

如果项目交付仅止于“演示能运行”，那它仍只是一次展示。若FDE离开后，系统无人会用、无人敢改，出现问题只能等待原团队返回，那么项目尚未完成。

我认为FDE的角色是连接业务现场、技术实现与产品沉淀的桥梁。他既要交付成果，也要确保成果融入实际工作。

一、首先观察客户如何运作

AI需求通常不会整齐地列在需求表中等待发现。

业务人员可能说：“我们想要一个知识库”“希望AI自动汇总”“最好能帮忙写报告”——这是用户期望，并非产品方案。

有价值的信息往往藏在他的电脑里：

• 二十多个部门用同一份Excel报送，每月需手动合并。
• 一份年鉴包含文字、图片和扫描件，查找一句话需花费大量时间。
• 同一指标在不同报告中口径各异，写材料的人需记住哪个版本可用。

用户说“汇总”，实际需求是按固定栏目合并、保留来源、生成可继续修改的初稿。

因此，FDE进场后，并非先画架构图，而是让业务人员打开正在处理的文件和系统，完整演示一遍。

然后，通过追问以下问题：

• 这项工作多久做一次，谁负责？
• 输入材料来自何处，格式是否稳定？
• 哪一步最耗时，哪一步最依赖经验？
• 什么结果可直接使用，什么结果必须复核？
• 出错后谁承担责任，如何补救？

将问题与实际结合，才能把“AI帮我处理材料”拆解为可执行的任务。

例如，资料汇总可分解为文件识别、字段映射、内容合并、来源标记、格式输出和人工校对。前两步可能需要模型，字段合并依赖规则，最终交付需保留人工修改。没有这种拆解，项目容易从小样板膨胀为“企业知识管理平台”。

二、FDE的工作流程

一个成熟的FDE项目通常经历七个阶段：

1. 发现真实任务

访谈不是问“你想要什么AI功能”，而是观察用户如何完成工作。需获取真实文件、真实输入、真实异常和真实产出。

2. 划定最小场景

企业通常有长串需求，但第一期不能全部承接。优先选择高频、数据相对可得、结果可检查、错误有退路的场景。

例如，先做“查询正式材料并返回出处”，而非“自动完成全部材料生产”。先让一个部门真实使用，再决定是否扩展。

3. 确认数据和权限

FDE需明确资料由谁负责、哪些版本有效、谁能查看、哪些字段不能提供给外部模型。数据接入不是简单拖入知识库，而是确认来源、格式、更新和责任人。

企业权限往往比技术文档复杂。同一份资料，对总部、分公司、项目组和外部供应商的可见范围可能完全不同。能查到不等于应该展示。

4. 快速做出最小原型

原型不是为了让会议室里的人惊叹，而是尽早暴露问题。第一版可只覆盖一个部门、一批真实资料和几类真实任务，但必须让业务人员上手。

此时最重要的反馈不是“回答像不像人”，而是“这次结果能否直接用于工作”。

5. 接入真实系统

原型可通过上传文件运行，但生产系统不能永远依赖手动上传。FDE需参与账号、网络、接口、日志、数据同步、异常重试和环境隔离的设计。

许多AI项目到这一步才发现，客户系统没有可用接口，字段没有统一口径，测试环境与生产环境不一致。FDE需提前暴露这些障碍，不能等到上线前才发现。

6. 和真实用户一起验证

用户测试不是让客户看演示，而是让他用自己的任务操作。需专门测试资料缺失、版本冲突、权限不足、接口超时和答案不存在的情况。

一个能在正常问题上回答良好的助手，若遇到无答案仍编造，就不能算完成。

7. 上线、采用和回流

上线只是开始。FDE需跟踪用户是否真正使用、哪些环节仍依赖人工、哪些问题反复出现。重复的现场问题需判断是补数据、改流程、做通用能力，还是明确排除在产品范围外。

这一步决定FDE是在交付一次性项目，还是在帮助产品积累下一项能力。

三、FDE和其他岗位如何协作

FDE不是“什么都做的人”。如果没有明确接口，最终往往变成谁都找FDE救火。

在团队中，FDE与其他岗位的协作如下：

产品经理不应将现场方案全部丢给FDE。哪些问题值得成为通用能力、哪些只是客户特例，需产品经理判断。

核心工程团队不应将FDE视为外包开发。现场代码若要进入长期产品，必须经过架构、测试、安全和维护责任的审查。

客户IT不只是负责开账号。它需明确数据、网络、身份和审计要求；客户业务负责人则需确认系统改变了哪一步工作，谁来承担最终责任。

四、FDE项目的验收标准

最好的FDE项目，允许FDE离场。

FDE的真正价值，不是让客户永远依赖一个人。

如果每个新客户都要从清洗文件、搭建接口、解释权限开始，说明经验仍停留在个人身上。成熟的做法，是把现场经验沉淀为模板、组件、规则、测试样例和操作手册，使下一次交付更快、更稳。

项目结束时，应留下几类东西：

• 场景说明：解决谁的什么问题，不解决什么问题。
• 数据台账：资料来源、版本、责任人和更新方式。
• 权限清单：谁能看、谁能改、谁能审批。
• 评估集：正常、边界、无答案和高风险样例。
• 运维手册：故障如何定位，何时转人工。
• 复用组件：接口、提示模板、流程节点和行业规则。
• 交接记录：内部团队能否独立修改和发布。

FDE离场后，如果系统仍有人使用，内部团队能独立维护，供应商下一次交付不必从头开始，项目才算真正完成。

FDE不是把客户需求翻译成代码的人，也不是为售前承诺兜底的人。它更像一个结果导向的岗位：把现场的模糊问题转化为可验证的任务，把一次性方案变成可运行的系统，再把现场经验带回产品。

AI项目最终比拼的不是谁能最快做出一个Demo，而是谁能让业务在无人监督的情况下，继续把事情做好。

本文来自微信公众号“人人都是产品经理”（ID：woshipm），作者：半杯丿清茶，36氪经授权发布。