FDE：把 AI 真正送进业务的人

FDE 是那个愿意跟客户一起下场，把「AI 看起来能用」变成「业务真的在用，而且出了问题有人负责」的工程师。

这两年，调用一个不错的大模型、做出一个像样的演示版，已经不算难了。

真正麻烦的事情都在后面：模型会答错，系统有延迟，知识库并不完整，老系统接不进去；业务部门说不清规则，法务和安全团队还有一长串顾虑。

最近听完「课代表立正」对 Cresta FDE 团队负责人 Jove 的访谈，我一直在想：当模型能力越来越容易获得，谁来补上演示版到真实业务之间的这段路？

FDE——Forward Deployed Engineer，中文常译作「前向部署工程师」——就是其中一种答案。

Jove 当时带着一支约 30 人的团队，目标是继续扩到 100 人。比团队规模更值得琢磨的是，他们为什么需要这样一群人：既写代码、懂业务，又要获得客户信任，最后还得为结果负责。

FDE 到底交付什么

假设一家酒店想用语音 AI 接客服电话。

老板真正关心的，大概不是底层用了哪一个模型。他关心的是客人打来电话时，AI 能不能听懂，会不会乱承诺；该转人工时能不能及时转，有没有伤害品牌。

普通工程师可能先问接口和架构，顾问会先做调研和方案，售前要证明产品值得买。FDE 还要继续往前走：把业务规则、模型能力、知识库和系统接口拼起来，然后盯着它在真实环境里运行。

访谈里把 FDE 比作「一家小公司的技术负责人」，我觉得很贴切。他要判断哪里适合用 AI，哪里必须停下来；也要亲手把系统做出来，完成测试、上线和修正。

代码只是工作的一部分。FDE 真正交付的是客户敢用的结果。

这份工作是一个闭环

客户很少带着一份清清楚楚的需求文档来。他们更可能只说：「我们也想用 AI」「能不能减少客服」「能不能做个智能前台」。

FDE 的起点不是马上写提示词，而是把问题问清楚：到底想改善什么结果？现在哪一步最痛？AI 如果出错，最坏会发生什么？

接下来，大致会经历四件事。

先把业务说清楚

不少公司内部对同一条业务流程都没有统一答案。FDE 要找到真正能拍板的人，梳理规则、风险和成功标准。有时聊到最后才会发现，最该先修的不是模型，而是那套没人说得清的流程。

再把智能体做扎实

除了选择模型，还要处理资料检索、工具调用、延迟、权限、转人工、失败后的降级，以及测试与评估。放到语音场景，还会多出停顿、噪声、口音和用户报电话号码时的节奏。

这些细节平时很少出现在演示里，却决定了系统能不能上线。

上线后继续负责

AI 是概率系统，很难靠一次配置永远正确。模型版本、成本和接口会变，客户的业务也在变。

FDE 需要观察真实使用，发现错误后止损、解释、修复，再重新验证。项目通过验收，并不等于工作已经结束。

把前线经验带回产品

如果每个客户都从头定制，公司最后会变成一家靠堆人增长的咨询公司。

好的 FDE 团队会把重复出现的问题变成接口、模板、测试集、文档和平台能力。下一次交付因此更快，产品也会因为真实客户的拉扯而继续长出来。

这一步很关键。FDE 一只脚在客户现场，另一只脚仍然站在产品里。

它和外包到底有什么不同

FDE 干的很多事情，看起来确实像外包：到客户现场、理解需求、写代码、做集成，再把系统交付上线。

差别不在于谁的技术更高级，而在于项目做完以后，问题归谁。

传统外包通常按照合同完成一个项目。客户验收，项目收尾；同类需求换个客户再来一次，也可以再签一份合同。FDE 还要对两件事负责：眼前这个客户有没有拿到业务结果，这次解决的问题能不能进入产品，供下一个客户直接复用。

这也解释了为什么有些公司把 FDE 放进产品工程团队，而不是客户服务或项目交付部门。

组织位置会慢慢改变一个人的判断。如果只对工时和验收负责，无穷无尽的定制很容易被接受；如果还要对产品负责，就会不断追问：这次解决的究竟是一个客户的特例，还是产品本来就缺的一块？

所以 FDE 不是靠一个新名字和外包划清界线。真正的分界线，是他有没有把客户现场的问题带回产品，有没有主动减少下一次还要靠人做的事情。

难招，是因为边界太宽

AI 编程没有让 FDE 的工程门槛消失。

一个缺少基本工程经验的人，很难判断 AI 生成的代码是否安全、测试是否充分，系统究竟是真的可靠，还是碰巧跑通。会用 Claude Code、Cursor 或 Codex，越来越像会用搜索和编辑器，很难单独成为竞争力。

可只懂技术也不够。

客户不会因为模型参数漂亮，就把核心业务交出来。FDE 得听出对方没有明说的顾虑，知道什么时候继续追问，什么时候承认不知道，也要能在客户想要一个危险方案时把「不行」说清楚。

访谈里提到，理想候选人往往有三年以上工程经验，做过真实的 AI 智能体，懂测试和评估，也有客户沟通、咨询、创业或早期工程团队的经历。

创业失败甚至未必是减分项。经历过一件事从「能做」到「做成」的人，通常更清楚中间会冒出多少计划外的问题。

真正能获得客户信任的人，往往还有几个共同点：

• 先听懂对方担心什么，再展示自己懂什么；
• 技术上足够扎实，但不会为了证明自己正确和客户较劲；
• 遇到未知就说清楚，再尽快查明白；
• 出错后先处理影响，不把责任推给模型或提示词。

AI 会替代 FDE 的哪一部分

今天需要 FDE 手工完成的配置、测试和排查，未来会有越来越多被平台和 AI 自动完成。这其实正是 FDE 应该推动的结果：把做过一遍的事情，变成系统下一次可以自己做。

可简单问题消失后，业务环境还会继续变复杂。

今天处理的是语音客服、知识库和延迟，明天可能轮到权限、审计，以及多个智能体协作时的责任边界。模型能执行更多事情，人就要做更困难的决定。

我暂时看不到「负责」这件事被完整自动化的路径。

客户仍然需要有人协调冲突、做取舍，也需要在结果不好时站出来。FDE 的具体技能会变，靠近真实结果的那部分价值反而更难消失。

在中国，FDE 会不会变成更累的外包

这个问题可能比「FDE 是不是风口」更重要。

北美人工成本高，软件订阅和企业采购相对成熟，减少等待和人工的价值比较容易算清楚。中国市场的人工成本、采购习惯、私有化要求和回款方式都不同。

如果客户只愿意按项目付费，又要求大量一次性定制，FDE 很可能只是一个更新鲜的职位名称，干的还是更辛苦的外包和驻场实施。

所以我会用三个问题判断一个国内的 FDE 机会：

• 客户有没有明确预算，也有没有真正负责结果的人？
• 上线后的业务变化能不能被量化？
• 这次积累的能力，能不能复用给下一个客户？

三个问题都说不清楚时，扩团队只会更快地放大交付成本。

FDE 模式在国内能不能成立，最后看的是公司愿不愿意克制定制冲动，也看客户是否真的愿意为结果付费。岗位名字可以直接翻译，背后的商业条件没法照搬。

我真正关心的是责任边界

听完这场访谈，我最感兴趣的并不是多了一个职业标签。

过去，一个人掌握某种语言、框架或数据库，就能凭技能分工在组织里找到位置。AI 让这些单一技能越来越不稀缺。接下来更有价值的人，往往能跨过技术、业务和人际边界，把一件充满不确定性的事推到结果。

这不意味着每个人都要转行做 FDE。

但工程师、产品经理和创业者都可以借用它的视角：少问一句「我会不会这个工具」，再多问一句「这件事最后出了问题，谁来发现，谁来修，谁来负责？」

一个新岗位是否值得存在，答案也许就藏在这条责任边界里。