AI 进入企业不再是简单的聊天框植入，而是需要深入业务场景的‘前线作战’。FDE（Forward Deployed Engineer）作为新兴岗位，正成为模型落地的关键推手——他们需要拆解混乱的业务流、设计数据与权限的缝合方案，甚至重构整个工作流程。本文将揭示为何模型越强大，企业越需要这群‘产品侦察兵’，以及他们如何用工程思维解决AI落地的最后一公里问题。

几年前，一家公司要接入AI，最常见的动作是做一个聊天框。

找一家模型厂商，申请API，搭建知识库，在网页右下角加一个机器人图标。领导来体验时，它能回答几个常见问题；项目汇报时，PPT 上也终于有了“AI 应用”的一页。

三个月后，真正使用它的人寥寥无几。

客服仍然在复制粘贴，销售仍然在几十个系统之间来回切换，运营仍然要手工整理表格，研发仍然在会议里讨论“模型有时不太稳定”。

问题出在哪里？

不是模型不够聪明。

而是企业真正需要解决的问题，从来不是“能不能接入一个模型”，而是：

能不能把模型塞进复杂、混乱、不断变化的工作现场里，让它每天稳定地帮人完成任务。

这件事比做一个演示难得多。

一个真实的企业系统里，通常存在多个数据源、不同层级的权限、历史遗留系统、说不清楚的业务规则，以及一群没有时间研究Prompt 的一线员工。模型需要知道什么时候可以自动处理，什么时候必须让人确认；答案出错后，需要知道从哪里追溯；模型更新之后，还要重新测试。

当越来越多公司开始碰到这些问题，一个过去主要出现在Palantir 等企业服务公司中的岗位，重新进入了行业视野：

FDE，Forward Deployed Engineer。

2026 年 5 月，OpenAI 宣布成立 OpenAI Deployment Company，专门帮助企业把 AI 用在日常业务中。官方公告明确提到，这家公司会把 FDE 派进组织内部，与业务负责人、技术团队和一线员工一起寻找问题、重做流程、开发系统并完成上线。OpenAI 同时宣布计划收购应用 AI 咨询与工程公司 Tomoro，引入约 150 名有经验的 FDE 和部署专家。[资料 1]

Anthropic 也正在招聘 Forward Deployed Engineer。其公开岗位说明中写得很直接：FDE 会进入重要客户的系统，使用 Claude 模型开发生产级应用，交付 MCP Server、子 Agent 和 Agent Skill 等可以直接进入工作流程的技术组件，并将可重复的方法整理后反馈给产品和工程团队。[资料 2]

Databricks 也建立了 AI FDE 团队，帮助客户开发并上线新型生成式 AI 应用。其招聘页面列出的工作内容包括 RAG、多智能体、Text2SQL、模型微调、效果评估和性能优化。[资料 3]

这不是一个普通的招聘热点。

它透露出一个更重要的行业变化：

当模型能力越来越容易获得，真正昂贵的部分，正在从“拥有模型”转向“把模型用起来”。

对于中国移动互联网从业者而言，FDE 值得关注，不只是因为它可能成为一个新的职业方向。

更重要的是，它正在重新定义产品经理、工程师、解决方案架构师和实施团队之间的分工方式。

图1 FDE 的核心不是做一个聊天框，而是把 AI 带进真实工作现场。

一、先把误解说清楚：FDE 不是前端工程师

第一次看到FDE，很多人会把它理解成“前端部署工程师”。

这很正常。

中国互联网行业长期使用FE 表示 Front-End Engineer，中文一般翻译为前端工程师。FDE 多了一个字母，很容易被理解成一种与前端开发、运维部署相关的技术岗位。

但FDE 中的 F，并不是 Front-End，而是 Forward。

完整名称是：Forward Deployed Engineer。

更准确的中文翻译可以是“前线部署工程师”“前置部署工程师”或“前沿部署工程师”。

它的核心不在于写前端，也不在于部署服务器。

“Forward Deployed”更接近一种作战概念：不是留在后方等待别人把需求整理清楚，而是走到最接近问题的地方，在现场判断情况并解决问题。

OpenAI 对 FDE 的岗位描述非常清楚。

FDE 需要与重要客户一起完成前沿模型的生产部署，负责需求发现、技术范围界定、系统设计、开发和正式上线。衡量工作结果的方式，不只是功能有没有完成，而是系统有没有真正被使用、工作流程有没有发生可以量化的变化，以及现场反馈能不能推动产品和模型继续改进。[资料 4]

换成更容易理解的话说：

FDE 不是负责向客户介绍 AI 能做什么的人，而是负责让 AI 在客户公司里真正开始工作的人。

这意味着，他可能要做很多不同类型的事情：

• 跟客服主管一起听投诉录音，找到最耗费人工时间的问题；
• 跟销售团队讨论哪些信息可以自动生成，哪些必须由业务人员确认；
• 阅读客户的数据库结构，确认模型能读取哪些字段；
• 编写接口，把模型接入企业原有系统；
• 建立测试集，判断模型在哪些场景容易出错；
• 设计人工审核机制，避免错误答案直接进入生产流程；
• 上线后查看日志，找到员工不愿意使用系统的原因；
• 把重复出现的问题整理成产品需求，反馈给核心研发团队。

其中可能包含前端页面，也可能没有。

FDE 的重点不是技术栈，而是结果。

二、为什么模型越来越强，企业反而更需要人？

很多人第一次听到FDE 时，会产生一个疑问：

AI 已经可以写代码、做分析、生成报告，为什么企业还要高薪招聘一批工程师进入客户现场？

答案恰恰在于：模型能力越强，企业越容易低估真正上线的难度。

图2 企业真正的难点在于把模型、数据、权限和流程连接起来。

1. 企业买到的是能力，不是可以直接使用的答案

假设一家连锁零售企业希望使用AI 分析门店经营情况。

一个模型确实可以阅读销售报表、总结问题，并生成建议。

但真正开始做时，很快就会遇到一连串具体问题：

• 不同门店的数据格式不一致怎么办？
• 促销活动、天气和节假日信息从哪里获取？
• 店长可以看到哪些数据，区域经理可以看到哪些数据？
• AI 给出的建议是依据什么生成的？
• 如果模型把某个门店的异常情况判断错了，谁来复核？
• 数据每天更新一次，还是实时更新？
• 结果应该出现在聊天框里，还是直接进入门店管理系统？
• 员工是否愿意改变原来的工作习惯？

这些问题中，只有一部分是模型问题。

更多问题来自产品设计、数据管理、权限配置、业务流程和组织协作。

API 可以购买。

工作方式不能一键购买。

2. AI 产品不能只靠传统验收方式

传统软件更像一台自动售货机。

点击某个按钮，系统按照固定规则返回结果。

测试人员可以写清楚：输入A，应该得到 B；输入 C，应该得到 D。

大模型不同。

同一个问题换一种表达方式，可能得到不同答案。同一段材料中，它可能正确识别九条信息，却遗漏第十条。它可以完成复杂任务，但也可能非常自信地说错话。

因此，AI 项目的验收不能只问：功能能不能运行？

还需要问：

• 哪类问题最容易出错？
• 错误发生的概率是多少？
• 错误造成的后果有多严重？
• 哪些答案必须附带原文依据？
• 哪些场景必须由人工确认？
• 模型升级后是否需要重新测试？
• 系统速度和调用成本是否可以接受？

FDE 需要把这些问题变成具体的测试样本、审核规则和上线标准。

3. 企业真正需要的是重新设计工作方式

很多AI 项目失败，不是因为模型不行，而是因为产品只是在原有工作之外增加了一个新入口。

员工原本已经要打开五个系统，现在又多了一个聊天框。

结果当然很难持续使用。

真正有效的AI 应用通常需要进入原有流程。

例如，销售人员不应该每天主动向AI 提问：请帮我整理一下今天最值得跟进的客户。

更合理的做法是：系统自动读取客户沟通记录、订单情况和近期行为，在销售每天打开CRM 时，直接显示最值得关注的客户、判断依据和下一步动作建议。

客服人员也不应该在回答用户问题时，额外复制一段文字到聊天机器人里。

更合理的做法是：客服工作台自动识别用户意图，检索对应规则，生成建议回复，并在低置信度场景中提醒人工确认。

这不是增加一个新功能。

这是重新安排一部分工作由谁完成、在什么时候完成，以及出错后由谁负责。

OpenAI 在 Deployment Company 的官方介绍中，将 FDE 的工作概括得很具体：先诊断 AI 最值得进入的场景，挑选少数优先处理的工作流程，再将模型连接到客户的数据、工具、控制机制和业务流程中，完成设计、开发、测试和上线。[资料 1]

这就是FDE 存在的原因。

三、FDE 不是突然出现的新职业

FDE 最近受到关注，与生成式 AI 的发展有关。

但这个岗位并不是由OpenAI 发明的。

较早建立类似机制的公司之一，是Palantir。

Palantir 面对的客户经常来自政府、制造、金融等复杂领域。这些客户的问题通常不是“增加一个按钮”或“开发一个页面”，而是如何把分散的数据、复杂的流程和不同部门的决策连接起来。

Palantir 将两类工程师区分得很清楚。

第一类是Software Engineer，内部称为Dev。

Dev 主要负责开发通用产品，例如平台中的存储、交互或基础设施能力。这些能力需要服务很多客户，因此更关注架构、稳定性和复用性。

第二类是Forward Deployed Software Engineer，内部称为Delta。

Delta 会与客户直接合作，使用 Palantir 的平台、开源工具和自己的工程能力，解决客户的具体问题。

Palantir 在官方文章中用一句话概括两者的区别：

Dev 关注的是“一种能力，服务多个客户”；Delta 关注的是“一个客户，调用多种能力”。[资料 5]

这句话非常值得产品经理记住。

因为它揭示了两种完全不同的产品思维。

一种思维从产品能力出发：

我们已经有这些模块，怎样让更多用户使用？

另一种思维从现场问题出发：

这个客户真正需要解决什么问题？现有能力应该怎样组合？还缺少什么？

这两种思维都重要。

但在一个新技术刚刚进入行业、标准答案还没有形成的阶段，第二种思维往往更重要。

AI 行业现在正处于这样的阶段。

四、为什么FDE 会在 2026 年明显升温？

Reuters 在 2026 年 2 月的一篇报道中，将 FDE 称为 AI 行业当时最热门的岗位之一。报道援引 LinkedIn 数据称，从 2023 年到 2025 年，FDE 及相近岗位的需求增长了 42 倍，全球新增岗位大约为 9000 个。[资料 6]

9000 个岗位并不算一个庞大的就业市场。

但它仍然值得关注。

因为它指向了AI 商业化过程中最难解决的问题。

1. 模型正在变成基础能力

早期的大模型竞争，重点是参数规模、推理能力、上下文长度和基准测试成绩。

这些仍然重要。

但对于企业客户而言，模型之间的差距已经不是唯一问题。

越来越多公司开始问：

• 哪一个场景可以最先节约成本？
• 哪一个部门最适合先试？
• 怎样把模型接入现有系统？
• 怎样保证输出可信？
• 如何让员工真正使用？
• 试点成功之后，如何扩大范围？

模型能力越普及，这些问题越重要。

2. 标准化软件难以覆盖所有场景

过去十几年，移动互联网和SaaS 行业都在追求标准化。

做一个产品，服务尽可能多的用户。

标准化可以降低边际成本，也更容易扩大规模。

但AI 项目有一个现实问题：

企业之间的差异，往往藏在工作流程里。

同样是处理合同：

• 互联网平台关心供应商条款；
• 银行关心合规风险；
• 制造企业关心采购周期；
• 医疗机构关心隐私和责任边界。

同样是客服：

• 电商关心退换货和物流；
• 游戏公司关心账号、充值和社区问题；
• 金融机构关心身份认证和风险提示；
• 航空公司关心航班变更和旅客安排。

底层模型可以相同。

但数据来源、权限设计、风险级别和人工审核方式完全不同。

FDE 的价值，就是在标准能力与具体现场之间找到可行方案。

3. AI 公司开始把交付经验当成产品原料

FDE 不只是一个服务客户的岗位。

它还有另一个重要作用：

帮助模型公司发现下一个应该做成标准产品的能力。

OpenAI 的 FDE Platform 团队招聘说明中提到，团队需要把客户现场中出现的问题，整理成可重复的方法和长期产品能力，而不是停留在一次性的修补上。[资料 7]

Anthropic 的 FDE 招聘页面也提出类似要求：识别并整理可重复的部署方式，再把信息反馈给产品和工程团队。[资料 2]

这意味着，FDE 不是站在产品团队外部的售后人员。

他更像一个离真实问题最近的产品侦察兵。

他一边帮助客户解决问题，一边判断哪些问题值得变成平台能力。

五、一个真实的FDE 项目，究竟是怎样推进的？

为了理解这个岗位，不妨看一个更接近真实工作的例子。

假设一家大型保险公司希望使用AI 提高理赔材料的处理效率。

每天，员工需要阅读大量事故说明、医疗材料、发票、合同条款和历史记录，再判断材料是否完整、案件是否需要补充信息，以及哪些情况需要交给更有经验的人处理。

管理层提出一个听起来很合理的需求：

做一个AI 理赔助手。

但这仍然不是一个可以直接开发的需求。

FDE 需要把它拆成一系列具体问题。

图3 一个 FDE 项目通常从观察现场开始，再进入开发、测试和上线。

第一步：先去看人是怎样工作的

不要急着打开模型控制台。

先坐到业务人员旁边，观察他们每天怎样处理案件。

需要弄清楚：

• 一份材料从哪里进入系统？
• 员工每天处理多少案件？
• 哪一步最耗时？
• 哪些信息最容易遗漏？
• 哪类案件最容易判断错误？
• 哪些规则写在文档里，哪些规则只存在于老员工经验中？
• 出错后会造成什么后果？
• 哪些案件绝对不能让AI 自动处理？

这一阶段不是“开需求会”。

而是理解真实工作。

产品经理经常犯的错误，是在会议室里采访用户，再把用户说出的解决方案原样写进需求文档。

FDE 更关注行为。

员工嘴上说最需要自动生成报告，实际花费时间最多的，可能是从几十页材料里寻找三个关键字段。

第二步：只挑一个值得先解决的问题

保险公司可能希望AI 完成很多事情：

• 自动提取材料信息；
• 检查材料是否完整；
• 识别异常情况；
• 生成案件摘要；
• 推荐处理方式；
• 自动联系用户补充材料；
• 预测理赔金额；
• 判断是否存在风险。

如果第一期全部做，项目大概率会失控。

FDE 需要判断，哪一个问题具备三个条件：

1. 发生频率高；
2. 能明显节省时间；
3. 出错后仍然可以通过人工复核控制风险。

例如，第一期只做：

从材料中提取关键字段，生成案件摘要，并标注原文位置。

这个功能看起来没有那么“智能”。

但它更容易验收，也更容易让一线员工愿意使用。

第三步：做出最小可用版本

接下来才进入开发。

系统至少需要完成：

• 接收文件；
• 识别文本；
• 判断文件类型；
• 提取关键字段；
• 生成摘要；
• 标注原文依据；
• 记录员工修改；
• 保存操作日志；
• 对低置信度结果做提醒。

注意，这里最重要的不只是生成结果。

还要允许员工检查和修改。

因为在高风险业务里，AI 不应该伪装成一个永远正确的专家。

它更适合作为一个速度很快的初级助手：先做大部分整理工作，再把不确定的地方明确标出来。

第四步：建立测试集，而不是靠感觉验收

系统开发完成后，不能让几位领导试用十分钟就宣布上线。

需要收集一批真实样本，按照业务类型、材料长度、文件质量和风险等级分类。

然后逐项检查：

• 字段提取准确率；
• 摘要是否遗漏关键信息；
• 原文引用是否正确；
• 低置信度场景是否成功提醒；
• 处理速度是否可以接受；
• 单个案件的调用成本是多少；
• 员工修改了哪些内容；
• 哪类文件最容易失败。

如果系统在常规材料中表现很好，但面对扫描模糊、格式混乱的文件经常出错，就需要明确限制范围。

不能假装它适用于所有情况。

第五步：接入原有工作台

测试有效之后，还要解决一个经常被低估的问题：

员工在哪里使用它？

如果员工必须额外登录一个新系统，上传文件，等待结果，再复制回原有工作台，使用率通常不会高。

更合理的方式是把AI 结果直接放进员工原来的操作页面中。

员工打开案件时，就能看到摘要、字段和原文位置。

发现错误，直接修改。

遇到不确定结果，系统自动提醒人工重点检查。

只有这样，AI 才真正进入日常工作。

第六步：上线后继续观察

上线不是结束。

还需要继续查看：

• 员工是否真的使用？
• 哪些结果经常被修改？
• 哪些功能没人点？
• 哪类案件仍然处理缓慢？
• 系统是否出现新的风险？
• 模型升级后，结果有没有变化？
• 哪些方法可以复制到其他业务线？

这才是一项AI 项目的完整过程。

FDE 的工作，就是推动这些事情真正发生。

六、FDE 与其他岗位到底有什么区别？

FDE 容易引起讨论，是因为它看起来像多个岗位的组合。

它像工程师，也像产品经理；像解决方案架构师，也像实施顾问；有时还要承担客户成功和项目经理的工作。

但它并不是把所有工作简单堆在一个人身上。

理解差异的关键，是看每个岗位首先对什么负责。

1. FDE 与传统软件工程师

传统软件工程师通常对产品能力负责。

他会考虑：

• 架构是否稳定？
• 代码是否容易维护？
• 功能是否可以支持更多用户？
• 性能能否承受更大流量？
• 能否减少重复开发？

FDE 首先对客户现场的结果负责。

他更关心：

• 哪个问题最值得先解决？
• 哪些现有能力可以直接使用？
• 哪些地方必须临时开发？
• 怎样在较短时间内证明有效？
• 哪些临时方案后续应该整理成通用能力？

传统工程师偏向“把一类能力做好”。

FDE 偏向“把多种能力组合起来，解决一个真实问题”。

2. FDE 与售前工程师

售前工程师通常发生在合作签约之前。

他需要理解客户需求、设计方案、演示产品，并帮助客户判断是否购买。

FDE 的工作往往更深入。

他需要进入客户系统，编写代码，处理数据，建立测试方式，并推动系统上线。

售前可以证明“理论上可行”。

FDE 需要证明“每天真的可以使用”。

3. FDE 与实施顾问

实施顾问通常围绕成熟产品完成配置、培训和交付。

例如，把已有的ERP、CRM 或协同系统按照客户组织结构设置好。

FDE 面对的问题通常更加模糊。

很多时候，没有现成模板。

客户只知道自己希望提高效率，却不知道应该改哪一个流程，也不知道AI 能做到哪一步。

FDE 不只是执行方案，还需要共同定义方案。

4. FDE 与解决方案架构师

解决方案架构师关注技术路线和系统设计。

他需要判断不同技术怎样组合，怎样满足性能、安全和成本要求。

FDE 通常也需要具备这种能力。

区别在于，FDE 往往还要亲自进入开发、测试和上线过程。

方案不是终点。

系统被使用才是终点。

5. FDE 与产品经理

FDE 与产品经理的相似之处很多。

都需要理解用户问题、拆解需求、控制范围、协调资源，并判断优先级。

但两者仍然存在一个明显区别：

产品经理可以主要通过团队推动实现，FDE 通常需要自己进入技术实现。

这不意味着产品经理必须转型成为全栈工程师。

但它提醒产品经理：在AI 时代，只会画原型、排需求和开评审会，价值会越来越有限。

你至少要能判断：

• 模型适合解决什么问题？
• 数据从哪里来？
• 哪些输出可以自动执行？
• 哪些结果必须人工确认？
• 怎样设计测试集？
• 上线后怎样判断系统真的有用？

七、FDE 不是万能答案，也可能变成昂贵外包

任何一个新岗位进入热门讨论时，都容易被包装成“未来最稀缺的职业”。

但冷静来看，FDE 也有明显风险。

1. 客户定制需求可能失控

一个客户需要修改字段。

另一个客户需要增加审批。

第三个客户需要接入十年前开发的内部系统。

如果团队不断围绕单一客户做临时开发，很快就会出现大量难以维护的代码。

短期看，客户满意了。

长期看，每个项目都变成一个孤岛。

2. 工程师可能长期处于救火状态

• 真实客户现场很少完全按照计划推进。
• 接口会临时变化。
• 数据会突然出错。
• 业务人员会提出新的要求。
• 领导会要求提前演示。

如果边界控制不好，FDE 很容易变成一支高成本救火队。

每天很忙，但没有留下多少可以重复使用的成果。

3. 服务收入与产品收入可能互相拉扯

企业服务公司经常面临一个老问题：

是继续满足大客户的特殊需求，还是坚持开发更多客户都能使用的标准产品？

前者可以快速获得收入。

后者更有可能形成规模。

FDE 团队必须不断做判断：

• 哪些需求只为一个客户服务？
• 哪些需求会在多个客户中重复出现？
• 哪些方法值得整理成组件？
• 哪些功能应该进入正式产品？
• 哪些需求应该明确拒绝？

OpenAI 的 FDE Platform 团队专门强调，要把客户现场中出现的问题整理成可以重复使用的平台能力，而不是停留在一次性修补上。[资料 7]

这说明，即使对于模型公司而言，这也是一个必须认真控制的问题。

4. 不是所有公司都需要自建 FDE 团队

一家规模较小、业务流程简单的公司，未必需要成立专门团队。

如果目标只是使用成熟工具完成会议纪要、内容整理或简单客服问答，直接购买现成产品更合适。

只有当问题具备以下特点时，FDE 模式才更有价值：

• 业务价值高；
• 流程复杂；
• 需要接入多个内部系统；
• 对准确率、安全或权限要求高；
• 标准产品无法直接满足；
• 成功后有机会复制到更多场景。

不要因为岗位名称新，就为简单问题增加复杂组织。

八、这件事为什么值得中国移动互联网从业者关注？

很多中国互联网从业者可能会觉得：

FDE 是海外 AI 公司的岗位，与我有什么关系？

实际上，它与国内产品、研发和运营团队接下来的工作方式高度相关。

1. 过去十年的产品经验，不能直接照搬到 AI 项目中

移动互联网时代，产品经理已经习惯了一套相对成熟的方法：

1. 分析用户需求；
2. 设计页面流程；
3. 输出原型；
4. 排定版本；
5. 跟进开发；
6. 查看数据；
7. 持续迭代。

这套方法仍然有用。

但AI 产品增加了新的问题：

• 模型输出不是固定的；
• 错误无法完全消除；
• 评测需要长期维护；
• 数据质量直接影响结果；
• 很多需求需要先通过实验确认；

业务人员的实际使用方式，比页面功能更加重要。

AI 项目不是增加一个“智能按钮”。

它要求团队重新理解工作本身。

2. 中国企业更容易出现复杂的系统拼接问题

国内很多公司已经积累了大量内部系统：

• CRM；
• ERP；
• OA；
• 工单平台；
• 数据看板；
• 企业微信；
• 飞书；
• 钉钉；
• 自研后台；
• 多年前遗留的业务系统。

真正有效的AI 应用，往往要进入这些系统。

这意味着，未来企业需要的不只是会写Prompt 的人。

还需要有人能够理解业务、连接系统、设计审核机制，并推动一线人员改变工作方式。

3. 产品经理的价值会从“写需求”转向“定义可验证的问题”

AI 可以帮助生成原型、整理文档和编写部分代码。

因此，单纯完成这些动作，越来越难成为产品经理的核心竞争力。

更重要的能力是：

• 找到值得解决的问题；
• 判断问题是否适合AI；
• 设计最小测试范围；
• 定义可以观察的结果；
• 控制风险；
• 推动业务真正使用；
• 把现场经验整理成可复制方法。

这其实就是FDE 思维中最值得产品经理借鉴的部分。

九、普通从业者怎样开始？一套可以直接使用的方法

不是每个人都需要成为FDE。

但几乎所有希望参与AI 项目的人，都可以借鉴 FDE 的工作方式。

下面是一套可以直接用于实际项目的方法。

我把它概括为七个步骤：

找现场、挑问题、算价值、做小版、设底线、看使用、再复制。

第一步：找现场——不要从“做什么 AI 功能”开始

错误的提问方式是：

• 我们能不能做一个AI 助手？
• 我们能不能增加一个智能搜索？
• 我们能不能做一个Agent？

正确的提问方式是：

• 哪一群人每天在重复处理大量信息？
• 哪一步最耗时间？
• 哪一步最容易出错？
• 哪一步完成后还需要反复返工？

先观察工作，再决定是否使用AI。

例如：

• 客服每天花大量时间检索规则；
• 销售每天手工整理客户沟通记录；
• 运营每周重复汇总数据；
• 法务需要从长合同中寻找高风险条款；
• 研发需要理解历史代码和文档；
• 招聘团队需要阅读大量简历。

这些才是可以继续分析的问题。

第二步：挑问题——第一期只解决一件事

不要一开始就做万能助手。

选择一个具备以下特点的问题：

• 高频发生；
• 输入相对明确；
• 输出可以人工检查；
• 出错后不会立即造成重大损失；
• 节省时间的效果容易观察。

例如，与其做“自动处理全部客服问题”，不如先做：

自动识别用户问题类型，推荐对应规则和回复草稿，由客服确认后发送。

与其做“自动完成合同审核”，不如先做：

提取付款、违约和续约条款，并标注原文位置。

第三步：算价值——先确定怎样判断有没有用

项目开始前，写下三个数字：

1. 当前每次处理需要多少时间？
2. 每周发生多少次？
3. 系统上线后，希望减少多少时间或错误？

例如：

• 当前客服检索规则平均需要4 分钟；
• 每天发生3000 次；
• 目标是把平均检索时间降低到1 分钟以内。

这比“提升客服效率”有用得多。

因为团队终于知道什么叫成功。

第四步：做小版——只跑通最关键的一段流程

第一期不要追求功能完整。

只需要回答：

AI 是否真的能够在这个环节提供稳定帮助？

例如，一个销售跟进助手的第一期可以只做：

• 读取最近沟通记录；
• 生成简短摘要；
• 提醒尚未回复的问题；
• 列出下一步建议；
• 允许销售人员修改。
• 先验证销售是否愿意使用。

不要急着开发复杂报表、自动触达和多系统联动。

第五步：设底线——明确 AI 不能做什么

每一个AI 项目都应该写一张“禁止自动处理清单”。

例如：

• 不能自动对外发送高风险内容；
• 不能在没有人工确认时修改客户信息；
• 不能读取超出用户权限的数据；
• 不能在缺少原文依据时给出确定结论；
• 不能把模型生成内容当成最终法律、医疗或财务建议；

低置信度结果必须转人工。

不要只讨论AI 可以做什么，先确定它绝对不能做什么。

第六步：看使用——上线后观察真实行为

不要只看模型准确率。

还要看：

• 有多少人每天使用？
• 哪个页面停留时间最长？
• 哪些结果经常被修改？
• 哪些建议从来没人采用？
• 员工在哪一步放弃使用？
• 系统是否真的节约时间？
• 新流程是否增加了额外操作？

员工不用，说明产品没有进入工作。

结果经常被修改，说明模型或规则仍然有问题。

建议没人采用，说明功能可能只是团队自我感动。

第七步：再复制——从一个场景中找出可以复用的部分

第一个场景稳定后，再判断：

• 哪些组件可以复用？
• 哪些数据处理方式可以复用？
• 哪些测试样本可以扩展？
• 哪些审核规则适用于其他业务？
• 哪些功能值得做成平台能力？

不要一开始就追求“大而全”。

先做好一个真实场景，再从中提炼方法。

十、个人怎样判断自己是否适合FDE 方向？

如果你正在考虑职业发展，可以用下面几个问题做一次自测。

你是否愿意同时面对人和系统？

FDE 不是关起门来写代码。

你需要跟业务人员沟通，理解他们说不清楚的需求，也需要进入系统处理具体问题。

你是否能够接受需求经常变化？

现场问题很少完全按照需求文档推进。

有时，真正的问题要到系统开始使用后才会暴露出来。

你是否愿意对结果负责，而不是只对交付物负责？

写完文档、上线功能、完成汇报，都不代表项目成功。

还要看用户是否使用，时间是否真的节省，错误是否减少。

你是否具备足够的技术理解力？

不一定要求你精通所有技术。

但你至少需要能够理解：

• API；
• 数据库；
• 权限；
• 日志；
• 模型调用；
• Prompt；
• RAG；
• Agent；
• 评测；
• 人工审核；
• 成本和延迟。

你是否擅长在混乱中抓住重点？

FDE 最重要的能力，不是掌握多少工具。

而是在大量需求、限制和意见中，判断：

现在最应该先解决哪一件事？

如果这些问题让你感到兴奋，而不是疲惫，FDE 可能是一个值得关注的方向。

结语：AI 时代真正稀缺的，是把技术变成结果的人

图4 AI 时代稀缺的是把技术能力转化为业务结果的人。

过去几年，行业讨论AI 时，经常围绕模型展开：

• 谁的参数更多？
• 谁的推理能力更强？
• 谁的上下文更长？
• 谁的代码能力更好？
• 谁的Agent 更复杂？

这些问题重要。

但对于绝大多数企业而言，模型不是终点。

真正困难的是：

• 怎样找到值得解决的问题；
• 怎样把数据接入系统；
• 怎样重新安排工作流程；
• 怎样控制错误；
• 怎样让员工愿意使用；
• 怎样证明结果有效；
• 怎样把一次成功变成可以重复使用的方法。

FDE 的出现，提醒我们一件很朴素的事：

技术能力不会自动变成业务结果。

模型再强，也需要有人进入现场。

• 有人去看真实流程。
• 有人判断先做什么、暂时不做什么。
• 有人处理那些无法写进演示文稿里的脏数据、旧系统和权限问题。
• 有人在系统出错时承担责任。

也有人把一次次现场经验整理出来，变成下一代产品的一部分。

这就是FDE 最值得关注的地方。

它不是一个神秘的新名词，也不只是AI 公司包装出来的热门岗位。

它代表的是一种越来越重要的工作方式：

离真实问题更近，离一线员工更近，也离最终结果更近。