最近，FDE 这个词突然在 AI 行业里火了起来。
FDE 可以简单理解成：一个深入客户真实业务现场，把 AI 真正部署进去的人。
它不是单纯写代码的软件工程师，也不是只做方案和沟通的咨询顾问。FDE 往往既要和客户聊需求，也要看数据、接系统、调接口、写代码、做部署、现场 Debug，最后还要对系统能不能真正跑起来负责。
FDE 其实不是一个新岗位
FDE 并不是大模型时代才出现的职业。这个角色最典型的早期代表就是 Palantir。它很早就形成了 Forward Deployed 的工作方式：不是把软件开发好之后交给客户自己使用，而是让工程师深入客户环境，和客户一起理解数据、业务流程和真实问题，再基于平台完成具体解决方案。
所以 FDE 的本质其实一直很明确：
技术能力 → 客户业务 → 现场交付
AI 时代只是让这种角色重新被放大了。
为什么 FDE 在 AI 时代突然火了？
因为今天的企业，可能并不缺模型，真正缺的是有人把模型接进工作流。
GPT、Claude、Gemini 等模型已经具备很强的理解、生成和工具调用能力。做一个能回答问题、分析文件、生成内容的 AI Agent，已经比过去容易很多。
但真正进入企业以后，问题马上会变成：客户的数据在哪里？AI 可以访问哪些数据？不同员工拥有什么权限？模型输出下一步进入哪个系统？任务失败怎么办？怎么和 CRM、ERP、知识库连接？
所以 AI 真正进入业务，需要完成这样一条链路：
模型 → 数据 → 系统 → 工作流 → 业务结果
FDE 就站在这条链路中间。它不是负责训练一个更强的基础模型，而是把已经存在的 AI 能力变成客户真正可以使用的生产系统。
FDE 到底每天在做什么？
如果把 FDE 的工作压缩一下，大致就是：
发现问题 → 确定 MVP → 接数据和系统 → 搭建 AI 工作流 → 部署 → 验证效果 → 持续迭代
比如一家企业想做 AI 客服，普通 Demo 可能只是做一个聊天框，接上模型 API。
但 FDE 真正需要处理的是：客服知识从哪里来？历史工单怎么读取？哪些问题可以直接回答，哪些必须转人工？回答后要不要写回工单系统？错误答案怎么追踪？上线以后有没有真正降低客服成本？
真正的 FDE 项目，通常都不是一句 Prompt 可以解决的。
FDE 和传统软件工程师有什么不同？
最大的区别，不是技术水平，而是工作对象。
传统软件工程师通常围绕产品开发，需求相对明确。而 FDE 面对的往往是一个很模糊的问题，例如：
“我们希望 AI 帮我们提升销售效率。”
接下来 FDE 要继续拆：到底是销售资料太分散，还是 CRM 记录质量太差，还是大量时间浪费在会议纪要和客户跟进上？
所以 FDE 很重要的一项能力，不只是“把功能做出来”，而是先判断：
真正的问题是什么。
它更像软件工程师、解决方案架构师、产品经理和咨询顾问的交叉。
想做 FDE，需要哪些能力？
第一是软件工程能力。数据库、API、前后端、云服务、部署、权限和 Debug，至少要能够独立解决实际工程问题。
第二是 AI 应用能力。需要理解 LLM、RAG、Agent、工具调用、结构化输出和模型评测。FDE 通常不需要自己训练基础模型，更重要的是知道什么模型适合什么任务，以及如何把模型可靠地放进系统。
第三是业务理解和沟通能力。客户不会告诉你“请帮我建 5 张表，再做一个异步任务队列”，他只会告诉你：“我们的销售效率太低。”FDE 要从模糊描述里找到真正的问题，再把业务语言转成技术方案。
最后是 Ownership。FDE 更像一个小项目 Owner，需要推动问题一直解决到客户真正能用。
简单总结就是：
懂技术 + 懂业务 + 能沟通 + 能落地。
哪些人适合转 FDE？
全栈、后端、AI 应用工程师天然具备技术基础，只需要补业务理解和客户沟通；解决方案工程师、解决方案架构师如果补足实际开发能力，也很接近 FDE；技术型产品经理、实施工程师、数据工程师、Data Scientist，甚至长期做 To B 项目交付的人，也都有转型基础。
这也是为什么很多人第一次看到 FDE 的 JD，会觉得：
“这不就是我一直在做的事情吗？”
确实如此。FDE 更像是 AI 时代重新获得明确名字的一种工作方式。
FDE 入行，最重要的不是学框架，而是做完整项目
如果想转 FDE，只学习 Prompt Engineering，或者搭几个 Agent Demo，其实远远不够。
更有效的方式，是完整做一次真实项目。
比如做一个企业客户分析 Agent，不要做到“上传文档 → AI 输出结果”就结束，而要继续往下做：
用户登录 → 保存客户资料 → 上传访谈记录 → 创建分析任务 → 校验权限 → 调用 AI → 写入数据库 → 更新任务状态 → 同步 CRM
这样一个项目做下来，才真正覆盖了 FDE 所需要的数据、系统、AI、权限和业务流程能力。
FDE 的目标不是证明“AI 能做”，而是证明：
这套 AI 系统可以被真实用户持续使用。
AI Coding 正在降低 FDE 的入行门槛
和过去相比，现在做 FDE 最大的变化之一，就是开发工具变了。
Cursor、Claude Code、Codex 等 AI Coding 工具已经可以帮助开发者快速生成前端、接口和大量基础代码。这意味着 FDE 可以把更多精力放在需求拆解、业务建模、系统设计和快速验证上。
但 AI Coding 也带来一个新问题：代码生成得越快，系统越容易变成黑盒。
前端生成出来了，后端数据库在哪里？业务流程怎么跑？AI Agent 在什么时候调用？用户权限写在哪里？需求变化以后应该改哪一段代码？
对于需要不断和客户一起修改系统的 FDE 来说，可控性反而越来越重要。
FDE 实战，也可以用 Zion Plugin 快速完成完整系统交付
这也是 Zion Plugin 很适合 FDE 实战训练的地方。
一种典型组合方式是：
Cursor / Codex / Claude Code 负责 AI Coding → Zion Plugin 负责可视化后端
开发者可以直接用自然语言，让 Coding Agent 调用 Zion Plugin，创建数据库、建立数据关系、搭建 AI Agent、配置 ActionFlow 业务流程、设置 RLS 权限，并完成后端部署。
关键不只是快，而是最终得到的系统依然是可视化、可理解、可修改的。
以前面的企业客户分析 Agent 为例，可以通过 AI Coding 快速生成前端，再用 Zion Plugin 建立用户、客户、访谈记录、分析任务和分析报告等数据模型，然后搭建：
上传访谈 → 创建任务 → 校验权限 → 调用 AI Agent → 结构化分析 → 写入数据库 → 更新任务状态
AI 帮你搭，但最终系统不是一堆黑盒代码，而是看得懂、改得动、可以继续维护的系统。
这也是 Zion 所强调的 Vibe No Coding：
AI 做得了 × 你看得懂 × 你改得动。
一个合格的 FDE，需要交付的不只是 AI Agent
FDE 这波重新受到关注，本质上说明了一件事：AI 越来越强以后，人的价值并没有消失，而是开始从“生产代码”向“理解问题和交付结果”迁移。
模型可以写代码、调用 Tool，也可以做复杂推理，但它不会自动理解一家公司的业务为什么这样运转，也不会天然知道哪些数据不能互相访问，更不会自己进入客户环境，把所有系统协调起来。
所以 AI 越强，真正能够连接：
模型 → 数据 → 系统 → 业务结果
的人反而越重要。
一个合格的 FDE，需要交付的不只是一个 AI Agent，而是一套真正进入业务、能够运行、能够修改、能够持续创造价值的完整系统。
