FDE 不是工程师，是组织接口
本文是《人在回路中 Human in the Loop》系列第 7 篇。
判断溢价需要组织载体
第 6 篇说到最后，只剩一个硬问题。
AI 越便宜，动作越不值钱；动作越不值钱，判断越贵。
但判断贵了以后，判断放在哪里？
很多老板会下意识说：放在我这里。公司重大方向我拍，业务边界我定，最后责任我扛。这句话在传统组织里成立，因为动作慢，反馈慢，错误暴露也慢。老板的判断可以通过周会、审批、复盘、预算、组织任命，一层一层传下去。
AI 进来以后，这套传导链条开始不够用了。
动作突然变得太快。一个 Agent 可以一夜之间改完几百条物料，跑完几千个客户线索，生成一套产品原型，甚至直接动到生产系统。老板的判断如果还只停在脑子里、会场里、PPT 里，它就追不上动作。你以为自己还握着方向盘，实际方向盘已经被拆成了提示词、权限、日志、审批流、回滚机制和异常升级规则。
所以第 7 篇要回答的不是“FDE 这个岗位火不火”。
这不是招聘趋势文章。
真正的问题是：判断溢价如何变成组织能力。
我的答案是：FDE 是一种组织载体。
不是“工程师 + 销售”的拼盘，不是更懂客户的程序员，也不是披着技术外衣的咨询顾问。FDE 的关键不在 title，而在它把三件过去分开的事绑在一起：客户现场的真实问题、厂商侧的工程能力、组织里的责任链。
过去，销售听客户说问题，产品经理写需求，工程师等需求文档，客户成功负责上线之后擦屁股。每一段都有人，每一段也都能自证专业。但 AI 时代最要命的地方，恰恰在这些段与段之间。客户说不清楚的问题，需要有人现场拆；拆出来的流程，需要有人马上写进系统；系统跑起来以后的异常，需要有人把“这不是 bug，这是组织边界没定义”带回产品和老板桌上。
这就是 FDE 的位置。
它不是某个职能的加强版，而是判断在组织之间移动时的接口。
如果第 6 篇的关键词是“判断权、责任权、最终裁决权”，第 7 篇的关键词就是“谁把这三权带到现场”。没有这个载体，老板说再多“AI 要服务业务”，最后也会变成两种烂局：技术团队闭门造工具，业务团队拿着工具不会用；或者业务老板直接绕过组织找 AI 手搓，等出事以后才发现系统、客户和后果都无人承接。
FDE 的价值，不是帮你多写几段代码。
FDE 的价值，是让判断在客户现场、生产系统和责任链之间跑得起来。
三家公司同时承认部署瓶颈
2026 年 5 月，几个信号挤在一起，很难当成巧合。
5 月 4 日，FIS 官方公告说，它正在和 Anthropic 合作，把 agentic AI 带进银行，第一站是 Financial Crimes AI Agent。公告里有两个细节很重。第一，Anthropic 的 Applied AI team 和 forward-deployed engineers 嵌入 FIS，共同设计这个 Agent。第二，这个 Agent 要把反洗钱 alert 和 case investigation 从 days/hours 量级压到 minutes 量级，同时让调查员保留最终决策。
同一份公告还写了治理层：客户数据留在 FIS-controlled infrastructure，Agent 决策要 traceable and auditable。注意，不是“模型更聪明了，所以银行可以用了”。它说的是数据、治理、审计、调查员控制权、知识转移。
5 月 11 日，OpenAI 发布 Deployment Company。官方公告里说，OpenAI agreed to acquire Tomoro，这会给 Deployment Company 从 day one 带来约 150 名 Forward Deployed Engineers 和 Deployment Specialists。它还会以 more than $4B initial investment 启动。OpenAI 对 FDE 的描述也很直接：这些人会和 business leaders、operators、frontline teams 一起识别 AI 价值，重塑组织基础设施和关键工作流，把收益变成 durable systems。
这句话翻译成老板语言就是：模型不是终点，部署才是生死线。
再看 Google Cloud。这里我只把它当作社媒和媒体信号，不当官方硬锚。公开报道和 Thomas Kurian LinkedIn 内容显示，Google Cloud 正在扩充 AI-focused go-to-market 组织，并继续投入 forward-deployed engineers，用来把客户拉近产品、Agent 平台、工程和研究团队。
三个信号放在一起，结论很清楚。
头部 AI 公司没有把下一阶段只押在“模型再强一点”上。
它们在押部署。
为什么？因为企业里真正卡住的，从来不是“能不能生成一个答案”。卡住的是答案能不能进入真实流程，能不能连接客户数据，能不能经过审批，能不能被审计，能不能在错误时回滚，能不能把现场学到的东西带回产品。
过去一年，太多老板被 demo 骗过。会议室里，一个 Agent 能写方案、做表格、生成网页、自动回客户，看起来像一支小队。可一进生产，问题就变成另一套语言：谁给它权限？谁定义输出质量？客户投诉了谁接？数据跨域谁批？它改错了价格，谁能停？它把一个老员工靠经验判断的例外情况当成普通流程处理，谁来负责？
这不是模型参数问题。
这是部署问题，也是组织问题。
OpenAI、Anthropic/FIS、Google Cloud 这些信号真正承认的是：AI 进入企业深水区以后，单纯卖模型不够，单纯卖 SaaS 也不够，中间必须出现一种能把“能力”变成“组织结果”的人和机制。
这就是 FDE 重新被看见的原因。
FDE 是什么不是什么
FDE 这三个字最容易被写烂。
很多公司一听 FDE，就开始把销售工程师、解决方案架构师、客户成功工程师换个名字。名片变了，工作没变。售前还是做 demo，架构师还是做 PoC，客户成功还是接上线后的问题。最后老板以为自己跟上了 AI 时代，实际只是给旧岗位贴了新标签。
真正的 FDE，要回到 Palantir 的原型里看。
Palantir 官方文档说，它的平台和产品持续通过 Forward Deployed Engineering 方法开发。这个方法的核心，是工程团队尽可能靠近问题，同时和核心工程团队协同，把现场反馈综合回来，并持续发布新功能。这里面至少有三层意思。
第一，FDE 要靠近问题。
不是靠近客户关系，不是靠近采购流程，而是靠近问题本身。企业里的真问题通常不会以需求文档出现。它会藏在一个老员工的判断里，藏在一个手工 Excel 里，藏在一个长期不敢动的系统接口里，藏在“这个客户不能按普通流程处理”的例外里。FDE 如果只听会议室里的需求，就和普通顾问没有区别。
第二，FDE 要能把问题写进系统。
这里只写报告不够，只画蓝图不够，只做演示也不够。AI 时代的部署不是“告诉客户应该怎么改”，而是把模型、数据、权限、流程、审计、回滚接成能日常运行的系统。OpenAI 在 Deployment Company 公告里也用了 production systems 这组词。FDE 的工程性，不在于代码行数，而在于它要把判断变成可运行、可观测、可追责的东西。
第三，FDE 要把现场反馈反哺产品。
这是它和传统咨询最大的区别。咨询也可以懂业务，甚至很懂。但咨询项目结束以后，经验大多留在报告和顾问脑子里。FDE 如果做对了，现场踩出的坑会变成平台能力。今天某个客户现场的异常处理、权限边界、评估方法，明天可能变成产品里的一个能力、一套模板、一条默认防线。
所以我给 FDE 一个很窄的定义：
FDE 是在客户现场，把业务判断写进生产系统，并把现场知识反哺平台的人。
少一个都不行。
只在客户现场，不写生产系统，是顾问。会写生产系统，不反哺平台，是外包工程师。能反哺平台，但不进客户现场，是产品工程师。FDE 的难处就在这里：它同时站在客户和厂商中间，同时接业务语言和工程语言，同时背交付结果和产品学习。
这也是为什么它不是一个容易复制的岗位。
真正难的不是招几个强工程师去客户现场，而是公司愿不愿意让这些现场经验改变自己的产品、流程和组织边界。
组织协议层的物理化身
一个 FDE 在组织图上的位置很奇怪。
工资通常由厂商发，但他每天处理的是客户现场的问题。产出要进入客户流程，但他又不是客户员工。客户业务负责人会盯他的交付，但未必拥有正式管理权。厂商产品团队要吃他的反馈，但又不能完全按客户单点需求走。
传统组织图画不出这条线。
传统组织图只有两类关系：实线和虚线。实线代表雇佣和汇报，虚线代表协作和支持。FDE 不完整落在任何一类里。它不是客户员工，所以没有实线；它也不是普通协作方，因为它会进入系统、接触数据、参与关键流程，影响业务结果。
我更愿意把这层位置叫作组织协议层。
组织协议层不是法务合同，也不是项目章程。它是一家公司允许 AI 进入生产系统之前，必须先定义清楚的一组运行协议：哪些数据能进，哪些动作能做，哪些节点必须人工确认，哪些异常要升级，哪个角色对结果负责，哪些现场发现要反哺产品，哪些能力必须在客户侧留下来。
FDE 就是这层协议的物理化身。
这句话听起来抽象，但落到现实里很具体。
OpenAI 公告里说，FDE 会和业务领导、运营人员、一线团队一起工作，连接客户的数据、工具、控制和业务流程。这里每一个词都不是普通工程交付。数据意味着边界，工具意味着嵌入，控制意味着权限，业务流程意味着责任。只要 AI 真的进入这些地方，就已经不是单纯技术问题。
如果公司没有组织协议层，AI 部署会变成两种极端。
第一种是 IT 托管型。所有事情都进技术部门排期，业务只提需求，AI 变成一个新系统。优点是安全，缺点是慢，且很容易把业务判断压扁成需求条目。
第二种是业务野路子型。老板或业务负责人直接拿 AI 手搓，绕过系统、权限和质量边界。短期很爽，长期很危险。网页能搓出来，不代表生产系统能接；Agent 能跑起来，不代表异常有人兜；流程能自动化，不代表客户信任不会被一次错误打穿。
FDE 要解决的不是“技术和业务沟通不畅”这种老问题。
它要解决的是：AI 进入组织以后，谁来把业务判断翻译成工程约束，把工程约束翻译成组织责任，再把现场变化反馈成平台能力。
所以 FDE 不是一条虚线。
它是一层新接口。
一号位如果看不见这层接口，就会把 FDE 管成旧组织里的一个岗位：归销售，变成高配售前；归交付，变成实施工程师；归产品，变成需求收集员；归技术，变成驻场开发。每一种归口都合理，每一种也都会削掉 FDE 的一部分能力。
更准确的管法，是把 FDE 放在经营问题上，而不是放在职能部门里。
它要对一个具体场景负责：这条流程有没有跑起来，业务判断有没有被写进系统，异常有没有被接住，客户侧有没有获得可继承能力，厂商侧有没有拿到可复用反馈。只要评价口径还停在“写了多少功能、拜访了多少客户、解决了多少工单”，FDE 就会被旧 KPI 拉回旧岗位。
所以组织协议层不是一个好听的概念。
它是 FDE 能不能成立的管理边界。
知识转移条款是分水岭
FIS 那份官方公告里，最值得老板盯住的不是“调查从几天压到几分钟”。
这个数字当然吸引人。但真正决定这件事是赋能还是锁定的，是另一句话：Anthropic 的团队和 FDE 嵌入 FIS，共同设计 Agent，并 transfer knowledge so FIS can build and scale additional agents independently over time。
短引完这句，老板就该停下来。
它说的是：知识要转移，FIS 未来要能独立建设和扩展更多 Agent。
这句话如果落不下去，FDE 就会变成一种很温柔的锁定。
为什么叫温柔？因为它一开始看起来全是好事。厂商派强工程师进来，帮你梳理流程，接你的系统，跑你的数据，写你的 Agent。上线很快，效果也明显。业务团队很满意，老板也觉得买对了。
但几个月后，你会发现真正懂这套东西的人不在你公司。提示词怎么改，评估集怎么建，权限怎么切，异常怎么处理，日志怎么审，新的业务场景怎么扩展，还是要等厂商。你以为买到的是 AI 能力，实际租到的是一段外部判断链。
这就是 FDE 最微妙的地方。
它既可能是赋能，也可能是依赖。
分水岭不在口号，在工程和合同同时成立。
合同里要写清楚：哪些知识要转移，哪些配置客户能改，哪些运行日志客户能看，哪些评估方法客户能继承，哪些新 Agent 客户能独立扩展。工程里也要对应起来：如果关键逻辑都在厂商私有黑箱里，客户拿到的只是 API 调用权，那“知识转移”就是一句漂亮话。
FIS 公告另一个细节也重要：客户数据留在 FIS-controlled infrastructure，每个 Agent decision traceable and auditable。数据、可追踪、可审计，这些词合在一起，说明这不是“把 Claude 接进银行”这么简单。它在搭一套受监管行业能承受的组织协议。
老板看 FDE 项目，不能只问三件旧事：多少钱、多久上线、能省多少人。
要问三件新事。
第一，项目结束后，哪些能力留在我们组织里？
第二，我们能不能独立修改、扩展、停用和审计？
第三，厂商撤出去以后，业务还能不能跑，异常还能不能接？
答不上来，这个 FDE 项目再漂亮，也只是把你的组织判断外包出去了。
内部增长系统同骨架实证
这一段必须先立边界。
我不是说我们做了一个 OpenAI Deployment Company，也不是说内部增长系统等于 Palantir。规模、客户类型、资本结构、平台厚度，都不是一个量级。硬贴只会显得虚。
我能说的是：在更小的尺度上，我们已经踩过同一根骨架。
这根骨架是什么？
客户现场有真实业务问题，问题不是一份干净需求文档。它混着历史系统、人工经验、业务节奏、客户关系、临时例外和责任边界。你不能站在外面写一份方案，然后等客户自己消化。你得进入现场，跟着流程跑，知道哪些步骤看起来低级但不能随便删，哪些动作看起来重复但背后有判断，哪些人不是“低效人力”而是风险缓冲。
这就是第 5 篇说的：AI 替代动作，不替代组织。
内部增长系统里，真正有价值的不是“某个 Agent 能做什么”。有价值的是，我们把动作拆进了流程，把人工关口留在了关键节点，把日志、审批、暂停、回滚、异常升级这些看起来不性感的东西放进系统。
一个外行老板看 AI，喜欢看生成结果。
真正做过生产的人，先看五件事：出了错谁知道，谁能停，谁能改，谁负责，经验能不能留下。
这五件事，才是内部增长系统和 FDE 同骨架的地方。
比如一个客户现场的业务判断，不能只变成提示词。提示词太轻，改起来快，漂起来也快。它要变成配置、规则、审批点、日志字段和复盘材料。只有这样，今天这个判断才不会只存在于某个操盘者脑子里，明天换人以后也不会直接断掉。
再比如一个 Agent 流程，不能只有“自动完成”。它必须有明确的人工关口：什么情况下自动走，什么情况下进人工队列，什么情况下暂停，什么情况下升级给负责人。没有这些，AI 跑得越快，组织越紧张。
这就是我对 FDE 的真实体感。
FDE 不是去客户现场炫技，而是把现场判断沉淀成下一次可复用的组织能力。
如果每次交付都靠一个强人现场救火，FDE 只是高价劳务。如果每次现场踩出的坑，能变成规则、模板、组件、默认防线和交接材料，FDE 才开始变成平台飞轮。
对一号位来说，这个区别非常要命。
你买的到底是一个会写代码的人，还是一套能让组织变聪明的接口？
前者项目结束就散，后者会让下一次部署更快、更稳、更像你自己的能力。
这里还有一个很现实的判断标准：客户侧的人能不能接棒。
如果一个系统上线以后，所有调整都只能找外部团队，那它不是组织能力，只是外部服务。如果客户侧的业务负责人能看懂关键规则，运营能改安全范围内的配置，技术能查日志和回滚，老板能从报表里看到哪类判断被 AI 放大、哪类判断仍然必须人工兜底，那这套东西才开始变成客户自己的能力。
这也是内部增长系统给我的一个反向教训：不能把“我们很强”当成果。真正的成果，是我们越强，客户越不被我们绑住。
FDE 做到最后，不是把自己嵌得更深，而是把客户组织训练到能接住更多判断。
FDE 的三种失败模式
FDE 这个词火起来以后，失败也会变多。
不是因为 FDE 不行，而是因为大多数公司会把它做窄。
第一种失败，是变成咨询。
团队进场，访谈，画流程，做诊断，交一个漂亮方案，再做几个 demo。客户看完很兴奋，老板觉得方向对了，但真正进入系统时，还是原来的 IT 排期、原来的数据孤岛、原来的权限审批、原来的业务例外。FDE 如果不能写进生产系统，就只是咨询交付加了一层工程话术。
这种失败最隐蔽，因为过程很专业。
每一步都有文档，每一个结论都像对的。但项目结束以后，客户组织没有多出一条可运行的新能力，只多出了一套“我们应该如何 AI 化”的材料。
第二种失败，是变成锁定。
这类项目短期效果可能很好。厂商掌握模型、工具链、评估方法、运行环境和核心配置，客户只看到结果。上线快，报表漂亮，业务也真的提效。但所有关键判断都在外部系统里。客户想改规则，要找厂商；想扩展场景，要找厂商；想审计细节，还是要找厂商。
这不是赋能，是外包判断。
老板最容易在这里误判。因为他看到的是“我们终于有 AI 能力了”。但组织内部并没有长出对应能力，只是把原来的人力依赖换成了厂商依赖。过去你怕老员工走，现在你怕外部团队撤。
第三种失败，是被产品吸收成低级实施。
厂商一开始说自己重视现场，后来项目多了，平台压力大了，就会把 FDE 变成模板实施人员。客户现场的问题如果刚好能套平台，就顺利；套不上，就被解释成客户流程不成熟、数据不标准、需求不清晰。现场的尖锐反馈回不到核心产品，只能变成工单。
这时 FDE 的飞轮断了。
Palantir 官方文档里讲 FDE 方法论，关键在“靠近问题”和“与核心工程协同发布新功能”。如果现场反馈不能改变平台，FDE 就只剩前半截。它还在客户现场，但已经没有能力把客户现场变成产品学习。
三种失败合起来看，本质都是同一个问题：
FDE 被拆掉了组织接口属性。
变咨询，是没有工程接口。变锁定，是没有知识转移接口。变低级实施，是没有产品反馈接口。
所以一号位不能只问“我们有没有 FDE”。
你要问：这个 FDE 连接了哪三端？客户现场、生产系统、平台反馈，少了哪一端？
少一端，就会从组织原型退化成旧岗位换名。
给一号位的组织会清单
这一篇最后，不给岗位建议，给一号位一张会前清单。
如果你下周要开 AI 部署会，不要先问“要不要招 FDE”。这个问法太窄，也太容易被供应商带走。
先问这件事：我们要让 AI 进入哪一个真实生产场景？
不是“客服提效”“销售提效”“研发提效”这种大词。要具体到流程：哪类客户、哪条链路、哪种输入、哪种输出、哪一类异常、哪一个业务指标。说不清场景，FDE 进来也只能陪你做 demo。
第二个问题：这个场景里，哪些判断现在藏在人身上？
不是哪些动作可以自动化，而是哪些判断不能丢。老员工为什么知道这个客户要特殊处理？运营为什么会在某个时间点停手？销售为什么看见某个信号就不继续追？这些判断如果不被拆出来，AI 只会替代动作，不会接住业务。
第三个问题：哪些判断要写进系统，哪些必须留给人？
这就是第 6 篇的三权回到现场。判断权在哪里，责任权在哪里，最终裁决权在哪里。FDE 的工作不是替你取消这些权，而是把这些权重新布线。
第四个问题：项目结束以后，能力留在哪里？
留在厂商脑子里，留在客户系统里，留在规则书里，留在日志和评估集里，还是留在一堆无人维护的演示代码里？这个问题决定了你买的是一次交付，还是一段组织进化。
第五个问题：现场反馈能不能反哺平台？
如果每次客户现场的坑都只变成临时修补，FDE 就不会形成飞轮。真正有价值的部署，应该让下一个场景站在上一个场景的沉淀上开始。
把这五个问题问完，你会发现 FDE 不是一个招聘问题。
它是组织设计问题。
老板不要被“我们需要几个 FDE”带偏。你真正需要的是一层组织接口：能把客户现场的真实判断翻译成工程系统，把工程系统里的约束翻译成责任链，再把责任链跑出来的新知识带回平台。
这层接口，有的公司叫 FDE，有的公司叫部署工程，有的公司可能根本不需要这个 title。
名字不重要。
重要的是：你的判断溢价有没有载体。
没有载体，判断就会停在老板口头上；动作会被 AI 放大，后果也会被 AI 放大。
第 8 篇要继续往下走：FDE 是载体，但一家公司怎么判断从哪里开刀？这就要进入 A/O/G 三刀合一。AI 不是先改岗位，也不是先买工具，而是先判断：哪些动作要自动化，哪些组织边界要重写，哪些治理权必须重新配置。
继续读
- 上一篇：判断溢价
- 系列入口：人在回路中：Human in the Loop
- 下一篇：A/O/G 三刀合一