Forward Deployed Engineering (FDE) 是什么?为什么 OpenAI、Anthropic 等 AI 顶流都在力推 FDE,它会是下一个值得转型的职业吗?

TL;DR · AI 摘要
FDE(Forward Deployed Engineering)是AI公司通过派驻工程师深入客户现场解决业务问题的核心职业,其竞争优势源于将AI嵌入具体业务流程的能力,OpenAI等公司正通过FDE实现差异化竞争。
核心要点
- FDE核心要求:必须On-site驻场,通过审计、评估、部署三阶段将AI融入客户业务流程
- 三条Agent应用原则:输入形态复杂需Agent,可预测任务用代码,模式识别保留人工
- 转型FDE需掌握Agent loop、结构化输出、成本优化等技能,并通过4类项目验证工程与商业能力
结构提纲
按章节快速跳转。
解释FDE作为AI公司竞争优势的核心机制,对比传统产品模式的局限性
详细拆解审计、评估、部署三个核心阶段的具体方法论与执行原则
提出30天转型路线图及4类关键项目实践要求
分析FDE概念来源及其在AI场景的适应性改造
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- FDE职业体系
- 核心机制
- On-site驻场
- 业务流程嵌入
- 工作阶段
- 审计
- 评估
- 部署
- 能力要求
- 工程能力
- 商业沟通
金句 / Highlights
值得收藏与分享的关键句。
如果智能本身正在被商品化,那么唯一的竞争优势就是'如何用、用在哪'
三条Agent判断原则:输入形态多样需Agent,可预测任务用代码,模式识别保留人工
Evals的真正用途是让怀疑AI的高管敢签字——它是商业信任工具,不只是工程工具
为什么 AI 公司疯抢 FDE? @vasuman 这个判断很直接:如果智能本身正在被商品化,那么唯一的竞争优势就是"如何用、用在哪"。
模型能力会被 Anthropic、OpenAI https://t.co/LGL5JOUMli" / X
Forward Deployed Engineering (FDE) 是什么?为什么 OpenAI、Anthropic 等 AI 顶流都在力推 FDE,它会是下一个值得转型的职业吗? 为什么 AI 公司疯抢 FDE?
这个判断很直接:如果智能本身正在被商品化,那么唯一的竞争优势就是"如何用、用在哪"。 模型能力会被 Anthropic、OpenAI 等拉平,套壳产品也会被复制。真正难复制的是——把 AI 嵌入到某家具体公司的具体业务流里。这件事没法用通用产品解决,只能派人去干。 所以 Applied AI 公司的商业模式是:把 FDE 派驻到客户现场,做"AI 转型外包",客户为效率提升付费。一个能独立完成"理解客户问题 → 写进陌生代码库 → 向非技术高管讲清商业价值"的人,vas 称之为 "million-dollar hire"。 角色的核心要求:必须 On-site! 这一点借用了 Palantir 的传统(FDE 的定义来源): · 2010 年 Palantir 的 FDE 跟着美军特种部队驻阿富汗,白天部队执行任务、晚上 FDE 改代码。 · Palantir CTO 的原话:"你无法为一个你不在其中的环境构建产品。" 迁移到 AI 场景的含义是:真正的效率提升需要"围绕 AI 重建公司",这不可能远程完成,必须坐在客户身边,基于公司专有数据和上下文构建定制 Agent。 FDE 的工作三阶段 1. Audit(审计 / 诊断):以原型 Demo 收尾 驻场轮岗各部门(例如 RevOps 两周、采购一周、财务一个月),目标是: · 摸清每个团队的工作流 · 找到瓶颈 · 判断哪些该自动化、哪些不该 三条"是否上 Agent"的判断原则,非常实用: · 规则可抽象,但输入形态多样(邮件 / PDF / 扫描件),且需要调工具?上 Agent! · 规则和输入都可预测?写普通代码,更快更便宜! · 需要模式识别 + 领域专家判断?保留人工! 另外两条经验法则: · 量要够大:一个月跑 5 次的流程,ROI 撑不起来。 · 别滥用 AI:大多数任务用"一串工具调用 + 一次 LLM 编排"就够了,过度用 AI 会带来 token 成本和质量下降。 2. Evals(评估) 客户砸百万美金做 AI 部署,必须有办法证明"它真的在工作"。好的 eval 不是只看最终答案对不对,而是验证 AI 是否像人一样思考。两个方法: · 拆解人的步骤逐步打分:人解决问题是多步的,把 checkpoint 列出来,看 AI 是否每一步都过关。 · 从黄金样本反向锚定:和资深员工一起把"完美答案"写出来 20 个,作为标尺度量所有产出。 Evals 的真正用途是让怀疑 AI 的高管敢签字——它是商业信任工具,不只是工程工具。 3. Deployment(部署) 几条非常反直觉但很务实的原则: · 不要做大规模数据迁移。在现有数据层(SharePoint、数据库)之上建 API,让模型作为 orchestrator 去查询。客户花了几年几百万上 ERP,不会让你再拆一次。 · 先搭沙箱执行环境,在客户基础设施里安全测试。 · 从最小自治单元起步,再逐步给权限。例:先让 Agent 只做"发现 bug → 调查 → 写工单",跑稳了再允许它"写代码 + 提 PR"。 如何在 30 天内成为 FDE?! vas 认为三类背景最容易切入:咨询顾问、PM、软件工程师。 咨询/PM 的短板:工程能力 解法是用作品集补齐。从下面四个项目里挑两个深做: · 一个能跑通你前公司某个完整流程的生产级 Agent(调 API、记录思考、有失败兜底)。 · 一个面向特定行业数据集(法律 / 医疗 / 财报)的 RAG pipeline。 · 一个自己写的 eval 框架,多维打分(正确性、格式、成本、延迟)。 · 一个把 LLM 接入到不支持 AI 的遗留系统的 MCP。 vas 强调:"Do not outsource your understanding to AI"——别让 AI 替你理解,否则面试一聊就穿。 SWE 的短板:沟通 工程师做同样的项目,但必须能把每个组件、技术选型、迭代过程、商业结果讲清楚,并能回答"你为什么解这个痛点、真实客户场景里会怎么走"。 30 天路线图(角色无关) Week 1:Agent loop 基础(读 Anthropic Building Effective Agents)、tool use、guardrails、context vs 外部记忆、audit trail Week 2:结构化输出(JSON)、Demo → Prod 常见坑、checkpoint 机制 Week 3:重试与指数退避、成本优化(小模型做小事 / 缓存 / token 上限)、构建 golden dataset、多 Agent 并行架构 Week 4:复盘 + 大声讲出来,把每件事绑到商业指标上
Quote
vas

@vasuman
13h
Forward Deployed Engineering 101
By the end of this article, you should understand why Anthropic, OpenAI, Google, and other AI companies are looking for FDEs, and how you can capitalize on this demand. I've done the job myself, hired...