AI带火了FDE岗位，但它的价值远不止于驻场开发。本文深入拆解FDE如何从业务现场挖掘真实需求、通过七步工作流将模糊问题转化为可运行系统，并厘清其与产品经理、工程团队的协作边界。最终揭示：一个成功的FDE项目，是让系统在FDE离场后依然能自主运转。 ———— / BEGIN / ———— AI直接带火了FDE这个岗位，很多公司已经开始开始招募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不是只负责开账号。它要把数据、网络、身份和审