FDE火了:企业真正缺的,不是AI工具课,而是一批业务型FDE

ALINA LINZI · FIELD NOTES

最近，FDE 这个词突然火了。

全称叫 Forward Deployed Engineer，前线部署工程师。

我原本以为，这又是技术圈新发明出来的一个职位名。看完一篇关于 FDE 的讨论，我却愣了一下。

这不就是我过去几个月一直在做的事吗？所以浅浅写几篇文章，分享一下我的想法。

我没有技术背景，也不会写代码。但我从用户需求开始，一个人完成了 AI 产品的开发、测试、上架、营销，再到后面的培训和迭代。

当然，我不属于传统岗位意义上的 FDE。传统 FDE 要进入企业客户现场，跟工程团队一起完成系统部署，还要处理数据、安全、权限、组织协同……AI 会写代码了，这些事情依然很重要。

但 FDE 背后的工作方式，我太熟悉了。要主动往前走，站到问题发生的第一线，从一句模糊的“我们也想用 AI”，一路追到真实需求、产品方案、上线使用和最终结果。

企业只请几个厉害的工程师远远不够，还需要一批懂业务、能把 AI 用进真实工作流的人。

这类人叫作“业务型 FDE”。

PART 01

业务没变，培训再热闹也没有用

现在很多企业做 AI，第一反应是培训。

请一个老师来讲 ChatGPT、Claude、DeepSeek，教员工写提示词、做 PPT、总结会议、生成文案。

当天大家觉得很震撼。

AI 好强，原来还能这么用。

然后呢？

培训结束，员工回到岗位。原来的表格照样手工填，客户资料继续散落在不同群里，销售复盘依然没人看，老员工脑子里的经验还是没有变成公司的资产。

最多就是写邮件快了一点，做周报轻松了一点。

这当然也算提效。但说难听点，如果花钱做了一场企业 AI 培训，最后只是让员工更快地写出一封邮件，这个 ROI 真的太低了。

老师讲得没问题，员工也认真学了。目标设错了。

大多数 AI 培训从一开始就问错了问题。

它问的是：这个工具有哪些功能？

企业真正应该问的是：我们哪一段业务流程最贵、最慢、最容易出错？AI 能不能把它重新做一遍？

工具课的终点是“我学会了”。

业务落地的终点是“这件事从今天开始换了一种做法”。

两者差得非常远。

工具课的终点是“我学会了”，业务落地要看真实工作流有没有改变。

PART 02

我不会写代码，但我一直站在产品一线

我做 AI 霖子（chat.alinalinzi.com），起点是商业教练业务里每天重复出现的问题。

学员会反复问：我的定位怎么改？产品怎么设计？这段销售对话哪里出了问题？公众号该写什么？下一步到底先做哪件事？

这些问题我已经回答过很多次，也积累了大量课程、咨询、案例、方法论和判断标准。

我要把已经验证过的业务经验，变成一个可以反复调用、持续迭代的产品，而不是再做一个陪人聊天的机器人。

于是我开始做 AI 霖子。

AI 写代码，我负责做决定。

什么功能值得做，什么需求必须砍掉，什么结果才算合格，用户为什么不愿意继续用……这些问题，AI 不可能替我拍板。

这几天，我正在办一场 Obsidian 知识库和 AI 霖子插件的 7 天打卡营。

课程从搭知识库骨架、做内容获客，一路走到销售、交付，再到让每个人做出自己的 Skill。白天我带大家把 AI 用进真实业务，课后继续改插件。课堂往前走一天，产品也跟着真实使用往前走一轮。

这是 AI 霖子 Obsidian 插件的真实界面。用户可以直接处理当前笔记、在知识库里找资料，或者调用自己的 Skill。

因为学员用的不是我提前布置好的演示环境，而是自己的电脑、知识库、客户资料和工作任务。

一个在我电脑上跑得很顺的功能，换一个系统、一个文件格式、一条真实业务指令，就可能露出问题。

有人上传微信聊天截图做销售诊断，我才发现常见的 PNG 图片会被错误拦截；有人跑一份很长的销售逐字稿，中途遇到网络中断；还有一次，插件提示“已经录入 CRM”，后台却没有真正新增客户。

这些需求直接来自课堂现场。问题就在我面前发生，结果到底有没有跑通，一眼就能看见。

所以我一边上课，一边修复、测试、重新发布。从 8 月 17 日开营到今天，AI 霖子的公开版本号从 0.7.35 一路走到了 0.7.70。

我一直盯着同一件事：“功能能演示”还不算完成，真实用户必须能用自己的任务跑通。

这次打卡营让我特别强烈地意识到：课堂从第一天起就是需求现场、测试现场和交付现场，培训也自然进入了产品开发的全过程。

我一边教用户，一边观察他们在哪里卡住；一边听反馈，一边判断这是个别问题，还是值得进入产品的共性需求；改完以后，再放回第二天的真实任务里验收。

需求、开发、测试、培训、反馈和迭代，就这样连成了一条线。

一个很小、很完整的 FDE 现场，就这样出现在我的打卡营里。

课堂往前走一天，真实任务就推动产品往前迭代一轮。

产品上线以后出现了真实付费，也出现了新的问题。

有些功能我以为很重要，用户根本不点。有些问题我原本没当回事，后台却一遍遍有人问。

这才叫站在一线。把东西交到用户手里，看他到底用不用、愿不愿意付钱、能不能拿到结果。

后来我去看 OpenAI 对 FDE 的职责描述：从需求发现、技术范围界定、系统设计、开发，一直负责到生产上线；最后用真实采用和工作流变化衡量成果。

FDE 最值钱的四个字是 Forward Deployed。往前走，走到客户旁边，走到问题现场，走到结果发生的地方。

PART 03

技术型FDE负责做出来，业务型FDE负责别做错

企业当然需要技术型 FDE。

生产系统怎么接，数据怎么处理，安全和权限怎么保障，模型出了错怎么兜底……这些必须由真正懂技术的人负责。

但如果企业把 AI 落地全部丢给技术部门，也很容易做出一堆“技术上没问题，业务上没人用”的东西。

因为最了解问题的人，往往不在技术部门。

销售知道客户在哪一句开始犹豫。

客服知道哪十个问题每天都在重复回答。

运营知道哪张表每周都要从三个系统里复制粘贴。

培训负责人知道新人最容易卡在哪一步。

业务负责人知道，哪一个错误会让公司真正损失钱。

这些人可能不会写代码，但他们知道什么是好结果，知道哪里最痛，也知道一个新流程能不能真的推下去。

他们要学会五件事：把模糊抱怨说成具体问题，把工作过程拆成清晰步骤，定义结果和验收标准，跟 AI 或技术团队快速做出原型，再把有效做法写成 SOP、教给更多人。

这就是我说的业务型 FDE。

技术型 FDE 负责把系统做出来。

业务型 FDE 负责确保大家做出来的，是对的东西。

少了任何一边，企业 AI 都很容易变成一场昂贵的表演。

技术能力和业务验收必须站在一起，系统才能真正进入业务。

PART 04

企业别再养AI气氛组

如果一家公司真的想培养业务型 FDE，培训方式也必须变。

不再是让一百个人坐在会议室里，轮流体验十个最新工具。

先选一个真实业务问题。

比如，销售跟进为什么总断掉？客服每天最重复的工作是什么？新人入职为什么三个月还不能独立？一份报告从收集资料到交付，到底经过多少次复制、等待和返工？

再让一小群真正接触这个问题的人，把当前流程拆出来。

每一步谁在做？花多少时间？哪里最容易错？什么结果算合格？现有数据在哪里？如果 AI 接走其中一部分，最后由谁验收？

然后做出一个最小原型，放回真实场景里测试。

跑不通就改。跑通了就写 SOP、定边界、做培训，再复制到更多人。

这才叫企业 AI 培训。学完要拿一个业务结果回来。

如果未来有企业找我做 AI 培训，我大概不会一上来就讲“今天教大家十个好用的 AI 工具”。

我会先问：你们到底想改变哪一件事？

谁每天在做这件事？现在付出了什么成本？改完以后，什么结果才算真的有效？

如果这些问题都说不清楚，上课只会制造短暂的兴奋。

我宁愿带着团队把一个真实问题跑通，做出一套真的有人用、有人验收、可以重复执行的工作流。

企业不缺会在现场演示 AI 的气氛组。

缺的是下课以后，真的能把业务往前推进的人。

不过，找到一个“真实问题”，往往比想象中难得多。

老板说“我们公司也要 AI 化”，到底是在提出需求，还是在表达焦虑？

下一篇，我接着写。

欢迎大家使用AI霖子（网页版：https://chat.alinalinzi.com）；Obsidian插件可直接在插件市场搜索“AI Linzi”；已经正式上架苹果iOS手机应用商店（非大陆地区）。

打造个人品牌，掌控自由人生

用热爱实现自我，用专业成就他人

点击阅读原文，免费注册AI 霖子。