夜雨聆风最近我发现 FDE 这个岗位很火，我们都知道，Anthropic 和 OpenAI 这类大模型公司都在收购相关企业和吸收人才要下场做企业部署了。说到底，现在 AI 的能力其实已经不错了，大模型公司要想赚钱，还是得让用户用起来，赚 to C 用户的钱利润太少了，其实企业才是 Token 的消耗大户，所以，这些大模型公司要建立类似的人才下场帮企业部署 AI，打通 AI 落地难的问题。
那什么是 FDE 呢？最近读到一篇关于 Forward Deployed Engineering（前沿部署工程师，简称 FDE）的文章，作者本身就是这个领域的从业者，还在旧金山创办了一家 Applied AI 公司，专门做 FDE 团队的搭建。他说这是当下科技圈最火的岗位，Anthropic、OpenAI、Google 这些头部 AI 公司都在疯抢这类人才。读完之后觉得挺有意思，里面的一些思路对我们理解 AI 落地、甚至规划自己的职业方向都很有参考价值。
为什么 AI 公司急需 FDE
文章开头抛出了一个很犀利的判断：如果智能正在被商品化，那唯一的竞争优势就在于你怎么用它、在哪里用它。换句话说，光有一个聪明的模型没用，关键是能把它嵌入到具体的业务场景里，真正跑起来产生价值。
这个观点其实值得我们好好想想。很多人觉得 AI 厉害就厉害在模型本身，但现实是，模型谁都能调用，API 谁都能接。真正拉开差距的，是谁能把这个技术和具体业务深度结合。这就像厨师和食材的关系，食材再好，不会做也白搭。
FDE 的定位就是那个会做菜的人。他们是高技能工程师，能深入理解客户的问题，在一个从没见过的代码库里写代码，还能把技术成果翻译成非技术人员能听懂的商业语言。文章说这是一个“百万美元级别的雇员”，一点不夸张。
必须到现场去
文章引用了 Palantir 前 CTO 的话：你不可能为一个你从未身处其中的环境构建产品。FDE 这个词最早就是 Palantir 发明的，他们对“到现场”这件事非常较真。2010年，他们的工程师直接跟着美军特种部队去了阿富汗，白天部队执行任务收集反馈，晚上工程师根据反馈连夜写代码。
这个例子虽然极端，但道理是通的。要让 AI 真正在一家公司里发挥作用，你必须坐在客户身边，理解他们的数据、流程、上下文。远程做个通用方案然后扔过去，效果一定大打折扣。
这一点对我们做任何需要落地的工作都适用。很多时候我们觉得自己懂了，其实只是懂了表面。真正的理解来自于沉浸在那个环境里，看到那些文档里写不出来的细节。
FDE 工作的三个阶段
文章把 FDE 的工作拆成了三个核心阶段：审计（Audit）、评估（Evals）、部署（Deployment）。
审计阶段，就是到客户公司里，跟不同团队坐在一起，搞清楚他们的工作流程、瓶颈在哪、哪些环节适合用 AI 来做。比如跟运营团队待两周，跟采购团队待一周，跟财务团队待一个月。
这里面有个很实用的判断框架：什么该自动化，什么不该。文章给了三条原则。第一，如果一个流程的规则是固定的但输入形式多样（邮件、PDF、扫描件都有），而且需要调用工具，那就适合放一个 AI Agent 进去。第二，如果规则和输入都是可预测的，直接写代码比用 AI 更快更便宜。第三，如果决策需要模式识别和领域专业知识，那就留给人来做。
还有一条很实在的提醒：如果一个 Agent 一个月只跑五次，客户拿不到好的投资回报。要找那些高频、耗时长的流程来自动化，量要够大才有意义。
另外，文章特别强调不要过度使用 AI。大多数自动化任务用一系列工具调用加上一次 LLM 调用作为编排层就够了。AI 用太多，token 成本会在规模化之后急剧膨胀，而且输出质量反而可能下降。
这些判断原则其实可以迁移到我们日常工作中。比如你想用 AI 提效，先问自己：这个任务频率高不高？规则清不清楚？输入变化大不大？想清楚这几个问题，就不会盲目上 AI，也不会错过真正该用 AI 的地方。
评估阶段，客户花了大价钱做 AI 部署，当然要看到效果。FDE 需要建立详细的评估体系来证明 Agent 确实在起作用。
文章提到一个好的评估方法：不只是看最终答案对不对，还要追踪 AI 的思考路径是否和人类一致。具体做法是，先把人类解决问题的步骤拆解出来，然后看 AI 在每一步是不是也命中了同样的关键节点。另外，先找几个标杆案例，搞清楚“最好的结果长什么样”，再拿这个标准去衡量 Agent 的表现。
这个思路很有启发性。我们评价任何工具或方法的效果，都不能只看最终结果。过程对了，结果才可复制；过程不对，即使偶尔蒙对了，也迟早会出问题。
部署阶段，文章给了一个很务实的建议：不要做大规模数据迁移。在现有的数据层（比如 SharePoint 或数据库）上面建 API，然后放一个模型作为编排器去查询。这样省时省钱，更重要的是不用把现有系统推倒重来。很多客户花了几百万美元、好几年时间才迁移到现在的 ERP 系统，他们最不想做的事就是再换一次。
部署的时候要从小处开始。先拿一个小流程跑通，再逐步叠加能力。比如先让 Agent 做到能发现 bug、调查原因、写一张工单总结问题。如果这一步稳定了，再给它写代码和提交 PR 的权限。
从最小的自主单元开始，验证了再给更多权限。这个渐进式的思路，做任何有风险的事情都适用。
30天成为 FDE 的路径
文章最后给了一个30天的学习计划，面向三类人：咨询顾问、产品经理和软件工程师。
对于咨询顾问和产品经理来说，他们天然擅长把数据翻译成 ROI，这是 FDE 工作的一半。但他们最大的短板是缺乏工程经验。文章建议通过做项目来弥补：比如做一个能完整执行某个流程的生产级 AI Agent，或者在特定行业数据集上搭建一个 RAG 管道，或者自己写一个评估框架来给 Agent 打分。
对于软件工程师来说，技术能力不是问题，最关键的是沟通。你需要能把 AI 能做什么、不能做什么，翻译成非技术 VP 能听懂的话。如果做不到这一点，就做不了 FDE。
这里面有一句话说得特别好：不要把你的理解力外包给 AI。一步一步来，这些概念都是可以搞懂的。所以这个计划叫30天，不是30分钟。
30天的具体安排是这样的：第一周搞懂 Agent 的基本原理和循环机制，学会让 Agent 调用工具，建立基本的安全护栏；第二周学习结构化输出、从 demo 到生产的过渡、以及断点续跑的机制；第三周学重试逻辑、成本优化、构建评估数据集、多 Agent 协作架构；最后一周做总复习，把所有学到的东西大声讲出来，并且尽可能和业务指标挂钩。
沟通能力是硬门槛
通篇读下来，文章反复强调的一个点是：沟通能力。如果你不能向一个非技术决策者解释清楚 AI 能做什么、不能做什么，那就不会有部署发生。知道什么时候 AI 不是答案，这件事本身就能建立客户信任，也能让真正上线的 Agent 获得更好的 ROI。
这一点放到更广的视角来看，技术能力越来越容易获取，但能把技术价值讲清楚、能在复杂环境中做出正确判断的人，永远稀缺。不管你是不是要做 FDE，这种“翻译”能力都值得刻意练习。
说到底，AI 时代最值钱的人，可能不是最会写代码的，也不是最懂模型的，而是那些能站在技术和业务的交叉点上，把两边连起来的人。
原文：x.com/vasuman/status/2057177266984226892
最后，告诉大家一个好消息：我的星球社群已经运营了 827 天，累计主题 2000 个，星球加入人数 1650 人，精华主题 282 篇，各种专栏课程累计上百篇，今年更新的视频教程也有 30+ 了。
在这里感谢大家的信任与支持。感兴趣的可以加入一下。下面有优惠券，领券再加入哈。
具体介绍一下，我的星球：「AIGC·掘金成长研习社」（可点击查看星球全面介绍），主要分享三个板块的内容：
