文｜新立场 今年 3 月 6 日上午十点，深圳腾讯大厦楼下开始排队。人们带着电脑，等腾讯云工程师帮自己安装 OpenClaw，首批八十多人在十点开始排队，到十一点，数百个预约号已经发完。据腾讯方面提供的信息，当天有近千名开发者和 AI 爱好者来到现场。队伍里有退休航空工程师，还有小学四年级的学生。 OpenClaw 是开源软件。腾讯提供的 Lighthouse 云端部署方案，最快只需要五分钟。另一边，社交平台上已经有人做起代装生意。远程安装报价一般在 50 至 100 元，上门服务通常在数百元。软件可以免费获取，部署工具也越来越简单，人们却依然愿意为安装和配置付费。 六个月后，腾讯又做了一件相似的事。9 月 10 日，腾讯云推出 FDE 工程师认证，培训合作伙伴完成智能体项目的需求分析、方案设计、应用搭建、交付实施与安全合规。同一天，月之暗面宣布 Kimi 企业合作伙伴计划，与传统 IT 服务商、系统集成商共同培养前线部署工程师。 火山引擎的公开招聘页面上，也出现了几种不同的 FDE：有人负责 Agent 的开发部署，有人负责模型选型与推理优化，还有人专门进入客户现场，弄清楚客户究竟需要解决什么问题。 在大模型商业化中，一直有一段很难省掉的工作，即模型可以通过API提供给成千上万家企业，企业却各有自己的ERP、数据库、权限体系和业务流程。模型可以同时升级，客户的系统和组织却无法同步改变；模型卖出去以后，往往还需要有人跟进去，帮助它进入具体的工作环境。 因此，"FDE热"暴露的问题是，如果每增加一家客户，都要多派几名工程师，那大模型公司最终会变成什么样的公司？ 同一个模型，接不进同一家公司 大模型最初看起来是一门接近标准化的软件生意。 把能力封装在 API 后面，制定统一的价格和调用方式，客户自行完成开发。模型升级一次，所有使用同一版本的客户都能受益。 但模型进入企业以后，工作通常没这么简单。假设一家企业希望 AI 帮忙审核合同，工程师真正开始实施时，首先要搞清楚合同存在哪里、谁可以读取、审核标准来自哪份制度、哪些部门有权修改，最后由谁批准。 模型即使准确发现合同中的异常条款，也未必有权访问原始文件，更无法自行决定企业内部的审批程序。换一家客户，这些问题往往要重新回答。 传统软件行业长期面对"企业越大，历史系统越多，定制需求越复杂，交付工作也越重"的问题。开发一套产品可能只需要做一次，部署到不同企业，却需要重复投入大量人力。 大模型没有消灭这些问题，只是把它们重新暴露了出来。 Palantir 很早就把解决这道难题的工作变成了一种产品开发方法。"human equivalent of backpropagation"——人类版的反向传播：工程师尽可能靠近客户实际面对的问题，与核心研发团队共同工作，再把现场不断产生的反馈送回平台，形成新的产品能力。 理解这套方法，可以从 Palantir 的三种角色开始。Echo 要找到客户真正需要解决的问题，协调业务人员和管理层；Delta 负责让技术方案运行起来，包括数据基础设施和实际应用；Dev 则与前两者协作，把已经验证的解决办法开发成可供更多客户使用的平台能力。 三种角色存在交叉，但形成了从现场发现问题到产品开发的协作链条。 火山引擎今年公开招聘的 FDE，体现了类似的分工。通用 FDE 要在客户环境里连接 API 和数据系统，从应用原型一直做到生产级 Agent，还要建设评估和可观测体系。算法方向的 FDE 则进一步负责模型选型、微调和推理优化，并把客户遇到的技术问题转化为方舟与 Seed 的产品需求。 火山引擎还专门招聘 FDE Echo，这个岗位的重点是访谈和观察客户，把模糊、零散的业务反馈整理成可以验证的产品机会，招聘要求甚至明确写入了至少五年的解决方案咨询工作经验。 这类岗位的出现，很大程度上是为了缩短客户需求在组织内部传递的距离。过去，一家企业说"月底对账太麻烦"，需求可能先由销售人员接收，再交给售前、产品经理和研发团队，几轮传递以后，研发收到的也许只剩下"需要增加一个财务接口"。 但客户遇到的问题，可能与接口本身毫无关系。是两个部门采用不同的数据口径，还是历史记录缺失？究竟应该增加接口、调整流程，还是让 AI 代替人工核对？工程师离客户太远，很难判断。 工程师离现场越远，对问题的判断越容易依赖二手描述。 FDE试图把工程师重新推到业务面前。参与实际流程、亲手搭建方案，再把反复出现的问题带回研发。如果这套机制能够正常运行，前一个项目留下来的经验，就有机会成为后一个项目直接调用的产品能力。 这是FDE和普通项目外包最容易拉开差距的地方。一个项目做完，只留下收入和一套客户专属代码，交付就只是交付；如果还能留下连接器、工作流模板、评测方法和新的平台能力，这笔人力成本才有可能被后续客