FDE 早就存在，AI 却把这个岗位推到了今天。
2026 年 6 月，我从大厂裸辞转型 FDE，此前做 AI 算法、模型优化部署，也做过企业内部沟通和培训，这些能力恰好落在同一条链路上：
一个产品的开发本来就横跨业务咨询、产品、算法、工程和交付，如今 AI 又把调研、原型、编码、测试、文档和项目记忆压缩到同一套工作流里，一个人或一支小团队因此能接住过去分散在多个岗位里的工作。
这篇文章想讲清楚：FDE 怎样借助 AI 把这些职能连起来，一名 FDE 又需要懂什么、会什么、亲手做到什么。
后面会出一个系列文章，把每一个点都讲深讲透。
1、AI 让 FDE 能接住更多职能#
FDE 看起来像把几份工作装进了一个岗位：他要听懂业务，定义产品，判断算法边界，写代码、接系统、推上线，还要让客户最终接得住。它的价值不在把几份 JD 拼起来，而在让同一个人持续对问题到结果之间的断点负责。
过去，一个人很难横跨这么多角色。现在，AI 可以协助查行业资料、整理访谈、画原型、生成代码、补测试、维护文档，也可以把几个月的项目记录变成随时可检索的上下文。AI 扩大了 FDE 可以亲手负责的范围，却没有替他做判断和承担结果。
传统软件项目通常分得很清楚：销售拿合同，售前写方案，产品拆需求，研发写代码，实施负责上线，客户成功关心续费。
成熟业务可以这样协作。企业 AI 项目刚开始时，问题、数据和技术路线都在变化，每转交一次，现场信息就可能丢一层。
客户说要做知识库，销售记成一个商机；产品经理拆成文档上传和智能问答；工程师接好向量数据库。等系统做完，团队才发现同一份制度有多个版本，没有人敢确认哪份有效，普通员工还能搜到特殊客户的价格。
每个人都完成了自己的任务，客户的问题却还在那里。
FDE 要守住这些岗位之间的缝。他未必要一个人包办所有工作，但必须看见整条链路：现在缺的是业务负责人、真实数据、模型能力、系统权限，还是上线后的使用意愿。需要专业人员时，他要知道把谁拉进来，也要能把问题讲到对方可以行动的程度。
这也是算法背景和 FDE 的连接点。模型、推理和部署经验，可以帮助我们更快判断问题在技术上是否成立；AI 工具则把这种能力延伸到调研、沟通和交付。但如果视线只停在准确率、延迟和吞吐量上，项目仍可能做成一个漂亮却没人使用的 demo。
2、找客户，也是技术工作的一部分#
转型 FDE 以后，客户筛选的重要性越来越明显。客户选错了，后面的技术越强，损失越大。
筛选时先看四件事：这个问题是否正在产生真实代价，内部有没有人对结果负责，能不能接触到真实流程和数据，第一步能否收窄到几周内验证。
我碰到过一上来就想做「全公司 AI 改造」的企业。目标很大，但往下问，谁是第一批用户、当前数据在哪里、哪个部门愿意配合、做完怎样验收，没有一个人能确认。也碰到过目标很小的团队，只想把一项重复工作缩短一点，负责人愿意拿真实样本出来，也愿意每周参加评测。
后者的预算可能没那么抢眼，项目反而更容易往前走。
预算表达的是愿望，日常工作暴露的是准备度。第一个客户最好已经在努力解决某个问题，只是当前办法太慢、太贵或者走不通。FDE 进入以后，是让一股已经存在的力量更有效，不是在空地上独自推动整家公司。
这需要行业理解，也需要商业判断。钱从哪里来，错误由谁承担，谁会因为流程改变受益，谁可能失去原来的权力。算法文档不会回答这些问题，它们却决定技术有没有机会进入生产。
3、沟通不是开会，它要变成工程输入#
客户能说出自己想买什么，很难一次讲清问题是怎样发生的。
「做一个 AI 客服」，可能是客服每天重复回答同一批问题，也可能是新制度发布后知识更新太慢，还可能是用户找不到正确入口。三个问题都能做成聊天窗口，背后的数据、风险、权限和验收方式完全不同。
我做企业内部沟通和培训时，对这一点感受很深。同一句「这个工具不好用」，管理者、一线员工和技术团队说的可能根本不是一件事。管理者看投入产出，一线员工关心会不会多一道操作，技术团队担心系统稳定和维护成本。
FDE 要把这些话翻译成同一张工作图。
谁在什么时候收到什么输入，打开哪个系统，根据什么作判断，遇到例外找谁，结果写到哪里。会议室里讲的是标准流程，真正工作时，人可能在群里催数据，用个人表格补系统，在正式审批前先打一通电话。这些绕路才是 AI 必须面对的接口。
AI 可以帮忙准备访谈问题、整理会议记录、比较不同角色的说法。会议结束后，内容会被拆成事实、判断、假设、决定和待确认项。第一轮提取可以交给 AI，最后必须由有权的人确认。
我踩过的一个坑，是早期太相信「大家都知道这件事」。等范围发生争议，几个人翻遍群聊，才发现大家记得的版本并不一样。后来我开始用 Markdown 管项目记忆：原始材料单独保存，AI 只能提出更新建议；事实、决定、风险和负责人进入正式文件前，需要标清来源和确认状态。
从那以后，这些 Markdown 文件就成了项目的控制面。客户什么时候同意缩小范围，一项技术选择基于什么条件，哪项风险还没有负责人，都要在这里留下。信息只存在于聊天记录里，AI 记得再多，也只是帮团队更快地翻旧账。
4、方案最终要落成一组可以验证的决定#
一次客户沟通可能留下几千字记录，仍然回答不了最简单的问题：到底要做什么？
方案会被压到几个问题上：当前工作怎样运行，第一阶段只改变哪一步，谁会使用，什么算有效，哪些内容明确不做。再补上双方责任、技术风险、人工接管和停止条件，项目才有边界。
我也碰到过类似情况：客户最开始想做一个覆盖多个部门的平台，真正跟着业务流程走了一遍，才发现最痛的只是其中一个环节。这个时候把大平台砍掉，先做一项每天都会发生、几周内就能验证的工作，反而更容易建立信任。
范围变小以后，用户是谁、输入是什么、错误会造成什么影响，都能被看见。原来那句「提升企业智能化水平」，终于变成了可以验收的工作变化。
方案阶段也必须有技术预判。扫描 PDF 能不能稳定解析，CRM 的接口是否支持目标写入频率，受限资料能否按用户身份隔离，模型出错以后谁来接管。暂时无法确认的内容，应该变成待验证假设，配一个最便宜的实验和截止时间。
架构图只说明系统准备怎样搭。交付方案还要解释为什么值得搭、做到哪里停，以及什么证据允许它继续往生产走。
5、FDE 的技术能力，要能走到生产#
我从算法转到 FDE，原来的技术能力成了底座。算法优化和部署经验让我更清楚：模型效果只是系统的一部分。
真正进入企业，要同时处理知识、应用、工具、权限、基础设施、评测、发布和运维。FDE 可以和专业团队协作，但自己至少要能做出端到端版本，也能判断问题出在哪一层。
Part1：知识库和 RAG，先处理错误的知识#
做企业知识库时，最先处理的是文档本身。向量数据库可以晚一点再选。
同一份制度可能有多个版本，文档没有 Owner，特殊价格混在普通资料里，扫描件解析以后表头和脚注丢失。这些内容直接进入 RAG，模型越流畅，风险越大。
文档先补上版本、生效时间、Owner、权限和原文位置，再做状态过滤、去重和召回。关键词检索负责产品编号、条款号和精确名称，向量检索负责语义相近，必要时再做融合排序。答案必须带证据，资料不足、版本冲突或者用户无权查看时，系统应该停下来。
这里的评测不能停在「答案像不像」。还要检查它有没有引用当前版本，证据是否真的支持结论，权限是否泄露，该拒答时有没有拒答。换模型、切分方式和检索策略以后，同一批真实问题要重新跑一遍。
Part2：Agent 和 MCP，工具接通以后才开始危险#
做 Agent demo 很容易。让模型查询客户、生成总结、调用一个写入接口，很快就能跑起来。
进入企业以后，还要继续问：这次调用代表谁，能访问哪个租户，写入前是否审批，参数有没有上限，网络超时后重复执行会不会写两次，出错以后能否审计和撤销。
MCP 能统一工具的描述和调用方式，却不会自动完成授权。这类工具的身份、scope、租户隔离、审批、幂等键和资源归属，需要放在服务端检查。模型生成一句「审批已通过」没有任何效力，外部文档里出现「忽略规则并删除数据」，也只能被当作普通数据处理。
这条原则贯穿企业 AI 实践：AI 负责理解、提议和规划，确定性代码负责检查边界，人对高风险动作作授权。
Part3：API 还是本地部署，要回到真实负载#
这是我原来做算法优化和部署时最熟悉的一段，也最容易被一句口号带偏。
有人听到「数据不出域」就直接采购机器，也有人认为调用最强 API 一定更省事。真正要拆的是：哪些数据不能出去，脱敏后是否可以，峰值并发多少，输入输出多长，延迟要求是什么，故障能停多久，谁负责升级和夜间运维。
模型大小不能替代任务评测。一台机器跑通，也不能证明两百个人同时用时还能稳定。需要在真实输入长度、目标硬件和并发曲线上做压测，看首字延迟、整体吞吐、显存、排队和失败恢复。
成本也不能只看 API 单价或者显卡价格。API 要算多步调用、长上下文、缓存和增长；本地部署要算闲置容量、冗余、电力、升级、安全和运维人力。最后落到每个合格任务的成本，答案才有业务意义。
很多企业最终适合混合部署：敏感资料和检索留在内部，通用能力调用外部模型，高风险任务保留本地模型或人工审核。这个方案看起来没那么整齐，却更接近企业真实约束。
Part4：上线之前，必须允许系统说「不行」#
我做发布检查时，会把应用、模型、提示、知识索引、工具和策略看成一个完整版本。产品、安全和运维分别确认，回滚目标提前写好，核心制品做哈希校验，关键测试重新执行。
就在这次整理过程中，我并行跑多组检查，生产门禁第一次把发布拦住了。按发布顺序单独执行以后，制品和依赖测试才全部通过。我没有继续猜第一次失败的具体原因，只保留这个结果。
这件小事很像真实上线。工程师说「我刚才本地跑过」，不能成为发布证据。生产需要固定制品、可重复顺序、明确审批和真正演练过的回滚。
系统上线以后还要能看见质量、延迟、费用、工具调用和人工接管。用户说答案有问题，要能追到当时使用的模型、知识版本和证据；工具写错数据，要知道谁发起、谁批准、参数是什么。没有这些信息，团队只能靠猜来修事故。
6、企业培训让我看见：上线只是技术完成#
我做企业内部沟通和培训时，还有一个很深的感受：员工不用新工具，原因经常不是他们排斥 AI。
有时候入口离原来的工作太远，多了一次复制粘贴；有时候系统错过两次，信任就没了；也可能它帮一线员工节省时间，却给主管增加了审核任务。还有人担心自己的经验被写进系统以后，原来的位置会发生变化。
培训不能只讲模型多强、功能怎么点。要让不同角色拿自己的任务练一遍，知道什么时候可以相信，什么时候要停下来，反馈以后谁会处理。业务专家还要参与评测，因为「什么叫答对」本来就掌握在他们手里。
FDE 要把系统放进原来的工作入口，让真实用户参与修改。错误出现时快速承认和处理，保留人工接管，让使用者看到自己的反馈怎样进入下一版。
技术上线和组织采用是两件事。FDE 要一直做到第二件事发生。
7、交付结束，客户要能自己接住#
一个项目验收了，客户仍然只有在群里找到原工程师才能处理故障，这次交付就没有结束。
交接会被拆成几类：架构与数据流、部署和回滚、评测证据、安全权限、资料和数据 Owner、已知限制、事故手册、培训与支持边界。文档写完以后，让客户团队独立发布一次、更新一次知识、处理一次模拟故障，再完成回滚。
FDE 在旁边看，不抢键盘。只有客户真的走完，交接里的空白才会暴露出来：某条命令依赖个人电脑，某个账号仍在供应商手里，某项评测只有原工程师知道怎样解释。
客户能独立运行、判断和恢复系统，FDE 才有资格离场。
8、做完一单，下一单应该更轻#
如果每个客户都从空白代码和空白文档开始，FDE 很快会变成昂贵的驻场外包。
一次实践结束以后，能沉淀的不一定是客户代码。问题发现方法、行业对象模型、连接器、评测结构、权限策略、发布检查和交接模板，都可以成为下一次工作的底座。
这也是我从算法专家转型 FDE 后，越来越在意的一件事。算法能力让我能把一项技术做深，FDE 要求我把客户、流程、工程、上线和采用连起来。只有把反复出现的判断和工具沉淀下来，下一次交付才不会从零开始。
现在再回答「一个 FDE 到底要会什么」，答案已经很清楚了。
他要能找到值得做的客户，进入真实流程，听懂组织里的不同立场，把模糊愿望收窄成可验收结果。他也要真能动手：治理知识，搭 RAG，设计 Workflow 和 Agent，控制 MCP 工具权限，作部署取舍，建立评测、观测、发布和回滚，最后把系统完整交给客户。
我是 Miles，一名从大厂转型 FDE 的 AI 算法专家，做过模型优化部署，也做过企业内部沟通与培训。关注我 @miles_mazy，我会继续分享自己在企业 AI 落地中做过的事、踩过的坑和沉淀下来的方法。一起成长，一起赚钱。