从卖盒子到卖结果：IT 交付模式的四次变迁与 FDE 的由来

满配盒子，只用20%功能：一名老售前亲历的交付模式变迁

FDE 实战手记 · 第 2 篇

先交代一下背景。前段时间我连发了三篇文章,讲的是同一件事:Agent 正在改变安全的隐含假设——过去整个安全体系默认「操作者是人」,而当 Agent 成为系统里的操作主体,速度、路径、权限的假设全变了,安全工作的模型和基础都需要重估。

这三篇文章，其实都在说同一件事：Agent 正在动摇安全领域长期默认的前提。

过去一整套安全体系，底层都有一个共识 —— 操作者是人。一旦 Agent 变成系统里实际动手的主体，速度、访问路径、权限边界这些前提全都不再成立；安全模型，乃至整套工作的根基，都得重新掂量。

那三篇写完,有一个判断在我脑子里越来越清晰: 相当一部分新型安全难题,已经没法指望某个外部厂商的标准产品来解决了。Agent 带来的是动态的安全问题,需要的是整合、集成、并且紧密嵌入到系统设计之中的方法——这类能力本质是「长在客户系统里」的,不是「装在客户机房里」的。

顺着这个逻辑往下说，就能引出我这篇要聊的核心: 光靠标准化产品远远不够，还需要一个新的岗位根据用户的需求,重新定义产品的交付形式。这个角色有个现成的名字:FDE。这个词是 Palantir 最早提出的;而今天各大模型厂商争相组建 FDE 团队(系列第一篇里摆过各家的钱和编制),追到根上,原因只有一个:产品的交付,与用户的期望之间,存在巨大的鸿沟。

所以这个系列不打算争论「什么才是正宗的 FDE」。我只关注最原始的那个核心:用户的业务诉求,到底如何被完成。

这一篇先讲一段我自己的经历——你会看到,这条鸿沟不是 AI 时代才出现的,它至少存在了二十年。从我的老本行讲起:负载均衡。

一、一个二十年没解决好的需求

早年我在一家硬件厂商工作,做的是负载均衡方向。这类设备的用户要求,从来就三样:可观测、可视化、高可用。设备本身做得足够硬,流量再大也扛得住;但说来惭愧,界面和图形一直都非常糟糕——用户想看的那张「一眼看清全局」的图,产品里始终没有。

用户想自定义监控视图怎么办?系统只提供了一套编程接口。接口能力是完整的,理论上什么都能做;但基于它做开发是一件非常复杂的事——起码对于大多数售前来说,基本没有动手的可能性。会讲方案、会调设备、懂客户业务,这些都没用,中间隔着完整的软件工程开发链路，完全跨不过去。有个客户现场场景我到现在还记得清清楚楚:客户在会议室白板上画出他想要的那张图——全局链路、每台设备的健康度、业务级别的成功率,画完回头问我:「能做吗?」我只能回答:能力都在,接口也有,但这张图,做不出来。那种「需求就站在面前,你却够不着」的感觉,做过售前的人应该都懂。

于是需求走进一个死循环:用户提出想看什么 → 售前理解、整理、翻译成需求文档 → 反馈给研发 → 研发去调研、排期、开发、测试 → 一条长长的流程走下来,常常一年半载 → 交付出来的东西,很可能和用户当初想要的已经对不上了。多设备的统一管理、上下游的统一视图,这些呼声最高的需求,在需求池里一躺就是几年。

不是谁不努力。用户没说错,售前没翻译错,研发也没偷懒——是那个年代的交付结构,只允许需求走这一条路。

二、盒子时代的 20/80

卖盒子的年代还有个公开的秘密:单个用户真正用到的功能,往往也就 20%;剩下的 80%,是历年来其他客户的需求沉淀在产品里的结果。但盒子是一体的,客户不得不为 100% 买单,同时被迫承载大量无关模块。管理界面堆满和自身业务无关的功能入口，真正刚需的定制视图反倒长期缺失。

这也不是厂商偷懒。在「功能只能长在盒子里」的年代,这是控制研发成本的唯一做法:把所有客户的需求汇集起来,挑公约数做进下一个版本,成本摊给所有人。代价是产品越做越厚,单个客户的贴合度越来越差。20/80 不是bug,是那种交付模式的必然结果。

三、拉长时间线看过去三十年:交付模式的****4种模式

负载均衡只是缩影。把镜头拉远看设备行业这三十年,大部分的IT产品交付模式大致走过了4种模式:

第一种,卖盒子。价值在硬件里,现场人员是「成本」——装完调完就该撤了。

第二种,卖方案。单个盒子不够用了,价值开始向「组合」转移:集成、定制、联调,懂多个产品的人开始值钱。

第三种卖订阅。云和 SaaS 把一次性买卖变成了持续续费,「客户成功」这个岗位诞生——不让客户用起来,明年就没有收入。

第四种,卖结果。AI 时代,客户买的不再是能力,是业务结果。这一站的岗位名字,就是系列第一篇讲的 FDE。交付业务成果，也就是 AI 当下的新阶段。客户采购的核心是可量化的业务价值，对应这个阶段的岗位，就是我第一篇重点拆解的 FDE。

四站走下来有一条不变的规律: 技术人员距离客户真实业务越近，自身岗位价值就越高。第一篇里巨头们砸的钱、给的编制, 本质就是押注第四代 “交付业务结果” 的 FDE 。

四、同一个需求,放到今天

再回头聊聊当年那张客户想要的监控大盘，如果放到今天,事情就简单多了。

FDE 坐在客户旁边,把要监控的指标、想看的图表、告警的口径当场讨论清楚,然后用 AI 编程工具, 短则当天、慢则三五天就能交出一个能跑的原型——接真数据、出真图表,用户现场实操看,不满意当场改。再也不用走调研、排期、开发、测试那套漫长内部流程。

多设备管理、上下游统一视图这些当年一躺几年的需求,今天起码 MVP 不会那么复杂了。用户和厂商可以快速协商出想要的内容:先做一个能看的,再讨论对不对——「做出来再对齐」的成本,第一次低过了传统 “先写全量需求文档再开发”成本。这是整套交付底层架构的根本性变革，绝非单纯开发工具升级。

图 4|同一个监控需求,当年 vs 今天

当年客户在白板上画的那张图——全局链路、设备健康度、业务成功率——放在今天, 只需要半天到几天就能产出完整原型。二十年前够不着的东西,现在只是 FDE 日常交付里基础的前置工作。

五、盒子的下一站:变成工具集

再往前看一步,我的判断是:这些盒子,将来大概率会变成一个个工具集。

设备的能力通过接口暴露出来——即可选用MCP(2024 年底发布的一种开放协议,让 AI 模型能标准化地调用外部工具),也可以是其他形式的 API——直接供大模型自主调用。FDE 通过模型来管理和控制这些设备:初期从监控、告警这类只读场景做起,风险低、见效快;再逐步走向配置下发和多设备联动。当然,只读好说,写操作是另一回事——权限、审计、回滚,一样都不能少;这也是为什么这个转变一定从监控和告警起步,而不是一步到位。

到那一步,20/80 的逻辑就被改写了:用户不再被迫接受一整个盒子,而是按自己的业务,组合需要的那几个工具。而「组合」这件事,恰恰需要一个懂业务、懂设备、又能指挥模型的人在现场。在这个转变过程中,FDE 的作用会被快速放大——紧贴真实业务场景，交付客户真正刚需的高价值功能模块。

六、售前的位置

聊到这里，可以回归我们售前从业者本身。售前岗位最核心的核心竞争力，是离用户的需求最近:在一次一次的沟通和交流里,快速理解并整理用户的需求。这个能力过去也值钱,但它的输出物是盒子的型号、解决方案的章节——需求翻译完,就移交内部团队，后续开发流程售前完全无法参与。

现在, 完全相同的需求拆解能力，输出物可以直接是一个可交付的 MVP。翻译完不用交出去了,自己就能把它变成能跑的东西。能力没变,输出物变了,价值就完全不是一个量级。

这也就部分回答了第一篇留下的第二个问题(哪些技能在增值,哪些在贬值)。结合我多年一线交付观察：把客户模糊、碎片化的业务诉求梳理成清晰、可落地实施方案的能力,正在快速增值;单纯「知道某台盒子有哪些参数」这类信息,贬值得最快。前者 AI 替代不了——它恰恰是 AI 的输入;后者 AI 一秒钟就能查到。

看到这里你可能会问:像我们这样一直深耕某个专业方向的人——安全、网络、存储、数据——将来做的,会是硅谷定义的那种什么都管的 FDE 吗?我认为不是。下一篇讲一个我最近想清楚的概念:领域型 FDE——以专业技术领域为边界、以产品能力为底座的 FDE 形态。它绝非通用 FDE 的简化低配版本，反而更适合我们这批深耕行业多年技术人的长期职业发展路径。我在研究这件事,也在做这件事。慢慢写,欢迎同行来聊。

引用与参考来源

1. MCP(Model Context Protocol):Anthropic 于 2024 年 11 月发布的开放协议,现为行业通用标准,modelcontextprotocol.io;

2. Amazon,《AWS invests $1 billion in forward deployed engineers》, about .amazon.com,2026-06-30;

3. 第一篇《巨头们正在为同一个岗位砸重金:FDE 到底是什么》文末的完整来源清单(FDE 岗位与投入数据);

4. 文中负载均衡行业场景为个人从业经历回顾,仅代表个人观察,不涉及任何具体客户信息;