夜雨聆风Hello，大家好，我是无界。
最近，FDE这个词突然火了。
它的全称是 Forward Deployed Engineer，通常被翻译为“前线部署工程师”。
很多人第一次听到这个岗位，都会觉得似曾相识：
不就是派一个技术人员去客户现场，了解需求、配置系统、处理问题，再把项目交付出来吗？
国内做ToB软件、系统集成和定制开发的公司，不是早就在做这些事情了吗？
一开始，我也有类似的疑问。
过去两年，我做过企业AI定制、业务场景验证、内部知识库、智能应用建设，也参与过从需求访谈、方案设计，到开发、部署、培训和持续优化的完整过程。
这些工作看起来和FDE非常接近。
但项目做得越多，我越发现：
FDE和传统交付最大的区别，不是工程师有没有驻场，而是客户究竟在为什么付钱。
传统项目里，客户购买的是功能。
FDE模式里，客户购买的是解决问题的过程，以及最终产生的业务结果。
这两种逻辑看起来只差了一句话，背后却是完全不同的商业模式。
一、FDE不是驻场写代码的人
Palantir是最早把FDE模式做出名的公司之一。
它的工程师进入客户现场后，并不会立刻打开电脑开始写代码。
他们往往会先花大量时间理解业务。
去看一线人员到底怎么工作，数据从哪里来，流程在哪个环节中断，管理层看到的报表和真实业务之间有什么偏差。
然后才开始搭建系统、连接数据、设计工作流。
所以，FDE真正的起点，并不是一份已经写好的需求文档。
而是承认一个事实：
很多企业在项目开始时，并不知道自己真正需要什么。
尤其是在AI项目里，这种情况更加明显。
客户可能会说：
“我们想做一个企业知识库。”
“我们想用AI提升员工效率。”
“我们想建设一个智能助手。”
“我们想让AI接入现有业务系统。”
这些话都没有错，但它们还不是可以直接开发的需求。
继续往下问，就会出现大量尚未解决的问题：
谁会使用这个系统？
在哪个具体场景下使用？
它要替代原来的哪一步工作？
什么样的结果才算准确？
错误由谁判断？
哪些数据可以使用？
哪些内容不能进入模型？
系统上线之后，谁负责持续维护？
如果这些问题没有回答，团队再强，也很容易做出一个“功能齐全，但业务价值有限”的系统。
因此，FDE不是被动接收需求的人。
他需要和客户一起，把模糊的业务期待，转化成能够验证、能够开发、能够交付的问题。
二、企业AI项目最贵的，往往不是写代码
做企业服务之前，我曾经以为，一个软件项目最核心的成本就是研发。
需求确认之后，产品设计、前端开发、后端开发、测试上线，按照工作量评估成本，基本就能算清楚。
真正进入企业AI项目后，我才发现，代码可能只是其中相对清晰的一部分。
最难评估的，反而是代码之外的工作。
例如：
客户不同部门对项目目标的理解并不一致；
业务人员知道痛点，但很难把痛点描述成系统需求；
技术部门关心安全、权限、部署和系统稳定性；
管理层关心投入之后，到底能不能产生业务收益；
一线使用者更关心，这个系统会不会增加自己的工作量。
供应商需要不断在这些角色之间翻译。
把业务语言翻译成产品方案；
把产品方案翻译成系统架构；
把模型能力翻译成客户可以理解的效果；
再把技术限制翻译成成本、周期和风险。
在AI项目里，还存在一个更加特殊的问题：
很多需求只有看到原型以后，客户才知道自己真正想要什么。
客户在没有使用过AI系统之前，很难准确描述交互方式、输出标准和异常处理机制。
第一个版本做出来之后，客户会对AI的能力多理解一点。
理解增加之后，需求也会随之变化。
这不一定是谁在故意扩大范围。
很多时候，这是创新项目本身的必经过程。
但在传统的软件合同里，这部分过程通常没有被单独定义。
客户觉得，理解需求是供应商应该做的。
供应商觉得，客户应该提前把需求说清楚。
最终，双方很容易陷入一种熟悉的拉扯：
客户认为供应商交付速度太慢；
供应商认为客户需求不断变化；
客户认为这些内容本来就应该包含在项目里；
供应商认为项目范围已经远远超出了最初约定。
FDE模式试图解决的，恰恰就是这个问题。
它把“理解业务、定义问题和快速验证”本身，也视为正式交付的一部分。
三、我们提供了FDE式服务，却经常按照功能清单收费
国内ToB项目最常见的合同方式，是列功能清单。
多少个页面、多少个模块、多少个接口、支持哪些权限、完成哪些部署。
项目验收时，再对着清单逐项确认。
这种方式的好处是边界看起来非常清晰。
但它有一个天然的问题：
它只能描述已知的功能，却很难为未知的问题定价。
企业真正希望得到的，通常不是某个按钮，也不是某张报表。
客户真正想要的是：
提高效率、降低成本、减少错误、缩短流程，或者让某项业务真正跑起来。
但结果很难直接写进功能清单。
于是，供应商只能把结果拆成功能，再按照功能报价。
客户买到的是功能，心里期待的却是结果。
这就形成了企业软件项目里最常见的错位：
供应商认为自己完成了合同；
客户却认为问题并没有真正解决。
在我过去做企业AI服务的过程中，也经常出现类似情况。
表面上，我们是在交付一套系统。
实际上，团队还在帮助客户梳理流程、验证场景、设计数据结构、培训员工、调整使用方式，甚至协助客户推动内部共识。
这些工作都很重要。
有时，它们对项目成功的影响甚至超过代码本身。
但在传统报价里，它们很容易被统称为“项目服务”，或者直接包含在开发费用中。
于是就出现了一个很矛盾的现象：
我们提供的是FDE式的深度服务，收取的却仍然是功能开发的钱。
客户也没有意识到，前期的探索、调研和业务梳理，本身就是有价值的交付。
他更容易产生的感觉是：
“我已经购买软件了，你理解我的业务，不是应该的吗？”
这并不是客户故意压价。
而是国内企业采购软件的习惯，本来就更擅长购买确定的功能，不擅长购买一段不确定的探索过程。
四、真正的企业项目，很少只由技术决定
FDE还有一个经常被忽略的作用：推动组织协作。
很多AI项目最后没有继续推进，并不是因为模型效果完全不行，也不是因为系统开发不出来。
真正的阻力，往往来自组织内部。
例如：
业务部门认为项目有价值，但没有独立预算；
技术部门愿意支持，却不愿意承担业务效果责任；
管理层认可方向，但没有明确谁来负责；
项目试点效果不错，却没有人能够决定下一阶段如何采购；
系统已经上线，但原有流程和考核方式没有改变，一线人员缺乏使用动力。
在这种情况下，单纯提高模型准确率，并不能解决问题。
供应商需要帮助客户回答：
这个项目到底归谁负责？
谁提供资源？
谁验收效果？
谁承担风险？
谁决定继续还是停止？
这也是为什么，一名优秀的FDE不能只会写代码。
他需要理解企业内部的决策结构。
需要知道，不同角色真正关心的是什么。
和业务人员沟通时，要讨论流程和效果；
和IT人员沟通时，要讨论安全、架构和稳定性；
和管理层沟通时，要讨论成本、收益和风险；
和一线使用者沟通时，要讨论系统是否真的好用。
很多企业项目最终卡住，并不是技术上不能Go。
而是组织上没有形成一个真正的Go。
五、FDE在国内，很容易变成“免费售前加高级外包”
FDE听起来是一种高价值岗位。
但放进国内的ToB项目环境里，它很容易变形。
项目签约前，供应商需要免费帮助客户梳理需求、设计方案、制作原型，证明自己懂业务。
项目签约后，供应商又需要派最有经验的人参与访谈、设计架构、处理复杂问题。
项目推进过程中，还要持续协调业务、IT、采购和管理层。
但客户最终支付的，可能仍然只是几个功能模块的开发费用。
最后，FDE就变成了三种角色的叠加：
免费售前、高级外包和项目无限责任人。
售前阶段，他负责帮助客户把问题想清楚。
开发阶段，他负责把系统做出来。
交付阶段，他负责让客户真正用起来。
只要项目没有达到预期，他就需要继续协调和优化。
但项目利润未必能够覆盖这种投入。
这也是FDE模式在国内难以直接复制的原因之一。
不是中国企业不需要深度服务。
恰恰相反，很多企业非常需要有人帮助他们理解AI、识别场景，并把技术嵌入业务。
问题在于，这部分价值还没有形成成熟的采购方式。
客户愿意为软件付费，愿意为功能付费，也愿意为硬件和云资源付费。
但让客户为“先花一段时间搞清楚问题”单独付费，仍然很难。
因为探索阶段不能保证一定成功。
而很多采购流程天然排斥不确定性。
六、真正能做好FDE的人，本身就非常稀缺
FDE需要同时具备三类能力。
第一类是技术能力。
他需要理解系统架构、数据、模型、接口和工程实现。
不一定要亲自完成所有开发，但必须能够判断一个方案能否真正落地。
第二类是业务能力。
他需要快速理解一个陌生行业的工作流程、角色关系、关键指标和异常情况。
不仅听客户说什么，还要判断客户没有说出来的问题是什么。
第三类是沟通和推动能力。
他既要能和一线使用者建立信任，也要能和技术团队讨论细节，还要能向管理层解释业务价值。
这三种能力集中在同一个人身上，本来就很少见。
国内传统的人才培养路径又往往是分开的。
技术人员长期面对代码和系统，缺少客户现场经验。
咨询人员擅长业务分析，却未必能把方案真正做成产品。
销售人员擅长推动合作，但很难判断技术边界。
真正能够从业务问题一路走到系统上线的人，往往已经接近一个小型团队的负责人。
但现实中，客户又经常要求：
供应商必须派最有经验的人参与。
问题是，有经验的人成本很高，而传统项目的利润又很有限。
最后，很多公司的做法只能是：
核心人员负责前期方案和关键节点，年轻员工负责日常执行，核心人员再不断介入救火。
项目越多，少数核心人员越忙。
公司看起来拥有很多客户，实际上所有交付都压在几个人身上。
这种模式很难规模化。
七、FDE不能只是一个“超级员工”
做了多个企业项目之后，我越来越确定一件事：
真正可持续的FDE模式，不能依赖某一个人特别聪明、特别努力、特别能扛事。
如果每一个客户都要重新访谈、重新设计、重新开发，所有经验都只存在于项目人员的脑子里，那么项目做得越多，公司反而越累。
真正的FDE背后，必须有一套可以复用的基础设施。
包括通用的数据接入能力、权限体系、知识库能力、模型调用框架、评测工具、工作流组件和实施方法。
前线工程师负责理解客户的特殊问题。
后方产品团队负责沉淀共性能力。
一个项目中验证过的方法，应该能够进入公司的产品和知识库。
下一次面对类似场景时，不再从零开始。
因此，我现在判断一个企业定制项目是否值得长期做，会看一个很重要的指标：
项目结束之后，公司除了收入，还留下了什么？
有没有留下可复用的组件？
有没有形成更成熟的行业认知？
有没有验证出一个可以标准化的场景？
有没有沉淀出后续客户能够直接使用的产品能力？
如果每个项目都是完全独立的代码，所有需求都只能服务一家客户，项目结束后团队只剩下疲惫，那么这不是FDE。
只是复杂程度更高的定制外包。
FDE的价值，不只是解决一个客户的问题。
更重要的是：
通过解决真实客户的问题，让产品逐渐逼近整个行业的真实需求。
八、我开始重新设计企业AI项目的交付方式
理解FDE之后，我开始重新思考企业AI项目应该怎么卖。
过去，客户提出需求后，我们很容易直接进入报价：
要做哪些功能？
需要多少人天？
多长时间上线？
现在我更倾向于先把项目拆成几个阶段：
业务探索、原型验证、系统建设和持续运营。
业务探索阶段，不急着承诺完整系统。
先梳理业务流程、关键角色、现有数据、使用场景和成功指标。
最终交付的，也不只是几次会议记录。
而是场景优先级、解决方案、原型、风险清单和实施路线。
这个阶段的价值，是帮助客户避免一开始就建设错误的系统。
原型验证阶段，也需要明确停止条件。
哪些指标达到之后继续？
哪些条件不满足时暂停？
需要客户投入哪些数据、人员和时间？
不能因为AI还可以“再优化一下”，项目就无限期延长。
系统建设阶段，则要把范围、变更机制和双方责任写清楚。
合同不能只写供应商要做什么。
也要写客户需要提供什么。
例如明确业务负责人、技术负责人、验收标准、数据条件、反馈周期和决策机制。
持续运营阶段，则需要关注真实使用情况，而不是系统上线之后项目就结束。
用户是否真的在使用？
哪些功能使用频率最高？
模型在哪些场景经常出错？
业务流程是否因此发生了变化？
只有这些问题被持续回答，AI系统才可能真正产生价值。
九、AI时代，写代码会越来越便宜，搞清楚问题会越来越贵
过去，企业软件最贵的部分往往是开发。
今天，随着大模型和AI编程工具的发展，从需求到代码的距离正在快速缩短。
页面、接口、基础功能和原型的开发成本，都可能持续下降。
但这并不意味着企业服务会变得越来越简单。
恰恰相反。
代码越容易生成，真正困难的问题越会暴露出来：
需求是不是对的？
场景是否真的值得做？
数据是否可用？
效果应该如何评价？
系统怎样嵌入原有流程？
员工为什么愿意改变工作方式？
项目产生的价值如何衡量？
这些问题，无法仅靠一个更强的模型自动解决。
它们需要有人真正进入业务现场。
理解客户说出来的问题，也理解客户没有说出来的问题。
再把业务、数据、技术和组织之间的复杂关系，转化成一套可以执行的方案。
这才是FDE真正稀缺的地方。
十、FDE不是一个岗位名称，而是一整套商业模式
现在很多公司开始招聘FDE。
但我认为，仅仅把解决方案工程师、售前工程师或者交付工程师改名为FDE，并不会自动拥有FDE能力。
FDE背后至少需要几件事情同时成立。
客户愿意为探索和问题定义付费。
供应商有足够的平台和产品能力，支撑前线快速搭建方案。
项目合同不再只围绕功能清单，而是围绕阶段成果和业务目标。
前线人员拥有足够权限，可以调动产品、研发和交付资源。
公司也有能力把一个客户中验证过的能力，沉淀到通用产品中。
缺少这些条件，FDE很容易成为一个听起来很高级，实际却承担所有杂事的岗位。
所以，FDE不是多招几个既懂技术又懂业务的人就可以复制。
它要求企业重新设计收费方式、合同结构、产品架构、人才体系和客户合作机制。
结语
过去两年做企业AI服务，我最大的感受是：
客户真正缺少的，往往不是一个更强的模型，也不是更多功能。
客户缺少的是，有人能够和他一起搞清楚：
什么问题值得解决，什么场景可以落地，技术应该如何进入业务，以及项目怎样才能真正产生结果。
这正是FDE存在的意义。
但我们也必须承认，这种价值不能永远隐藏在免费售前、低价开发和无限交付里。
如果供应商不为探索定价，不为不确定性设定边界，不把项目经验沉淀成产品，那么所谓FDE，最后只会变成更加辛苦的外包。
我现在越来越相信：
AI时代，代码本身会越来越便宜，但理解一个企业真正的问题，并推动它被解决，会越来越贵。
未来企业服务真正的竞争力，也许不是谁能够更快写出一套系统。
而是谁能够走进客户的业务，找到真正的问题，用技术把它解决，并把一次项目的经验，变成下一次可以复用的能力。
这可能才是FDE最值得我们学习的地方。
关注我，带你一起玩转AI！如果你觉得我分享的内容对你有帮助，麻烦点赞、分享、在看，你的支持是我创作的最大动力！