AI带火了FDE岗位，但它的价值远不止于驻场开发。本文深入拆解FDE如何从业务现场挖掘真实需求、通过七步工作流将模糊问题转化为可运行系统，并厘清其与产品经理、工程团队的协作边界。最终揭示：一个成功的FDE项目，是让系统在FDE离场后依然能自主运转。

AI直接带火了FDE这个岗位，很多公司已经开始开始招募FDE，或者是要求FDE入驻了。

岗位名字倒是听起来高大上的，实际上工作内容还是比较落地的：进客户现场、理解业务、接数据、做原型、调系统、陪着上线。

真正的区别在于：责任终点在哪里。

如果项目交付的终点只是“Demo能跑”，那依然只是一次展示。如果FDE离场后，系统没人会用、没人敢改，出了问题只能等原来那几个人回来，这个项目就还没完成。

我理解的FDE，是一个把业务现场、技术实现和产品沉淀连起来的人。他既要把东西做出来，也要确认这件东西进入了真实工作。

一、先看客户怎么工作

AI需求通常不会整齐地写在需求表里等着你去发现。

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

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

• 二十多个部门用同一份Excel报送，每个月都要手工合并。
• 一份年鉴里有文字、图片和扫描件，查一句话要翻很久。
• 同一个指标在不同报告里有不同口径，写材料的人必须记住哪个版本能用。
• 用户说要“汇总”，实际要的是按固定栏目合并、保留来源、生成可继续修改的初稿。

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

然后，开始通追问这几件事：

1. 这项工作多久做一次，谁来做？
2. 输入材料从哪里来，格式是否稳定？
3. 哪一步最消耗时间，哪一步最依赖经验？
4. 什么结果可以直接用，什么结果必须复核？
5. 出错以后谁负责，如何补救？

问题与实际情况结合，才能把“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，而是谁能让业务在没有人盯着的情况下，继续把事情做下去。