1. 全文概览
FDE(Forward Deployed Engineer)：前置部署工程师
- 跨界翻译官：兼具技术与业务的人才，既能写代码、做系统集成，又能听懂非技术高管的商业需求。
- 驻场交付者：FDE 通常会直接“空降”或长期驻扎在客户（如律所、医院、工厂、政府部门）的业务现场。
- 破局关键人：将通用的 LLM or 软件系统 嵌入到企业真实生产环境中，解决落地难的问题。
FDE 不是一个新词，20 多年前就有，而且现在人家利润率不低。
本质上就是为效果付费，解决企业实际的问题。
由上到下进行推动，全面配合。
- 深入工作现场，了解一线员工痛点在哪，而不是等着收集需求，因为需求传递过程中会失真；
- 不做花里胡哨的功能，只为效果收费，为解决问题收费；
- 积极主动解决问题，不用等着客户催；
- 深度集成到客户现有的系统，打通数据等通路；
- 系统做好了没人用？上手难度大吗？尽量嵌入现有流程，降低使用门槛；
- 一线员工对新系统不信任？定位他们一般找谁解决问题，咨询问题，要数据等等，先搞定 KOL；
本质上来讲，这些都是软件工程里面老生常谈的问题，只是这两年 AI 能力强了之后，能解决一些脏活累活。
当前国内也在流行做这一块，不过短时间内可能很难改变外包的名头。
因为甲方可能强势，有各种定制化的需求，还愿意给钱。钱不够你不做？有的是人做。
最近了解到某些云厂商，打着 FDE 的名号，但是目的只是让客户消耗更多 token 罢了。
2. 原文摘要
历史与现实
- 2003 年，Palantir 因为不知道间谍怎么工作发明了 FDE；
- 2025 年，整个行业因为「不知道企业里的智能体该怎么工作」而集体拥抱 FDE。
二十二年，同一个答案。
FDE 特质
- 足够宽的通才：代码、调试、数据、上云、了解模型、能搞定客户企业基础设施；
- 业务技术结合：把技术翻译成业务结果的能力
- 主人翁意识：不用客户打电话，自己立马解决
FDE 工作时间分布
- 四到五成泡在客户侧写代码调系统；
- 两三成和客户管理层对齐方向、拆问题、做架构决策；
- 一两成把现场学到的模式沉淀回公司产品线，剩下是评估优化和知识分享——写打法手册、内部布道、培训客户团队；
技术大部分工程师都有，三种翻译能力不一定
- 把业务问题翻译成技术问题
- 把技术方案翻译成高管能懂的话
- 把现场经验翻译成团队复用的知识
核心是结果导向。
怎么选公司？
- 产品平台：无平台就纯人力外包
- 知识沉淀：现场学习怎么回流到产品
- 汇报关系：FDE 汇报给产研OK，售前不OK
FDE 保证结果不被稀释
- 收钱的方式向结果靠拢，按结果验收，没用的功能不做
- 成功度量前置到开工前，先和客户商量什么叫成功，挖掘客户需求
- 最终裁判是客户组织的行为改变( 真的在用系统解决问题 )
FDE 常用的工具箱
- 平台底座层，公司的武器；
- 人工智能工程层，个人的手艺；
- 数据与集成层，进场的第一仗；( 70% 都卡在这 )
- 交付与协作层，客户环境里的生存装备；
- 知识沉淀层，规模化的杠杆；打法手册，组件库，部署清单
脚下踩着平台，手里握着工程，眼里盯着结果，身后连着产品线。
调查显示人工智能项目规模化的障碍
- 员工不愿意用新工具，但是私下里用 ChatGPT 飞起( 消费级产品做的太好 )
- 对模型输出质量的担忧
- 糟糕的用户体验
- 缺乏高管的支持
- 变革管理困难
但是没有出现：模型不够聪明、算力不够便宜、技术不够先进
本章第一性原理：在错误的问题上，一切执行力都是浪费；而企业里错误问题的密度，远超想象。
核心：写第一行代码之前，怎么确保你在解决正确的问题。
互联网核心概念：PMF( product market fit，市场与产品契合)：产品对了，市场自己会拉动增长。视角在供应方。
FDE 的核心概念：PSF( Problem solution fit，问题与方案契合度 )，视角在需求方。
- 痛点检验，是不是某个具体的人的具体痛点。提升客服效率 vs 客服主管每天得话几个小时 xxxx
- 经济性检验，解决这个问题，值多少钱？ROI 是什么？
- 可行性检验，以我们的能力和客户的现实情况，能做到几分？
麦格鲁给过一个更锋利的标准：去解决首席执行官最关注的五个问题之一。
理由很现实，只有这个量级的问题，才能帮你碾过企业内部的官僚阻力。
只接两类问题——真的难的，和真的有业务影响的。只有难没有影响，是炫技；只有影响不难，轮不到你。
一到五天、客户带真实数据、现场做出能部署的原型、高管当场拍板。要么几天内见真东西，要么不要开始。
需求从哪里来？从痛里，痛不会出现在会议室，只会出现在工作现场。
参与式观察。
难得是找到那个没人写进文档的工作流，人们真正信任的那个数据源，以及指导流程为什么是那样的人。
这些东西都只能在现场找到。
变通是组织的疤，每道疤下面都是一次系统的失败，也都是 FDE 的机会。
随说：有系统还要人工核对数据，等等，此路不通变通一下
警惕干翻译过的痛点，绕过翻译，直接到达痛的神经末梢。
理解客户的使命而不是需求，需求是痛点的二手叙述，使命才是痛点的一手出处。
MVP -> MVD 最小可部署单元
MVD 军规
- 数据真实，没有例外
- 缩小切口，而不是缩小野心( 找一个小的点先做起来 )
- 定死截止时间，倒逼取舍
FDE 的实践给出一条中间路线：数据上兼容旧系统，架构上绝不迁就旧系统，我们称之为「读旧写新」 。
顺从人的习惯，而不是顺从系统的习惯。
新系统最大的敌人不是旧系统，是旧习惯。
不要问客户要什么。
而是说：这是我做的东西，你看有哪里不满意。
哪里不对 >> 想要什么
做比说真，不要看客户说什么要看在做什么。
做调查问卷不固定出题，而是引导用户说出痛点。
「企业买人工智能，就像你奶奶拿到一部苹果手机——她想用，但需要你帮好。 」 —— a16z（安德森·霍洛维茨基金）
选对灯塔，做出标杆，让客户和你一起打磨产品。
不愿意公开替你说话的灯塔，价值至少减半。
著名孵化器 YC 有一条古训：「做不可规模化的事。 」最早的民宿平台创始人挨家挨户给房东房子拍照，在线支付公司 Stripe 的创始人当场帮户安装软件。
把交付做成能讲出去的故事，需要三个要素
- 一个具体的数字
- 一个具体的人
- 一个具体的反差
要找知识枢纽：职级不高，但是大家有问题会找他。
Palantir 常年发布场景化的技术文章OpenAI、Anthropic 把企业客户案例做成详细的技术叙事；a16z 的一篇行业雄文为整个赛道定了调——这些都不是品牌宣传，是精心经营的信任资产。
方法论开源，制造「被引用的资格」 。 把自己怎么做发现、怎么做验证、怎么做交付的方法论公开，短期看是教会同行，长期看是定义行业标准。
咨询公司与系统集成商。这是 2026 年最戏剧性的生态变局。OpenAI 部署公司的创始伙伴名单里，赫然并列着贝恩咨询、凯捷、麦肯锡——全球最大的咨询与集成巨头，从潜在的竞争者」变成了「「持股的同盟」 。逻辑很清晰：模型公司有技术，咨询公司有客户关系与行业纵深，集成商有落地人力——三方合流，才能把「人工智能转型」这个巨型市场整体吃下。
需求排期先后参考
- 灯塔价值：后续行业背书等强度
- 学习价值：能够沉淀多少可以复用的能力，能力的价值如何( 共建/白嫖 )
可以体验的技术橱窗：公开的演示环境，交互式的教程。
目的就是为了让可能的客户体验使用，或者体验，营造良好的口碑。
随说：或许这就是开源商业公司赚钱的门道？
多数技术团队都会犯的错，写提案的时候通篇讲『我们要做什么』，而不是『你将得到什么』。
好的 FDE 提案，倒金字塔结构：
第一层：业务结果，一段话说完
第二层：价值验证路径，怎么证明做到了
第三层：交付方法，我们怎么做
第四层：风险与对策，我们想过会怎么死
FDE 前期主要是驻场，现在是远程多+驻场少。
驻场的关键节点
- 关系建立的初期：第一次见面、影子工作法、与高管的信任建立；
- 高强度共创：训练营式的联合创建、关键架构决策的白板攻坚
- 政治敏感期：方案推广、部门协调、变革管理
远程的核心：深度编码、文档编写、常规迭代，需要心流的工作。
模型通常是最干净的部分。难的是找到那个每人写进文档的工作流程。
无论技术如何进化，组织内部的人性和权责博弈，始终是比技术更难解决的问题。
随说：年会不能停 2 部，都是在讲这个
每一次迅速的修复，都是客户对你信任增加的时候。
OpenAI 的 FDE 工作法里有一个对应的节奏划分：前期共创（驻场白板对齐） 、验证（建评估体系） 、交付（多日驻场构建） 。注意交付阶段仍以「多日驻场」为单元——能修得这么快，靠的就是人守在问题旁边。
评估体系的工程实践：
- 从真实案例里长出来；
- 让业务方成评委；
- 把评估体系接到生产回路上；
现有评估体系定义的好，才有模型交付的好。
降低使用门槛
- 寄生在用户已有的界面里。( excel ? 做插件、邮件？那就在邮件里完成 )
- 默认值，有效提高使用率，降低使用成本
- 把对话，做成按钮( 一键生成周报，等等)
- 先做副驾驶，再谈自动驾驶
系统集成：它是系统考古，又是组织政治，还得管数据治理。绝对是一场硬仗。
数据问题先于模型解决，否则人工智能垃圾进垃圾出又得上演。
人工智能来了之后，数据集成工作效率大增。可以通过浏览器等方式去获取数据。
尽可能自动化集成流程：流程挖掘、数据管道、系统对接、接口文档梳理，这种速度优势会复利。
对支持者的经营要点：给他能讲的材料(能讲出去的故事)、给他战功（把他的远见编程职业生涯的亮点）、给他安全感（失败时你顶在前面）。
成熟的管理变革，会提前设计受损者的出路。否则会不利于推进新的政策/系统。
电商公司得物的效率工程负责人任喜亮，把万人规模公司的 AI 转型拆成三步：
- 第一步：达共识 跟全员达成共识，降低工具门槛，让所有人先用起来；
- 第二步：分场景 把企业场景按容错空间分成四象限，容错空间大的场景（比如经营分析）优先交给 AI；
- 第三步：沉知识
设专门的知识运营小组，钻进业务团队里，把专家的隐性经验从个人脑子里搬到 AI 可见的空间。
共识、场景、知识——顺序不能反：先有人愿意用，再挑对的地方用，最后让 AI 有米下锅。
当一支 FDE 团队的每一次交付都在为下一次交付修路，它就不再是人海，而是一台正在自我加速的机器。
随说：尽量自动化
激活部署的七件武器讲完了：热修复的速度、评估体系的方向、降门槛的巧劲、集成战争的耐性、变革管理的软功、自动化的杠杆。
赚价值的差价，生意才能长久。
搭建这套系统，给你三条实践建议。其一，从第一天就采集基线——没有改造前的数据，就
没有改造后的价值证明，而基线只在项目启动
那一刻存在，错过永不再来。其二，指标必须
与客户共建——他不认的指标，算出花来也没有谈
判效力；在立项会上达成一致的那一刻，
指标就成了你们的共同语言。其三，克制指标数量——每个客户三到五个核
心指标足矣；指
标一多，就等于没有指标。
FDE 模式成立的标志，是「每个后续客户的定制量递减」。否则就是做外包。
把失败转为组织资产，需要机制
- 复盘的无罪化：诚实复盘失败的功，可能大过侥幸的成功；
- 教训的结构化：下次要尽调xxx，把失败写进后续的流程
- 失败的适度外传：自爆家丑有时候也是一种宣传。我们已经交过学费了。
企业采购人工智能最大的驱动力，正在从『效率』升级为『生存』。
应对组织政治？
- 必须带着『当地人』：找最有声望的员工，邀请他参与适配过程，征求意见。
- ”只因人们不会反对自己建造的东西”
- 让每一步扩张都有受益者：没有受益者的扩张是侵略，有受益者的扩张是解放
- 永远给『旧秩序』留体面：要尊重，比如：我们要把过去十年的经验，放大一百倍。
知识不嵌入流程，就永远只能是考古资料。
FDE 的商业模式：现场是探针、平台上杠杆、产品是复利的载体。
是什么摧毁了中国企业软件产业？
白嫖、开源、外包、招标、数科、畸形的市场结构。
中国的工程师长期消耗在『高度定制、强关系、价格战』的非标交付里。
SAP 中国区总裁还提醒了一句值得记住的话：AI 落地的最大挑战是组织惯性而非技术——基础数据架构的历史欠账，不会因为 AI 来了就自动消失。