AI落地的最后一公里，Codex+Claude Code +DeepSeek落地银行、运营商、能源、电力，政务的落地方法和案例实操

过去一年，硅谷开始频繁出现一个新岗位：FDE。

全称是 **Forward Deployed Engineer，通常翻译成“前线部署工程师”。

如果只看名字，它有点像一个被重新包装过的技术岗位：工程师去客户现场，帮客户把系统接起来，把方案跑起来。

但我觉得，这个岗位真正值得关注的地方，已经超出了“工程师要不要出差”，也不只是“它是不是售前工程师的新名字”。

FDE 火起来，背后反映的是一个更大的变化：AI 公司正在发现，模型能力越来越强之后，真正难的事情变成了部署。这里说的部署，不是用 AI 工具写个 demo。它真正要解决的是先在企业真实业务里找到值得做的需求，再把 AI 放进对应流程里，让它接上数据、理解权限、融入系统、跑出结果，并且能被一线团队稳定使用。

这个过程，才是 AI 落地真正困难的地方。

其实，我自己现在也在大厂业务一线做类似 FDE 的事情：用 AI 技术打通平台、上下文和研发流程，通过 Harness 工程把 AI 能力嵌入真实交付链路，提升业务交付效率。

一、为什么现在大家突然开始谈 FDE？

FDE 不是一个全新的概念。

它最早被更多人知道，和 Palantir 有很大关系。Palantir 面向政府、金融、工业等复杂客户时，很早就意识到：这类客户不是买一个软件账号就能用起来的。

他们的问题往往很复杂：

数据分散在不同系统里，权限规则非常严格，业务流程高度定制，组织里不同部门的目标还不一定一致。

这种情况下，如果只靠标准产品、文档和远程支持，很难真正进入核心业务。

所以 Palantir 的工程师会深入客户现场，和客户一起梳理问题、接入系统、开发功能、推动上线。

这就是 forward deployed 的含义：工程师不是待在总部等需求，而是被“部署”到问题发生的一线。

过去，这种模式主要发生在政府、金融、能源、制造等复杂行业。

但现在，大模型把它重新推到了台前。

原因很简单：AI 产品天然需要进入业务现场。

一个普通 SaaS 工具，可能只要开账号、配权限、导入数据就能开始用。

但一个 AI 系统不一样。

它要理解企业的知识库、业务规则、审批流程、数据边界、合规要求，还要知道什么时候可以自动处理，什么时候必须交给人。

这不是一个“开箱即用”就能完全解决的问题。

所以，OpenAI 最近推出了 Deployment Company，核心目标就是帮助企业把 AI 部署到真实业务中。这里面很重要的一类角色，就是 Forward Deployed Engineers。

这其实是一个信号：

大模型公司不再只卖模型能力，也开始重视“把能力变成业务结果”的过程。

二、FDE 到底和普通工程师有什么不同？

普通软件工程师的工作重心，通常是构建可复用、可维护、可规模化的产品能力。

他们面对的是一类用户，目标是抽象共性问题，然后沉淀成产品功能。

FDE 也写代码，但他的起点不一样。

FDE 面对的往往是一个具体客户、一个具体场景、一个具体业务问题。

比如一家大型制造企业想用 AI 提升售后效率。

这句话听起来很简单，但落到真实工作里，问题需要考虑很多问题：

售后知识在哪里？历史工单能不能用？客户问题怎么分类？哪些回答需要审核？哪些情况必须转人工？系统要接 CRM 还是工单平台？生成的答案如何评估？出了错谁负责？

这些问题，单靠问问模型解决不了。

FDE 要做的事情，是从业务现场出发，把这些模糊问题拆开，然后变成一个可以运行的系统。

他可能要和业务负责人开会，和一线员工一起看流程，和 IT 团队确认系统接口，和安全团队讨论权限边界，然后自己动手写代码，做原型、接数据、跑测试、上线迭代。

所以，FDE 不是单纯的“懂客户的工程师”，也不是单纯的“会写代码的顾问”。

FDE 是一种跨岗位的角色：

他既要有工程师的实现能力，也要有产品经理的问题抽象能力，还要有交付负责人把事情推进到上线的能力。

三、FDE 和 OPC 的区别是什么？

这里的 OPC，我指的是 One Person Company，也就是“一个人公司”。

四、为什么 AI 时代尤其需要 FDE？

AI 落地最大的误区，就是以为“模型强了，应用自然就成了”。

企业内部却不是这样。

很多企业现在已经不缺 AI 工具。真正的问题是：

• 业务场景太模糊，不知道该从哪里切入。

• 企业数据很乱，AI 没有稳定上下文。

• 流程里有太多例外情况，demo 看起来很好，上线后问题很多。

• 一线员工不信任 AI，不知道什么时候该用。

• 管理层想看效果，但没人能把技术指标翻译成业务指标。

这些问题本质上都不是单一技术问题。

它们是技术、业务、流程、组织之间的缝隙。

FDE 的价值，就在于站到这些缝隙中间。

它不会只回答“这个模型能不能做”，还会继续追问：

• 这个场景值不值得做？

• 要接哪些系统？

• 怎么评估效果？

• 哪些环节必须有人兜底？

• 能不能先做一个小范围上线？

• 做完之后，哪些能力可以沉淀成通用产品？

这也是为什么 FDE 对 AI 公司很重要。

AI 公司如果只停留在模型层，就很难知道客户真正需要什么。

但 FDE 深入客户现场之后，会看到大量真实需求：哪些工作流最适合 agent，哪些地方 RAG 不稳定，哪些评测指标有意义，哪些功能应该做进平台。

换句话说，FDE 既是交付角色，也是产品发现角色。

他把一个客户现场里的具体问题，变成下一代产品可以复用的能力。

五、FDE 不是高级外包，关键看能不能沉淀

当然，FDE 这个角色也有争议。有人会觉得，这不就是高级外包吗？

客户有需求，工程师去现场做项目，做完交付，然后继续下一个项目。

这个质疑是有道理的。

如果一个公司只是派工程师不断做定制项目，每个客户都从头写一遍，最后留下大量不可维护的技术债，那它确实很容易变成项目制服务。

这不是 FDE 的理想状态。

真正有价值的 FDE 模式，重点不只是“帮客户做成一个项目”，更关键的是形成一个循环：

• 先解决一个真实客户的问题。

• 再从这个问题里识别可复用的模式。

• 然后把这些模式沉淀成产品、工具、框架、模板和方法论。

• 最后让后面的客户部署得更快、更稳。

也就是说，FDE 走的是一条从“定制”到“产品化”的路。

如果只定制，不产品化，这个模式会越来越重。

如果能从定制里提炼共性，它就会变成 AI 公司理解市场、打磨产品、扩大部署能力的重要方式。

这也是 FDE 和传统外包最大的差别：外包通常以交付项目为终点。好的 FDE 会把交付变成产品进化的起点。

六、对普通工程师来说，FDE 意味着什么？

我觉得，FDE 的兴起，对很多工程师是一个很重要的提醒。

过去很多工程师的成长路径，是不断加深技术栈：学框架、学架构、学性能、学分布式、学云原生。

这些能力仍然重要。但 AI 时代，把技术放进真实业务里，形成闭环 更加重要。

你不能只会写代码，还要知道代码解决了谁的问题。

你不能只会调模型，还要知道模型输出怎样才算有用。

你不能只做一个 demo，还要知道怎么上线、怎么评估、怎么迭代、怎么让人真正用起来。

这也是为什么我觉得，FDE 这个岗位虽然来自国外语境，但它对国内的 AI 应用工程师很有启发。

国内很多企业现在并不缺“会调用大模型 API，会用 AI Coding 工具的人”。

真正缺的是：能听懂业务方的问题，能把问题拆成系统方案，能做出可运行原型，能接入真实数据，能设计评测方法，能推动上线，还能把一次项目经验沉淀成可复用能力。

这其实就是 AI 应用工程师的高阶形态。它不一定非要叫 FDE。也可能叫 AI 解决方案工程师、Agent 应用工程师、AI 产品工程师、行业应用工程师。其实，名字不重要。

重要的是背后的能力要求变了。

七、未来更值钱的，是“用 AI 拿到结果”的人

过去两年，大家谈 AI，更多是在谈模型。

模型参数、上下文长度、多模态能力、推理能力、工具调用能力等。

这些当然重要。

但接下来，真正决定 AI 能不能进入企业核心流程的，可能不是模型本身，而是部署能力。

• 谁能把模型接进业务？

• 谁能让 AI 在真实流程里稳定工作？

• 谁能让一线团队愿意用？

• 谁能把一次成功经验复制到更多场景？

这些问题背后，需要的不只是算法工程师或传统软件工程师，还需要一种更贴近业务现场的新型工程能力。

AI 时代不仅需要“造模型的人”，也需要大量“把模型真正用到真实业务中的人”。

对个人来说，这可能是一条新的职业路径。对企业来说，这可能是一种新的组织能力。对 AI 行业来说，这可能是从 demo 走向生产的关键一环。

如果说过去的软件时代，工程师的核心价值是“把需求变成系统”。那么 AI 时代，一类新的工程师价值就是，用 AI 拿到业务结果。