AI技术催热了FDE这一职位，但它的角色远非简单的现场开发。本文深入剖析FDE如何从业务一线挖掘真实需求，运用七步工作法将模糊问题转化为可运行系统，并明确其与产品经理、工程团队的合作界限。最终揭示：一个成功的FDE项目，关键在于系统在FDE离开后仍能自主运行。

AI直接推动了FDE岗位的走红，许多公司已开始招募FDE或要求其进驻现场。

职位名称听起来高端，实际工作却很接地气：深入客户现场、理解业务流程、处理数据、搭建原型、调整系统、陪同上线。

核心差异在于：责任的终点在哪里。

如果项目交付仅止于“Demo能跑”，那仍只是一次展示。若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氪经授权发布。