--- title: "昨天在深圳做完 FDE 路演，我更确定：企业真正缺的不是模型" author: Miles Ma date: 2026-08-12 section: FDE 实战 url: https://immilesma.com/blog/fde-enterprise-gap/ x: https://x.com/miles_mazy/status/2087516591244361755 description: "从深圳一次 FDE 路演中的提问出发，讨论 FDE 是岗位还是组织能力，销售、工程和 Agent 应怎样配合。围绕企业现场的数据、业务与责任，梳理程序员转型和企业使用 FDE 时要面对的现实问题。" --- # 昨天在深圳做完 FDE 路演，我更确定：企业真正缺的不是模型 > 从深圳一次 FDE 路演中的提问出发，讨论 FDE 是岗位还是组织能力，销售、工程和 Agent 应怎样配合。围绕企业现场的数据、业务与责任，梳理程序员转型和企业使用 FDE 时要面对的现实问题。 昨天，我去深圳，代表团队，给投资人和协会，做了一场 FDE 项目路演汇报。 ![文章配图](https://immilesma.com/blog/fde-enterprise-gap/media/01-image-06.jpg) 原本准备讲的是科研系统怎样配合 FDE，把 AI 真正部署进企业；现场聊到最后，大家反复追问的却是几个更基础的问题：FDE 到底是一个人，还是一套服务？它更像销售，还是更像工程师？程序员能不能转？企业又该怎么用这种人？ 这些问题放在一起，刚好暴露了今天企业 AI 落地最大的缺口。**模型越来越强，能把模型、业务、数据和组织责任接起来的人，依然非常少**。 我索性把现场没来得及展开的部分写下来。它不只来自这份路演 PPT，也来自我过去做算法部署、企业沟通和 FDE 项目时碰到的那些麻烦。 ## FDE 的缺口，远比一个岗位缺多少人更大 讨论人才缺口，最容易掉进招聘数字里：今年多了多少职位、薪资涨了多少、哪些大厂开始招人。这些数字会变，统计口径也很乱。我更愿意从企业每天正在发生的事情看这个缺口。 现在做一个 AI 演示已经很容易。拿几份文档做问答，用模型生成报告，接几个工具跑一段自动化，半天就能看到效果。真正进入企业，问题马上变了：资料有多个版本，数据散在不同系统，账号权限拿不到，业务规则只存在于老员工脑子里，模型答错以后没人知道该不该拦，上线后又没有人维护评测和成本。 模型回答得再漂亮，只要没有进入真实工作流，就没有产生业务结果。系统能够调用接口，只要权限、审批和失败恢复没做，企业也不敢让它执行。 **企业真正缺的，是有人愿意把“模型能做什么”一路负责到“客户真的得到什么”**。 ![文章配图](https://immilesma.com/blog/fde-enterprise-gap/media/02-image-04.jpg) OpenAI 现在对 FDE 的职责描述很直接：从客户发现、技术范围、系统设计、构建，一直负责到生产上线；成功也不以演示完成计算，而看生产采用、工作流变化以及现场反馈有没有进入产品和模型路线。当前岗位体系里还拆出了 FDE、Forward Deployed Software Engineer、Technical Deployment Lead 和 Platform Engineer。Anthropic 也在 Applied AI 下面配置工程、架构和部署相关角色。 这里缺的显然不只是一种工程师。企业不知道该从哪项工作开始，技术团队能做 Demo 却不熟悉客户现场，业务团队知道痛点却不能把它翻译成系统。项目好不容易做完一次，现场改出来的接口、流程和判断又跟着交付团队一起离开。下一位 FDE 进场，还是得从头摸一遍。 单独补上其中一段，项目还是会卡。企业招一个算法工程师，可能解决模型问题，却没人确认业务目标；找一家咨询公司，可能得到一套方案，却没人把代码跑进生产；让销售推动项目，可能拿下订单，却把无法兑现的承诺留给交付团队。 所以我说这个缺口巨大，指的不是某个招聘网站上少了多少简历。**企业 AI 从兴趣走向结果，中间整条责任链都是空的**。 ## FDE 到底是人，还是一种组织能力 从名字看，FDE 当然是一个岗位：Forward Deployed Engineer。Forward 指向前部署、靠近问题现场；Engineer 则要求这个人真正参与构建和上线，不能只停在建议和协调上。 但把视角拉远，**FDE 更像一套把现场和研发连接起来的组织机制**。 昨天的 PPT 里，我把它画成了两端。左边是客户现场，负责理解业务、搭建方案、用真实数据验证价值；右边是研发后台，负责产品规划、平台开发、版本发布和基础能力。FDE 在中间不断来回：把平台能力带到现场，再把现场验证过的方法、失败经验和共性需求带回研发后台。 ``` 研发后台：模型、平台、通用组件、产品路线 ↓ 能力下沉 FDE ↑ 资产回流 客户现场：流程、数据、例外、验证结果 ``` **如果只有向下输出，FDE 很快会变成高级实施或驻场外包**。每个客户重新写一遍，项目越多，公司越依赖堆人。如果只有向上汇报，现场又变成需求收集，客户等几个月才能看到一次产品排期。 我理解的 FDE，要让两个循环同时转起来：研发能力向现场下沉，现场成果向研发后台回流。项目里临时改通一个接口、处理一个例外，只能算解决了当下的问题。FDE 还要把这些做法拆开看：哪些只是这个客户的特殊配置，哪些可以抽成模板、组件、评测集或标准流程；再带着证据交给后台研发验证、入库和维护。昨天 PPT 里的数据接入模板、本体建模方法、行业分析模型、智能体技能库、证据追踪体系和研究脚手架，都是这个循环应该留下的东西。 它们不一定全部做成软件产品。一套经过验证的数据字段定义、一份异常处理清单、一个行业术语映射、一组评测题，同样是研发资产。下一次遇到相似项目，团队不必照搬上一家客户的方案，也不用从零开始，而是在已有底座上换数据、改配置、补少量业务逻辑，交付速度自然会更快。 所以，FDE 可以由一个人承担，也可以由一支小队共同承担。一个人时，他要同时做发现、方案、工程和交付；项目变大以后，可以拆成客户负责人、FDE、FDSE、平台工程师和领域专家。**岗位怎么拆可以变，但必须有人从客户问题负责到生产结果，再把可复用的资产带回研发**。如果项目上线以后就撤场，这条链其实还没走完。 企业如果只改一个职位名称，没有改变部门之间的责任边界，就没有真正建立 FDE 能力。 ![文章配图](https://immilesma.com/blog/fde-enterprise-gap/media/03-image-03.jpg) ## 销售属性更重要，还是技术属性更重要 这是路演后最容易争论的一个问题。 我的答案很明确：**工程能力是 FDE 的门槛，客户与商业能力决定 FDE 的上限**。 没有技术能力，FDE 很容易变成会讲 AI 的销售。他能把模型、Agent 和私有化部署讲得很热闹，却无法判断数据能不能用、接口能不能接、模型为什么错、系统能不能上线。客户问一句“这个承诺怎么验收”，答案就只能回到漂亮的 PPT。 但一个技术很强、完全不愿意碰客户的工程师，也很难做好 FDE。他可能写得出最复杂的系统，却不知道企业愿意为什么付钱，不知道哪位业务负责人承担结果，也不知道客户说“我们想做知识库”时，背后可能只是客服每天在几十份文件里找答案。 这里说的销售属性，和喝酒、应酬、催客户签字没有多少关系。FDE 得找出客户正在为什么付出代价，让不同角色愿意把真实流程和限制说出来，再把技术选择讲成范围、价值、风险和代价。客户压周期、压价格、压效果时，还得守住不能乱承诺的边界。 而且这些事最后仍然要回到工程判断。客户要求两周上线，你得知道应该缩范围，还是这个系统根本做不到；客户坚持本地部署，你要继续追问数据边界、并发和运维能力；客户想让 Agent 自动执行付款，你要敢把审批、幂等和回滚摆到桌面上。 FDE 不是在“销售”和“技术”之间选边。它的稀缺性恰恰来自两者必须落在同一个结果上。销售能力让你进入现场，工程能力让你留下来，交付结果决定客户下一次还愿不愿意让你进来。 如果一定要给不同阶段一个侧重点，我会这样判断：程序员转 FDE，最该补的是客户发现、表达和谈判；销售或咨询转 FDE，最该补的是动手构建、数据、系统集成和生产责任。两边都不能靠 AI 帮你假装已经会了。 ![文章配图](https://immilesma.com/blog/fde-enterprise-gap/media/04-image-01.jpg) ## 为什么这次路演要把科研系统放进 FDE 昨天的主题叫“科研配合 FDE 工程师”。这里说的科研，是把证据、复现和审查纪律带进企业交付，给 FDE 加一套更严格的工作方法。 企业 AI 项目有一个麻烦：很多结论看起来都像真的。 模型说“这个方案能提升效率”，供应商说“这个模型支持某项能力”，工程师根据参数估算吞吐，演示跑通了一批样本，客户又根据经验判断可以上线。如果不区分这些结论背后的证据，它们最后会被一起写进方案，仿佛可信度完全相同。 路演 PPT 里把证据拆成了六类： - REQUIREMENT：客户或项目明确提出的要求； - CALCULATED：根据公开模型和假设计算出来的结果； - SIMULATED：使用记录下来的输入和条件完成的模拟； - MEASURED：在可重现条件下实际观察到的结果； - SUPPLIER_DECLARED：供应商或外部权威给出的声明； - CERTIFIED：有明确认证记录支持的结论。 这六类不需要排高低，真正要防的是互相冒充。根据并发和 Token 量算出的成本，只能叫计算结果；测试环境跑通，只能说明在那组条件下测到了；供应商写“支持私有化”，不代表已经通过客户自己的安全审查。 **一句话能不能进入交付方案，取决于它有什么证据，也取决于证据能不能被重新检查**。 这套方法能直接改变 FDE 的日常工作。客户提出目标时，先标记为需求；AI 帮忙分析时，把假设和来源保留下来；工程师做小步实现，运行验证器、扫描器和测试；AI 可以参与第二轮审查，人再确认隐私、边界和最终结论。失败后，团队要能回到一个明确状态继续，而不是重新翻聊天记录猜当时为什么这样做。 昨天 PPT 中的六条原则也就有了实际用途：数据优先、证据分级、可重现、可恢复、人类负责、隐私边界。它们听起来像科研要求，却都是企业交付里经常缺的东西。一个 FDE 如果只留下代码，没有证据、决定和恢复方法，研发后台就无法判断哪些能力值得复用，换个人以后项目也会重新失忆。 ![文章配图](https://immilesma.com/blog/fde-enterprise-gap/media/05-image-08.jpg) ## 一个 FDE 带一群 Agent，能不能完成企业 AI 转型 这是昨天路演最后一页，也是我认为最值得继续验证的一句话： > 一个 FDE 带着一群 Agent，就能完成 AI 转型的交付。 我认可这个方向，不过得补上一个前提：Agent 可以扩展执行能力，责任转不出去。 以前，一个人很难同时完成客户研究、会议整理、方案比较、原型开发、测试、文档和项目复盘。现在这些工作可以拆给不同的 AI：有的负责搜索与整理，有的检查代码，有的生成测试，有的比较会议记录和当前方案是否冲突。FDE 可以用更小的团队完成过去需要多人协作的工作。 AI 不知道客户没有写进文档的利益冲突，也不知道一句“原则上可以”到底算不算承诺。它不能自行决定哪些数据允许上传，不能代替负责人批准范围变化，更不能在项目失败时承担商业后果。 所以这套人与 AI 协作系统需要一道明确的门：**AI 可以提出、实现和审查，人负责授权、合并和最终判断**。原始材料可以由 Agent 整理，进入项目事实库之前必须由人确认；代码可以由 Agent 起草，进入生产之前必须经过测试和审批；报告可以由 Agent 生成，证据类型不能由它自行升级。 **Agent 让 FDE 的手变多了，没有替 FDE 长出客户现场的眼睛，也没有替他承担签字的责任**。 我越来越相信，未来会出现一种很小的交付团队：前面是少数能够进现场、懂业务、敢作技术判断的 FDE，后面连接研究、开发、测试和交付 Agent，再由平台团队提供稳定底座。Agent 可以帮助整理现场差异、补齐文档、生成测试，把一次性交付物改造成候选资产；FDE 和后台研发再决定哪些进入公共组件，哪些留在客户项目里。团队人数可能会少，对领头那个人的判断力要求却会更高。 ![文章配图](https://immilesma.com/blog/fde-enterprise-gap/media/06-image-05.jpg) ## 程序员怎么转型 FDE 程序员转 FDE 的优势很明显：有工程基础，理解系统边界，也更容易识别一个 AI 演示离生产还有多远。真正困难的地方，是从“别人把需求写清楚，我负责实现”，转到“需求本身不清楚，我先判断什么值得实现”。 转型不必从背一份更长的技术栈开始。RAG、Agent、MCP、模型部署当然要学，但它们只是工具。更有效的办法，是完整跑一次小型交付。 找一项你接触得到的真实工作。可以是客服查资料、销售整理会议、运营核对数据，也可以是企业培训后的问题收集。跟着一个实际使用者走完最近一次任务，记录输入、动作、判断、系统、输出和例外；再从中找一个高频、可测、失败后能人工接管的环节。 接下来做一个很小的版本。先写清现状和基线，再写第一阶段改变哪一步、明确不做什么。用真实但脱敏的样本验证，记录哪些地方失败。最后把系统、评测、运行说明和复盘一起留下，再把其中可复用的部分整理成研发后台能够接手的资产候选。 转型过程中，我会刻意训练四类产出： - 一份能让客户纠正的现状判断； - 一份有范围和验收条件的交付方案； - 一个能够使用真实样本验证的最小系统； - 一套讲清失败、修复和业务变化，并能回流研发后台的资产包。 **这四样东西比“我学过十个 Agent 框架”更能证明你具备 FDE 能力**。它们也正好对应昨天路演里的人与 AI 循环：提出问题、定位来源、小步实现、运行验证、双重审查、留存恢复。 程序员还要主动进入一些过去可能躲开的场合：跟业务负责人谈目标，跟一线员工看真实流程，跟 IT 讨论权限，跟采购谈范围变化。做 FDE 以后，沟通不再是开发前的准备工作，**沟通本身就是系统设计的一部分**。 ![文章配图](https://immilesma.com/blog/fde-enterprise-gap/media/07-image-07.jpg) ## 企业应该怎样正确看待 FDE 企业最危险的做法，是把 FDE 当成一个“懂 AI 的万能驻场”。什么需求都交给他，所有部门都不提供负责人，最后再用“有没有做出一个智能体”验收。 FDE 不是替企业承担内部决定的人。他可以还原流程、指出矛盾、给出方案、参与构建，却不能替业务部门确认规则，不能替数据 Owner 开放权限，也不能替管理层决定什么风险可以接受。 **企业要让 FDE 产生价值，至少要提供四样东西：真实工作现场、能够使用的样本、有权作决定的人，以及允许从小范围验证的空间**。 ![文章配图](https://immilesma.com/blog/fde-enterprise-gap/media/08-image-02.jpg) 项目做完以后，企业还得回头看有没有留下两层能力。对客户，要留下可接管的系统、数据标准、证据规则、评测集、运行手册和失败边界；对交付方的研发后台，要留下经过脱敏和抽象的模板、组件、行业规则及评测方法。前一层避免客户长期依赖驻场人员，后一层让下一次同类项目能够站在这次交付的结果上继续做。 昨天的路演把商业模式分成效果付费、定制开发和私有化部署三层。这个方向可以成立，但企业不应该一上来把三层全部购买。问题还没验证时，先做诊断或小范围验证；场景成立但系统差异很大，再进入定制开发；数据和基础设施真的有明确约束，才讨论私有化部署。按效果付费也必须先约定基线、归因和双方投入，否则“效果”只会变成新的争议。 对企业来说，判断 FDE 是否合格，可以问得很简单：他有没有深入真实流程，有没有亲手参与构建，有没有用证据说明结果，有没有把现场经验变成研发后台接得住的资产，有没有让客户内部团队逐渐减少对他的依赖。 如果答案都是“没有”，这个岗位无论叫什么，本质上仍然只是销售、咨询或外包。 ## 这场路演之后，我对 FDE 的理解更具体了 我以前做 AI 算法和模型优化部署，更熟悉的是模型这一端。后来做企业内部沟通、培训和 FDE 项目，才越来越清楚：模型能力只是起点，企业真正愿意为结果付钱。 FDE 的机会很大，也确实难做。它要求一个人既能进客户现场，又能回到代码和数据；既能推动项目，又敢拒绝没有证据的承诺；做完眼前这一个客户，还要把现场验证过的东西送回研发后台，变成下一个项目可以调用、修改和继续迭代的资产。 我并不想把销售、咨询、产品经理和程序员粗暴塞进一个岗位。只是 AI 已经让一些原本需要多人协作的工作可以由更小的团队承担，FDE 恰好站在最前面：掌握上下文、组织 Agent、完成工程交付，也负责把一次项目变成组织下一次还能使用的能力。 **未来真正稀缺的，不只是会使用 AI 的人，而是能带着 AI 进入真实世界、把复杂问题做成可验证结果的人**。 ![文章配图](https://immilesma.com/blog/fde-enterprise-gap/media/09-image-09.jpg) 我是 Miles，一名从大厂转型 FDE 的 AI 算法专家，做过模型优化部署，也做过企业内部沟通与培训。昨天在深圳的路演，只是这条路上的一次现场验证。 关注我 @miles_mazy，我会继续把 FDE 怎么找客户、怎么沟通、怎么做方案、怎么带着 AI 完成交付写清楚。**一起成长，一起赚钱**。 --- [在 X 查看原文](https://x.com/miles_mazy/status/2087516591244361755)