本文来自微信公众号： HavenlonLabs ，作者：Havenlon Labs，原文标题：《现实不是 API：FDE 走红背后的软件经济学转向》
过去几十年，软件工业几乎建立在一个稳定到不必言说的商业信念之上：最好的软件，是能够被无限复制的软件。一家公司投入几百名工程师完成一套产品，再把同一套代码交付给一万家、十万家甚至上百万家客户。第一份代码的生产极其昂贵，第二份的复制却几乎免费，软件因此天然拥有制造业难以企及的边际成本结构。从操作系统到数据库，从ERP到SaaS，从云计算到移动互联网，整个产业其实一直在回答同一个问题——如何让一份软件服务更多的人。这套逻辑可以被概括为一个时代的命题：Scale Software。
在这套命题之下，软件公司不断抽象需求、标准化流程、封装复杂性，把千差万别的客户问题压缩成有限的产品能力。客户越不需要工程师介入，产品看上去越成熟；部署越标准化，商业模型看上去越漂亮；服务收入越少、软件收入占比越高，公司的规模化能力似乎就越强。
但在AI时代，一个看起来逆潮流的职业却重新走到台前：Forward Deployed Engineer，FDE。这些工程师并没有远离客户，恰恰相反，他们进入客户现场，理解业务流程、数据结构、组织关系和真实约束，把模型、Agent与软件系统真正嵌进业务。Palantir很早就把Forward Deployed Engineering当作自己的产品开发方式，并在官方文档中把它形容为软件公司的"human equivalent of backpropagation"：让工程师尽可能靠近真实问题，同时与核心工程团队保持协同，持续把现场反馈综合成新的产品能力。今天，这种曾被视为Palantir特殊组织形态的做法，正在扩散成整个行业的共同选择——2026年5月，OpenAI成立了专门的部署公司，把派驻FDE进入企业作为主要业务形态；两个多月后，TechCrunch干脆把FDE称作AI行业最新的人才执念。
表面上，这只是一个岗位变热了。但如果只把FDE理解成一种新的工程师职业，我们大概会低估它真正表达的东西。FDE的出现，或许意味着软件产业正在从Scale Software，走向Scale Reality。
一、软件工业过去四十年一直在努力逃离“具体”
软件最伟大的能力之一是抽象。现实世界是具体而混乱的：每家公司都有自己的组织结构，每个行业都有自己的规则，每套业务都背着历史遗留的包袱。软件工程真正的力量，在于把这些具体不断压缩，最终变成数据库、流程引擎、权限模型、API与标准化产品。
某种意义上，软件公司四十年来一直在做同一件事：消灭差异。十家公司有十种采购流程，ERP希望把它们收敛成几种Workflow；一百家公司有一百种客户管理方式，CRM尝试把它们统一抽象为Lead、Opportunity和Account；数百万开发者拥有各不相同的基础设施，Cloud则把这些差异重新封装成Compute、Storage与Network。这套机制推动了软件工业史无前例的规模化，原因也很朴素：只有当现实能够被抽象，软件才能够被复制。
于是在很长一段时间里，判断一个软件产品是否优秀的重要标准，就是它能否减少特殊情况。特殊需求意味着定制开发，定制开发意味着工程师投入，而工程师投入意味着边际成本。这也是SaaS时代如此推崇标准化的根本原因：理想状态是产品一次构建、反复售卖，客户自己注册、自己配置、自己使用，实施越来越轻，工程师永远留在产品团队。在传统软件经济学里，人的介入几乎等同于规模化的失败。
因此，一个极其重要却很少被明说的产业信仰逐渐成型：现实应该适应软件，而不是软件不断适应现实。只要软件公司足够强大，它甚至拥有改写客户流程的能力。“最佳实践”之所以成为一个如此重要的商业词汇，是因为它真正表达的意思是——不要告诉我你过去怎么工作，请按照我们的系统重新工作。
这在标准化时代高度有效。但AI正在让这条逻辑出现裂缝，而裂缝首先出现在成本结构上。
二、AI降低了生产软件的成本，却没有降低现实的复杂度
生成式AI最直接改变的一件事，是软件的生产成本。写一个页面更快了，生成一个API更快了，搭建Workflow更快了，从模型调用、数据处理、Agent编排到完整应用原型，速度都在显著提升。软件正变得越来越容易被制造。
但随之出现的问题很容易被忽略：代码变便宜了，现实并没有。一家银行的核心困难不是缺少一个Agent，一家制造企业的真正障碍也不是没有大模型。医院、保险公司、政府机构、能源集团乃至一家物流公司的问题，往往藏在大量难以标准化的约束里——数据究竟在哪里，谁拥有决定权，哪个系统才是Source of Truth，冲突时听谁的，什么动作允许自动执行，什么动作必须人工确认，出了事故由谁负责，旧系统能不能改，以及最难的一层：组织是否愿意改变原有的责任结构。这些问题不会因为模型智能提升而自动消失；当AI从"回答问题"走向"执行任务"，它们反而变得更加尖锐。
一次成本迁移正在发生：过去最昂贵的是制造能力，未来越来越昂贵的，可能是把能力正确地嵌入现实。过去一个新功能需要几十名工程师投入半年，软件公司因此必须极度克制定制冲动；今天，一个强大的模型、一套成熟的平台，加上一名真正理解业务与工程的FDE，也许就能迅速构造出过去需要完整项目团队才能完成的方案。AI因此产生了一个看似矛盾的效果：技术越容易标准化生产，工程师反而越有能力深入非标准化的现实。
这大概才是FDE重新变得重要的根本原因。TechCrunch在2026年那篇报道里，多位从业者给出的共同背景并不是企业拿不到模型，而是企业开始从"购买AI"进入"让AI真正创造业务结果"的阶段。换句话说，市场正在从Capability Competition进入Deployment Competition。模型能力仍然重要，但越来越多企业真正要解决的问题变成了一句话：How do we make it work here？其中最难的词不是Work，而是Here。
三、Reality Is Not an API
互联网时代给了工程师一种强大的世界观：几乎任何东西最终都可以成为API。支付有API，地图有API，身份有API，存储有API，模型也有API。只要接口足够清晰，一个系统就能在完全不了解内部复杂性的情况下调用另一个系统。这是软件世界最了不起的抽象之一，也是"Here"这个词长期被低估的原因。
但企业真实运行的世界并不完全服从这套语法。一个字段为什么长期为空，可能需要去问十年前设计这套系统的人；一个审批节点为什么存在，可能源于三年前的一次事故；某位管理员理论上拥有权限，实际上却从来不被允许真正使用；一条流程写着六个步骤，员工每天绕过其中两个；数据库里的状态看起来是最终结论，业务人员真正相信的却是一张Excel。这些东西共同构成了一家公司真实的运行方式，它们不一定写在Documentation里，更不会出现在API Schema中。
Reality is not an API。
现实不是一组等待软件读取的结构化参数，而是制度、历史、利益、责任、人、流程、例外与风险共同形成的状态。传统软件尚可以通过标准化绕开其中一部分复杂性，Agent却不行。因为一旦软件开始自主行动，它就不再只是Information System，而开始成为Operational System，而Operational System必须进入真实的因果链条——它的每一个动作都会落在某个人的责任范围之内。
于是一个新问题浮现：模型理解了任务，并不等于系统理解了现实。FDE承担的，恰恰是这一层工作。他既不是传统售前，也不是普通实施，更不只是软件工程师，他真正在做的是一种反复进行的翻译：
Business Reality↓Operational Problem↓Technical Representation↓AI/Software System↓Production↓Real-world Feedback
翻译的终点不是交付，而是把最后产生的反馈重新送回产品。机器学习通过Loss修正模型，FDE通过现实修正产品——这也是Palantir那个"人类版反向传播"的比喻真正指向的地方。而一旦反馈成为主线，FDE改变的就不再是交付方式，而是产品本身的形成方式。
四、FDE真正改变的不是交付，而是产品形成方式
如果只是帮客户把系统装好，FDE并不新鲜。软件行业几十年前就有Implementation Engineer、Solutions Architect、Professional Services和技术顾问。FDE值得关注的地方在于，他的反馈不应停留在交付层，而必须回到产品本身。
传统软件组织的链条通常是Product→Sales→Customer：产品先被定义，再被卖给客户；客户提出特殊需求后，要么进入Feature Request队列，要么由服务团队完成定制。产品与现实之间存在一条清晰的边界，边界之外的东西被系统性地归类为"例外"。Forward Deployed Engineering的理想结构则更像一个闭环——产品进入现实，现实由FDE转译为反馈，反馈进入核心工程，再重新塑造产品。
因此FDE最大的价值并不是帮客户解决了多少问题，而是帮助产品发现自己原来理解错了什么。这个区别至关重要。普通实施是在既有产品边界之内完成交付，优秀的FDE则不断逼问一个更难堪的问题：为什么这里必须定制？如果只是这一个客户奇怪，那么它或许永远只能是定制；但如果第二个、第三个、第五个客户都撞上同类问题，那么所谓的特殊情况可能一点都不特殊，只是产品原有的抽象错了。现场问题由此开始转化为平台能力。
这背后是一种颇为不同的产品哲学：不要过早地消灭差异，而应该先理解差异为什么存在。真正优秀的平台，也许不是拥有最少定制的平台，而是具备一种能力——不断把有价值的定制重新吸收为标准能力。于是产品的进化路径变成：
Specific Reality→Specific Solution→Repeated Pattern→Abstraction→Platform Capability
这就是Scale Reality的第一层含义：不是把同一套软件强行复制到更多现实，而是建立一个能够持续理解不同现实、吸收不同现实，并最终重新形成抽象的系统。这样的系统一旦成立，它挑战的就不只是产品方法论，而是软件行业长期奉行的那套财务信条。
五、这可能正在动摇SaaS最核心的一条商业教条
资本市场过去非常偏爱Pure Software，理由写在毛利率里。Professional Services则被认为不够性感：客户越需要工程师，公司越像咨询公司；项目越依赖人，收入越难Scale。于是过去二十年的SaaS公司一直在努力减少人的介入，把服务收入压到财报中尽可能小的一角。
AI可能正在改变这条经济曲线，原因并不复杂。如果一名工程师的生产力因为AI提升数倍甚至一个数量级，那么过去昂贵到不可接受的定制工作，就开始落入软件公司能够承担的成本区间。过去需要十名工程师投入六个月的事情，未来也许变成一名FDE、一套平台加上AI，在三周内完成。这不是简单的效率提升，而是商业模式边界的位移：一旦定制的边际成本足够低，"服务"与"产品"之间那条曾经泾渭分明的线就开始模糊。
这也解释了为什么2026年多家前沿模型公司几乎同时把部署做成了独立业务。OpenAI在5月成立部署公司，明确把派驻FDE进入企业作为核心服务形态，并收购了一家已有FDE团队的应用型工程公司以获得现成的现场能力。这类动作在旧的SaaS估值语言里几乎是自伤毛利，但在新的成本结构下，它更像是在购买另一种资产。
一家AI公司完全可以同时拥有高度标准化的平台和极度深入现场的FDE：前者负责Scale Software，后者负责Scale Reality。二者并不矛盾，甚至互相加强。
AI越是降低软件的生产成本，软件公司就越有能力承担现实的复杂性。
这同时解释了另一个看似奇怪的现象：为什么自动化越强，我们反而看到更多"人深入客户现场"的组织安排？因为自动化并没有消灭复杂性，它只是改变了复杂性最昂贵的位置。复杂性正在从Production转向Integration，从Coding转向Context，从Software转向Reality。而复杂性搬家之后，稀缺的能力也随之换了地方。
六、真正稀缺的能力正在从“会不会做”变成“知不知道应该做什么”
工业时代最稀缺的是制造能力，软件时代很长一段时间最稀缺的是编程能力，工程师的价值因此集中体现为一个问题：Can you build it？
当模型越来越擅长生成代码、构建界面、连接API、分析数据之后，一个更古老的问题重新浮现：What should be built？以及更困难的一层：What can actually work here？这两个问题无法完全交给模型回答。因为一个技术方案是否正确，不只取决于逻辑是否成立，还取决于它是否嵌入了真实的组织结构、权力关系、风险边界与业务目标——而这些恰恰是最不容易被写进Prompt的部分。
于是工程师的价值开始向另一端移动。未来最昂贵的工程师，未必是能写最多代码的人，而更可能是那种能够走进一个陌生行业，在极短时间内判断出什么是真问题、什么是假需求，什么不能改变、什么必须改变，哪里值得自动化、哪里绝不能自动化，什么应该进入产品、什么只应该留在这一个客户身上的人。这是一种很难通过Job Description完整描述的能力：它既要求工程能力，也要求产品判断；既要求抽象能力，也要求尊重具体；既要理解技术边界，也要理解现实中的责任归属。
这也是FDE最困难的地方。他必须同时拥有两种看起来彼此冲突的能力：进入现实，又不被现实绑架。只懂抽象的人容易制造出漂亮却无法落地的错误产品，只懂具体的人则容易退化为永远无法复用的项目工程师。真正优秀的FDE必须站在两者之间。
看见具体，但寻找结构；接受例外，但寻找规律；解决今天的问题，同时寻找明天能够复用的抽象。
这种张力本身，就是新范式的形状。
七、从Scale Software到Scale Reality
因此，FDE背后真正值得讨论的不是一个岗位，而是一种正在成型的商业范式变化。
Scale Software解决的问题是：如何让同一套能力服务更多客户。Scale Reality试图解决的则是另一个更困难的问题：如何让技术持续进入不同的现实，同时不失去规模化能力。两者的内在逻辑几乎相反——Scale Software追求减少Variance，Scale Reality必须接受Variance；Scale Software希望Reality Adapt to Product，Scale Reality则要求Product Learn from Reality。
更关键的差别在资产形态上。Scale Software的核心资产是Code，Scale Reality的核心资产可能逐渐变成被现实验证过的结构。一家未来真正优秀的AI公司，最重要的资产也许不只是模型、代码或数据，而是它究竟经历过多少种真实世界：见过多少家银行、多少座工厂、多少所医院，处理过多少异常、多少失败、多少组织冲突，遭遇过多少在实验室里不可能提前设计出来的边界情况。
这意味着，每进入一个新的现实，公司获得的不只是一笔收入，还有一次训练。客户由此成为产品进化的一部分，而不再只是产品的接收端。
模型通过数据学习，公司通过现实学习。
这大概才是"人类版反向传播"最深层的商业含义。也正因为如此，评估一家AI公司的问题需要被重新提问一次。
八、未来真正难规模化的，可能不是软件，而是现实
过去的软件创业公司经常被问：这个产品能不能Scale？这仍然是一个重要问题。但AI时代或许需要追加另一个问题：这家公司理解现实的能力能不能Scale？
两种失败方式都很清晰。如果每进入一家新客户都必须重做一个项目，那么它不是平台，只是一家被冠以软件之名的项目公司；如果完全拒绝理解客户之间的差异，它又可能永远停留在POC，无法真正进入生产环境。真正困难的是在两者之间建立一套机制：既深入现实，又不断抽象现实；既接受定制，又持续消灭重复定制；既给现场工程师足够大的自由度，又让现场经验稳定地沉淀回核心平台。这可能是未来AI公司组织设计中最重要的问题之一。
FDE只是今天出现的一个答案。几年之后，这个职位可能改名，也可能被更多Agent部分接管——Palantir已经推出了AI FDE，让Agent通过自然语言指令代为执行Foundry上的操作，并在用户既有权限范围内工作。但工具的更替不会让背后的问题消失；恰恰相反，它会让那个问题越来越清晰。
当制造智能越来越容易，谁负责让智能正确地进入现实？
过去四十年，软件工业最伟大的能力，是把复杂世界抽象成软件。未来二十年，一个同样重要的能力或许是：让软件重新学会尊重复杂世界。因为模型可以Scale，Compute可以Scale，代码正在越来越容易Scale，真正不会自动Scale的，是现实本身。
所以FDE的流行，也许并不意味着软件工业退回了"人力服务"。它更像是在提醒整个行业：我们已经非常擅长Scale Software，而下一场真正困难的战争，是Scale Reality。