跳转至

第 2 章 为什么需要 FDE

第 2 章 为什么需要 FDE

Note

本章导读：从"是什么"进到"为什么"。本章用经济学视角论证 FDE 的必要性——传统项目制为何陷入"死亡螺旋"、四种交付模式如何对比、FDE 靠"经验曲线/能力回注飞轮"如何实现边际成本递减，并用 Palantir 的真实财务数据（毛利率、净利率、NRR）验证这套逻辑。 读完本章，你能用经验曲线和财务数据说明 FDE 为什么比传统项目制更赚钱，并用鉴别清单判断一家供应商是不是真 FDE。

2.1 传统交付模式的结构性困境

传统项目制交付往往陷入一种"死胡同"，在 To B/To G 行业尤为常见。

graph TD
    cust["客户定制需求多且分散"] --> rd["企业投入大量研发进行定制开发"]
    rd --> delivery["交付周期长，成本失控"]
    delivery --> loss["项目利润率(毛利)极低甚至亏损"]
    loss --> noRnd["无力投入核心平台研发"]
    noRnd --> compet["产品竞争力下降"]
    compet --> lowprice["只能靠低价和更深度的定制抢单"]
    lowprice --> cust

    style cust fill:#f5ece0,stroke:#a8895f
    style loss fill:#fdecea,stroke:#d94f4f
    style lowprice fill:#f5ece0,stroke:#a8895f
图 2-1：项目制交付陷入"需求分散→定制→亏损→无力投平台"的自我强化死亡螺旋

为什么这是"结构性"困境，而非"管理不善"？

很多陷入这个循环的公司，第一反应是"我们项目管得不够好"——于是加强 PMO、压缩工期、精细核算人天。但这些努力往往只能延缓、无法逆转下滑，因为问题不在执行层，而在结构层。逐环拆解这条螺旋，会发现每一步都是"局部理性、全局自杀"：

  1. 需求分散 → 定制开发：客户的需求真实且合理，销售为了签单必须接。局部看，接单是对的。
  2. 定制开发 → 周期长、成本失控：每个项目从头造轮子，没有可复用资产，成本随项目数线性甚至超线性增长。
  3. 成本失控 → 毛利极低甚至亏损：为了中标又不得不压价，利润被两头挤压。
  4. 无利润 → 无力投入平台研发：这是最致命的一环。没有利润，就没有钱投入到能"一次开发、多次复用"的核心平台上——而平台恰恰是唯一能打破线性成本的东西。
  5. 无平台 → 产品竞争力下降 → 只能靠更低价、更深度定制抢单：于是回到第 1 步，且每绕一圈，定制更重、毛利更薄、离平台更远。

Caution

死亡螺旋的残酷之处，在于它是"自我强化（self-reinforcing）"的。 越是缺钱，越不敢投平台；越不投平台，就越只能靠人力堆定制；越堆定制，就越缺钱。这是一个正反馈的恶性循环——单靠"更努力地做项目"永远走不出去，因为你越努力，螺旋转得越快。 唯一的出路是从结构上切断某一环：要么容忍短期亏损、强行投入平台（Palantir 的选择），要么改变交付模式本身。

一个典型的痛感场景（一线读者大概率似曾相识）：

团队刚交付完 A 客户的定制系统，B 客户来了几乎一样的需求，但因为 A 的代码写死了字段和流程，几乎无法复用，只能推倒重来。于是同一类问题，团队解决了两遍、收了两份人天钱、却没沉淀出任何资产。第三个类似客户来时，团队依然要从零开始。收入在增长，但公司什么都没积累下来——这就是项目制的本质陷阱：用规模换收入，却换不来资产。

而 FDE 模式则致力于把这条恶性螺旋反转为正向飞轮：在现场解决问题的同时，将定制代码提炼为通用组件；下一个类似项目复用这些组件，部署速度更快、成本更低；成本下降带来的利润，再投入研发更强大的平台——每绕一圈，成本更低、平台更强。

2.2 四种交付模式全景对比

要理解 FDE 模式的独特定位，最好的方式是把它放到四种主流交付模式的坐标系里对照。

维度 标准 SaaS 传统咨询 项目外包/定制开发 FDE + 平台模式
客户适配度 低（客户需改变流程适应软件） 高（定制化方案） 极高（完全按需开发） 高（平台底座 + 现场定制集成）
研发复用率 极高（100%同一套代码） 中（复用分析框架） 极低（每个项目从头造轮子） 高（70%平台 + 30%定制组件回注）
边际成本趋势 趋近于零 线性增加（依赖高级人头） 线性增加（依赖开发人头） 先高后低、经验曲线式递减（幂律递减，通过平台沉淀）
毛利率趋势 高且稳定（70%-90%） 稳定（40%-60%） 低且脆弱（10%-30%） 从低到高（项目级初期可为负；公司软件毛利率 2018 年约 50% 起步；成熟期 80%+）
商业模式 纯订阅制 咨询服务费 人天计费或固定项目费 高价值许可费（含平台授权与首期部署）

Note

上表行业毛利区间（SaaS 70–90%、咨询 40–60%、外包 10–30%）非精确统计或统一标准，对外引用时请注明"经验区间"。

如何读懂这张表：FDE 凭什么"既要又要"？

这张表最反直觉的一行是"客户适配度"与"研发复用率"——因为在传统认知里，这两者是天然矛盾的一对：

  • 标准 SaaS：一套代码服务所有客户，复用率 100%，但客户必须削足适履去适应软件（高复用、低适配）。
  • 项目外包：完全按客户需求定制，适配度极高，但每个项目从头造轮子，几乎零复用（高适配、低复用）。

绝大多数公司只能在这条对角线上二选一。而 FDE + 平台模式的全部精妙之处，就在于它试图同时拿到对角线的两端——用"平台底座（保复用）＋ 现场定制集成（保适配）"的分层结构破解这个矛盾：

  • 底层 70% 靠平台：数据引擎、本体层、通用组件是标准化的、跨客户复用的——这部分贡献了复用率。
  • 上层 30% 靠 FDE 现场定制：贴合每个客户的具体流程、数据、界面——这部分贡献了适配度。
  • 而且这 30% 不是白写的：其中的通用部分会被回注为平台能力，让下一个客户的"70% 平台"变成"75%、80%"——复用率本身是动态上升的。

Tip

一句话抓住四种模式的本质区别：

  • SaaS 卖的是"标准品"——边际成本趋零，但触达不了复杂痛点。

  • 咨询 卖的是"洞见"——交付 PPT 和方法论，但不落地为可运行系统。

  • 外包 卖的是"人天"——完全定制，但公司什么资产都沉淀不下来。

  • FDE + 平台 卖的是"被平台放大的解决方案"——用标准底座承载定制交付，再把定制反哺回底座。它是唯一一个"做得越多、平台越强、下一单越省"的模式，这也是为什么只有它的边际成本曲线是"经验曲线（幂律）式递减"而非"线性增加"。

（这四种模式在"卖什么"上的根本差异，正是第 1 章所辨析的"从卖人力到卖能力"。）

这张表的最后两行（边际成本趋势、毛利率趋势）指向同一个结论：FDE 模式初期看起来最像"低毛利的外包"，但它的成本结构从根子上就不同——成本是先高后低（越做越轻）、毛利率是先低后高。

正因如此，FDE 极易"退化"回外包——这是全书最重要的警示之一。

上表清晰地把外包和 FDE 分在了两列，但在真实的日常现场，两者几乎肉眼难辨：都是派工程师驻扎客户现场、都在写贴合客户的代码、都在解决客户的具体问题。差异不在"当下做什么"，而在"做完之后往哪走"——是把通用经验抽象、沉淀回平台（FDE），还是写完就留在客户那里（外包）。正因为这个差异是"隐性的、面向未来的"，它极易在两种现实压力下被悄悄侵蚀：

  1. 销售压力：为快速签单，销售倾向承诺"客户要什么我们做什么"，FDE 被迫在现场写死大量一次性代码，无暇抽象回注（这也是第 3 章强调 "FDE 不应汇报给销售" 的原因）。
  2. 交付压力：工期紧张时，"先把这个客户糊弄过去"永远比"多花 20% 时间把逻辑抽象成通用组件"更省事——于是回注被无限期推迟，FDE 事实上变成了外包。

Caution

一个自检信号：如果你的"FDE 团队"连续几个项目下来，平台能力毫无增长、每个新项目仍在重复造轮子、收入靠堆人头线性增长——那么无论它挂着什么头衔，它已经退化成了一支昂贵的外包队。 这正是第 1 章强调"永远不要用人头计费（Time & Material）衡量 FDE"的原因——人天计费会从考核机制上，把 FDE 一步步逼回外包的老路，掐断上表中那条本该越做越轻的成本曲线。

要真正理解这条"成本先高后低、越做越轻"的曲线（对应毛利率先低后高）为何成立、以及它背后的数学规律，就需要进入下一节的经济学原理。

2.3 FDE 的经济学原理

FDE 模式在经济学上遵循深刻的经验曲线效应（Experience Curve Effect）。 其公式表示为：

\[ C_n = C_1 \times n^{-\alpha} \]

其中：

  • \(C_n\)：交付第 \(n\) 个客户的部署成本
  • \(C_1\)：交付第 1 个客户的极高初始成本（此时 FDE 需要大量写非标代码）
  • \(n\)：累计客户交付数量
  • \(\alpha\)：学习率参数，由 FDE 团队将非标经验抽象回注给核心平台的速度决定。

把这个公式画成曲线，就能一眼看清 FDE 与传统外包的分野——同样是做项目，一个越做越省，一个越做越贵：

经验曲线：FDE 越做越省 vs 外包越做越贵

上图中，FDE 的成本随累计交付数 \(n\) 按 \(n^{-\alpha}\) 快速下坠（靛蓝凸降曲线），而传统外包因缺乏平台复用、每单从头再来，成本始终持平甚至因复杂度上升而抬头（琥珀上行曲线）。两条线之间不断张开的"剪刀差"，就是平台飞轮沉淀带来的成本红利——它随项目数增加而越拉越大（图中标注了第 1/5/10/20 个项目节点）。下面的数据表，正是这条曲线在几个关键节点上的具体展开：

边际成本递减效应示例：

项目次序 现场所需 FDE 人数 实施周期 核心平台覆盖度 现场定制代码量 项目级利润率（示意）
第 1 个项目 5 人 6 个月 40% 60% -20%（战略亏损）
第 5 个项目 3 人 3 个月 60% 40% +35%
第 10 个项目 1.5 人 1 个月 80% 20% +65%
第 20 个项目 1 人 2 周 95% 5% +85%

表图对照：上表四行与图中四个标注节点一一对应（第 1 个=高成本起步 → 第 20 个=个位数成本），读表时可回看图理解"成本下坠"的趋势；曲线与表格数值均为示意，非精确测量。

Note

上表为示意性的单项目核算（把 FDE 现场人力成本计入后，某个项目自身的盈亏）——它会随定制代码占比下降而由负转正，用来解释经验曲线的机理。这与 Palantir 公司整体毛利率（软件毛利率，通常不为负）是两个不同口径，请勿混淆：项目级利润会因重人力投入而为负，公司软件毛利率一般不会。

graph TD
    solve["FDE 解决客户非标痛点"] -->|提炼/解耦| abstract["业务抽象为通用能力"]
    abstract -->|合并到主分支| platform["核心平台(Foundry/AIP)升级"]
    platform -->|平台能力增强| reduce["降低下一个类似客户的交付成本"]
    reduce --> solve

    style solve fill:#dbe4f0,stroke:#3949ab,stroke-width:2px
    style platform fill:#e4efe4,stroke:#5b7a5b
图 2-2：FDE 经济学飞轮

飞轮如何从静止转起来：一个"先亏后赚"的加速过程

上面的公式和曲线揭示了一个反直觉的规律：FDE 模式的盈利能力不是一开始就有的，而是被"转"出来的。 理解飞轮的启动过程，是理解整个 FDE 经济学的关键。

  • 静止期（第 1-2 个项目）：飞轮最重，必须用力推。 此时平台还只有最通用的底层功能，没有沉淀任何行业解决方案，没有可复用的行业模块。因此第一批项目必然是高定制、高投入的——FDE 要在现场写大量非标代码（定制代码占比 60% 以上），交付慢、毛利为负。这不是执行失败，而是飞轮启动的物理必然：你必须先在泥泞里把路趟通一次，才谈得上把它修成公路。这几个"种子项目"当期是亏钱的，但它们真正的产出不是利润，而是行业 Know-how 与可被抽象的经验——这些才是喂养飞轮的燃料。

  • 加速期（第 3-10 个项目）：共性显现，飞轮开始自转。 当同一行业的第 3、4、5 个项目做下来，FDE 会发现"这段清洗逻辑、这个预警模型、这套本体结构"在客户间反复出现。此时把它们抽象、回注为平台组件（\(\alpha\) 学习率的体现），下一个同类项目的定制代码占比就降到 40%、20%……边际成本随之递减，毛利由负转正。

  • 飞轮期（第 20 个项目以后）：势能积累，越转越快。 平台已沉淀出成体系的行业方案，新项目大量复用既有资产，定制代码降至个位数百分比（示意表中第 20 个项目为 5%），单个 FDE 可并行支撑多个项目，毛利趋于 SaaS 水平。飞轮的重量没变，但它积累的动能已经让它自己转下去。

Important

启动期的判断逻辑：靠什么决定"接不接、做什么"？

既然启动期没有可复用模块，那"这个项目值不值得做"就不能用"平台复用度"来衡量——那是飞轮转起来之后（成熟期）才有意义的指标。启动期真正该看的，是 Palantir 官方在《Delivering a use case》中给出的结果导向（outcome-oriented）三要素：

  1. Outcome（期望结果）：这个项目最终能帮客户改善哪个运营决策、挂钩哪个核心 KPI？——先问结果，而非先问要建什么功能。这是价值的第一标尺，也决定客户的付费意愿。

  2. Data（数据可行性）：从期望结果倒推所需的数据实体，评估现有数据能否支撑这个结果。

  3. 痛点的行业普遍性：这个痛点在同行业其他客户中是否普遍存在？——注意，这是"痛点是否普遍"（可通过行业调研前瞻判断），而非"我方能否复用现成模块"（启动期无从谈起）。痛点越普遍，这个种子项目未来喂养飞轮的价值越大。

来源：Palantir Foundry 官方文档"Delivering a use case"，原文三要素为 Outcome / Data / Tools。此处结合 FDE 商业语境，将偏交付执行的 "Tools（平台工具选型）" 替换为更适合入场决策的 "痛点的行业普遍性"——Tools 层面的工具选型将在第三篇 Prototype/Build 阶段详述。

换言之：通用性是被"训练"出来的结果，不是入场时筛出来的前提。 Palantir 官方将 FDE 方法论比作"人肉反向传播"——平台的通用能力，正是靠一个个种子项目反复喂反馈，一轮轮收敛而成。这也解释了第 3 章"五次部署法则"的深意：共性要 5 个客户之后才真正清晰，过早标准化反而会把个例的偏见固化下来。

飞轮转起来之后：承接选择逻辑的反转

前面讨论的都是"飞轮如何启动"。但一个更深刻、也更常被忽略的问题是：当飞轮真正转起来、平台已经沉淀出成体系的行业方案之后，承接项目的选择逻辑会发生一次根本性的反转。

反转的根源，在于稀缺资源变了：

  • 启动期，最稀缺的是"行业 Know-how"——平台一无所有，所以要广撒种、赌通用性，判断点是 Outcome + Data + 痛点的行业普遍性（前瞻性地押注哪些赛道值得深耕）。
  • 成熟期，行业 Know-how 已不再稀缺（平台里全是），此时最稀缺的变成了顶尖 FDE 的交付带宽。于是承接选择的核心问题，从"这个项目值不值得亏钱做"，变成了"在有限的 FDE 带宽下，哪些项目能最大化复用飞轮红利、又不反噬平台"。

成熟期的承接判断，应从"结果导向"升级为"资产杠杆导向"，看以下四个点：

判断点 含义 启动期 vs 成熟期的差异
(a) 复用杠杆率（正向核心） 该项目能复用多少现成平台资产/行业组件？复用越高 → 边际成本越低 → 交付越快、毛利越高 "复用度"终于成为正当的入场指标——但它是成熟期指标，绝非启动期门槛（这正是启动期悖论的另一面）
(b) 战略延展性 项目落在已沉淀的成熟行业里（收割型），还是开辟一个新的、值得押注的赛道（再播种型）？ 成熟期要有意识区分两类：收割型用杠杆逻辑评估，再播种型回到启动期的种子逻辑评估
(c) 是否反噬平台（负向筛选） 高定制、极特殊、通用性极低的孤岛需求，接了会占用稀缺带宽、诱导平台为个例妥协、破坏架构一致性 这是成熟期特有、启动期没有的判断点——详见下方展开
(d) 人效贡献 该项目会拉高还是拉低团队人效（单个 FDE 可并行支撑的项目数）？ 考核从"能不能交付"转向"人效是否健康增长"

Important

成熟期最关键的能力，是对"能做但不该做"的项目说不（负向筛选）。

这是启动期与成熟期最深刻的一处反转，也是本节要讲透的重点：

  • 同一个高定制、通用性极低的孤岛需求，在启动期可能因为"痛点行业普遍、值得赌"而应该接（它是喂养飞轮的种子）；但在成熟期，如果它无法复用既有资产、又不通向新赛道，就应该坚决 Say No——哪怕团队完全有能力把它做出来。

  • 原因是成熟期的机会成本变了：一个顶尖 FDE 投入到一个"只此一家、别无分号"的孤岛需求上，意味着放弃了 N 个能复用飞轮、快速高毛利交付的项目。更危险的是，为了迁就这个孤岛需求，平台团队可能被诱导做出破坏通用性的妥协，反过来污染已经铺好的"铺装公路"。

  • 这与第 9 章"回注优先级矩阵"的判断完全同构：左下角（低通用 + 高成本）的需求坚决不做，留作一次性项目定制、绝不并入平台。承接选择与回注决策，在成熟期用的是同一把尺子。

一句话概括这次反转：启动期的智慧是"敢于为通用性亏钱"，成熟期的智慧是"敢于为通用性拒单"。 前者怕的是错过种子，后者怕的是稀释资产。一个健康的 FDE 组织，必须同时具备这两种看似矛盾的勇气，并清醒地知道自己当前处在飞轮的哪个阶段。

graph LR
    subgraph start["启动期：种子逻辑"]
        seedScarcity["稀缺=行业 Know-how"] --> sowSeed["广撒种 赌通用性"]
        sowSeed --> seedJudge["判断点：Outcome+Data<br/>+痛点行业普遍性"]
    end
    subgraph mature["成熟期：杠杆逻辑"]
        matureScarcity["稀缺=FDE 交付带宽"] --> harvest["精挑选 收割红利"]
        harvest --> reject["判断点：复用杠杆+战略延展<br/>+负向筛选反噬项目"]
    end
    start ==>|飞轮转起来<br/>约 5 个项目后| mature

    style sowSeed fill:#dbe4f0,stroke:#3949ab
    style harvest fill:#e4efe4,stroke:#5b7a5b
    style reject fill:#f5ece0,stroke:#a8895f
图 2-3：飞轮启动前后，项目承接选择逻辑的反转

Note

换个视角问到底：乙方为什么愿意做投入更重的 FDE 模式？

读到这里的读者大多默认"乙方案 FDE 理所当然"。但一个诚实的经营者会问：重人力、重投入、启动期还亏损的 FDE 模式，乙方凭什么愿意做？ 答案是：重投入换来的，是极高的"切换成本"（switching cost）。

一旦客户的业务逻辑被固化进系统、工作流真正跑起来，客户便几乎无法迁移——换掉这套系统，意味着业务逻辑、数据血缘、人工习惯、流程依赖全都需要重来，代价远高于当初的采购价。这种"落地生根"带来的锁定效应，让 FDE 模式的公司拥有了类似保险或公用事业的商业稳定性（客户想走也走不掉、续约与增购可预期），同时又兼具软件公司的毛利。外包恰恰相反：它卖的是一次性人力，人走价值走，客户没有任何切换负担，也谈不上稳定性。稳定性与毛利兼得，才是"卖能力"而非"卖人力"真正打动乙方经营者的商业理由。

"飞轮真正转的到底是什么？"——乙方要同时盯住两个指标

上文把飞轮描述成"能力回注→边际成本递减"，但很多乙方管理者容易把它误读成"多接项目、多回注、自然就转"。这不是真正的飞轮。 真正的飞轮，是下面两个维度同步推进，而不是单纯"多接项目"：

  1. 价值维度：交付给客户的结果价值，是否越来越大？（客户是否真的在用、真的因此变好、真的愿意为此增购）

  2. 杠杆维度：产品杠杆，是否让 FDE 交付这些结果变得越来越容易——代码越少、时间越短？（平台/组件被回注得越多、越通用，下一个同类交付就越轻）

两个维度缺一不可。 只盯价值不盯杠杆，公司会退回"每次都用人力硬扛"的外包；只盯杠杆不盯价值，回注会变成"为了抽象而抽象"、与客户真实结果脱节的闭门造车。只有当"结果价值越来越大"和"交付越来越容易"同步推进时，飞轮才算真的转起来——这也是乙方判断自己是在做 FDE，还是只是在"多接项目"的试金石。

2.4 财务证据：从"低毛利外包"到"高盈利平台"

Note

时效性声明：本节数据引自 Palantir（NASDAQ: PLTR）公开财报，截至 FY2025（自然年 2025，财年截止 12 月）。财务数据会随时间更新，读者引用前请自行核对最新财报——可访问 https://stockanalysis.com/stocks/pltr/financials/ 查阅最新营收、毛利率与净利率口径（表中 2025 年 82.4% 毛利率、+36.5% 净利率、44.8 亿美元营收等数值均为 FY2025 时点数据）。

Palantir 早年因投入大量 FDE 在客户现场，常被华尔街诟病为"一家伪装成 SaaS 的低毛利外包公司"。但随着 FDE 飞轮的转动，其财务数据实现了惊人的反转。这个反转分两个阶段发生——先是毛利率爬升，再是盈利能力质变：

第一阶段（2018–2022）：毛利率证明"这不是外包"。

财年 整体毛利率 核心驱动因素
2018 ~50% Apollo 部署平台尚未成熟，FDE 纯靠人力堆叠整合异构数据。
2020 68% Foundry 平台组件化加速，Apollo 实现自动化跨网部署。
2022 78.6% 行业本体（Ontology）大规模复用，每个新增客户实施周期大幅缩短。

毛利率从 50% 爬到 ~80%，已经足以反驳"外包"论——外包的毛利率通常只有 10%–30%。

第二阶段（2023–2025）：毛利率见顶后，飞轮威力转移到"盈利能力"上。

到 2023 年后，毛利率稳定在 80% 出头的高平台（2023 年 80.6%、2024 年 80.3%、2025 年 82.4%），不再是看点。真正体现飞轮成熟的，是经营利润率与净利率的转正与飙升——这说明平台复用带来的规模效应，终于压过了 FDE 的人力投入成本：

财年 整体毛利率 经营利润率 净利率 营收（亿美元） 营收增速
2022 78.6% -8.5% -19.5% 19.1 +23.6%
2023 80.6% +5.4% +9.8%（首次转正） 22.3 +16.7%
2024 80.3% +10.8% +16.3% 28.7 +28.8%
2025 82.4% +31.6% +36.5% 44.8 +56.2%

Note

数据来源：Palantir（NASDAQ: PLTR）公开财报，经 stockanalysis.com / Fiscal.ai 整理，截至 2025 财年（自然年，FY 截止 12 月）。毛利率、经营利润率、净利率均为公开可查证数据。

这张表最反直觉、也最有参考价值的一点是：2024→2025 年，Palantir 营收增速不降反升（从 +28.8% 跳到 +56.2%），同时经营利润率翻了近三倍（10.8%→31.6%）。一家体量已达数十亿美元的公司，还能同时实现"增长加速 + 利润率飙升"，这与"平台沉淀越厚、边际成本越低"的 FDE 飞轮机制方向一致，可作为飞轮成立的旁证（并不构成严格因果证明——见下方口径提示）。

Caution

财务口径与因果提示（请勿过度归因）：上述毛利率/净利率/营收改善不能单独、直接证明"FDE 飞轮成熟"或"AIP 让 FDE 用极少代码交付"。企业财务结果还同时受市场需求、客户结构、定价策略、会计口径（如 2025 年净利率走高可能含一次性损益或新口径）、成本控制等多重因素影响。因此本章把这些指标定位为"财务表现与该机制一致的可观察旁证"，而非单一指标的严格证明。需要任何一项作为严谨论证时，请回溯 Palantir 官方财报与披露口径自行判断。

除了毛利/净利，还有两组数据在方向上与"落地生根、卖能力"的模式一致（旁证而非严格证明）：

  • 净收入留存率（NRR）——"从 1 个用例扩展到 N 个"在财务上的反映。 NRR 衡量老客户今年比去年多付了多少钱，大于 100% 说明老客户在持续增购、扩展场景。Palantir FY2021 总体 NRR 达 131%（其中美国商业 150%、政府 146%），FY2022 为 115%，2024 年回升至 118% 左右（FY2025 的 NRR 官方未单独披露，读者引用时以最新财报口径为准），并结合第 4 章 BP 案例的"落地生根"一起看——它在方向上印证了 FDE"先用一个快赢切入、再横向复制"的扩张逻辑，但因 NRR 口径会随客户结构与披露方式变化，勿将其作为单一"确证"。
  • 单客户产出持续走高——规模化不是靠堆客户数，而是靠做深单客户。 Palantir 每个政府客户的年均收入从 2020 年的 680 万美元增至 2021 年的 1000 万美元；其 Top 20 客户的近十二个月平均收入，从 2024 年的 6460 万美元升至 2025 年的 9390 万美元。单客户越做越深，与"卖能力"（而非按人头卖一次性项目）的商业模式逻辑一致（同样受客户结构与价格因素影响，属旁证）。

Note

上述 NRR 与单客户收入均为 Palantir 官方财报/投资者材料披露的可查证数据，来源见附录 C。

Important

对 To B/To G 技术服务商的启示： 早期容忍较低的毛利率并敢于向客户现场派驻顶尖人才（FDE），是获取行业 Know-how 和核心数据的必经之路。只要建立了"现场定制 -> 平台抽象"的坚实反馈管道，后期规模化盈利就更有可能达成。Palantir 用了约七年（2018 的 50% 毛利、亏损 → 2025 的 82% 毛利、36% 净利率）走完这条路——飞轮启动慢，但一旦转起来，规模化与盈利的正反馈就会放大（"回报是指数级"非精确承诺）。

2.5 真伪 FDE 鉴别清单

本节把第 1 章的本质辨析，变成一份可勾选的操作工具——读者（尤其是甲方 BDM/TDM/HR）不再需要凭感觉判断"对方是不是真 FDE"，而是照着清单逐项核验即可。

先看三档判定——核心看"做完项目留下什么"：

维度 外包 项目制 真 FDE
做完项目留下什么 只留给客户一个孤立系统 带回一些经验，但无法复用（经验留在个人身上） 严格去掉客户信息后，把行业通用经验沉淀为可复用的模板 / Skill / 平台能力，能显著降低下一个同类客户的交付成本

一句话：外包留系统、项目制留经验（不可复用）、FDE 留可复用的平台能力。 判断真伪，就看"项目结束、人离开现场之后，公司手里留下了什么"。

8 条勾选鉴别项（真 FDE 应尽量满足）：

  • ① 交付结束后，公司能力是否增长？——不只是客户受益，而是"公司"这个主体的可复用能力变强了（呼应第 1 章的核心判定）。
  • ② 是否有能力回注动作？——识别（值得抽象的点）→ 抽象（解耦成通用组件）→ 集成（并入平台）→ 验证（确认可复用且不坏），形成闭环。
  • ③ 是否按价值而非人头计费？——报价挂钩结果/KPI，而非人天（Time & Material）；人天计费从考核机制上就会把 FDE 逼回外包。
  • ④ FDE 是否汇报给产品线而非销售？——汇报线决定行为：汇报给销售会被"签单压力"裹挟成一次性外包（呼应第 3 章）。
  • ⑤ 定制代码是否被抽象为可复用组件？——不是写完就留在客户那里，而是其中通用部分被抽离、回注为组件。
  • ⑥ 是否沉淀了 Playbook / SOP？——把"这次怎么做的"固化成可复用的方法文档，而不是只留在个别工程师脑子里。
  • ⑦ 离开客户现场后，系统是否仍能自运营？——客户离开 FDE 后系统照常运转（而非人一退系统就瘫），说明交付物是"能力"而非"人"。
  • ⑧ 人才是否是真工程师（能写生产级代码）而非咨询顾问？——FDE 的内核是工程师身份（呼应第 1 章）：真 FDE 写得出生产级代码；只会画方案、讲道理的，本质是咨询。

Caution

这份清单不是"全或无"的考试，而是一把诊断尺。 现实中一个团队可能满足 6 条、卡在 1 条。卡住的那一条，往往就是它正在向外包退化的位置（尤其 ③④ 两条考核/汇报线，是退化的最优先入口）。甲方可据此评估供应商下限；乙方可据此做自诊断，提前堵住退化缺口。

Tip

给甲方的判读阈值（可操作版）：8 条中勾选 ≥6 条，且 ①②③④ 四条"硬指标"必须勾选，才可认定对方是"真 FDE 倾向"；若"硬指标"中任何一条缺失（尤其 ③ 按价值计费、④ 汇报产品线），无论其余几条如何，都应视为"高退化风险"供应商——签约前优先核验这两条，因为它们是考核/汇报线层面的结构性保证，后天很难补齐。

Important

本章小结：传统项目制的问题是结构性的：边际成本不降，规模越大越吃力。FDE 靠能力回注让边际成本随项目数递减，Palantir 的毛利率与 NRR 验证了这条经济逻辑；鉴别真伪 FDE，先看计费方式和汇报线。

Tip

本篇小结 认知篇立起了全书的地基：FDE 不是驻场外包，而是"用平台承载定制、再把定制回注为平台能力"的一种交付范式，其本质是从卖人力到卖能力。它之所以成立，是因为一条经济学规律——能力回注飞轮让边际成本随规模递减，从而走出传统项目制的死亡螺旋。但"飞轮"目前还只是一个原理；它在现实中究竟长什么样、由谁跑通？ 下一篇（标杆篇）将走进 Palantir——这套模式的发明者与集大成者，看它如何用平台、团队与方法论把飞轮真正转起来。

本篇收尾 · 甲乙方对照：什么是 FDE

中国 FDE 实践中，组织内部的权责博弈往往比技术方案本身更复杂——同一个词，甲方和乙方理解不同。收尾的这组对照，把认知篇最容易起分歧的三个问题，按"甲方怎么问、乙方怎么答"拆开。

问题一：这和驻场外包有什么区别？

  • 甲方这么问："你们派几名工程师到我们现场写代码，这不就是驻场外包吗？怎么收费、按人天吗？"
  • 乙方这么答：区别不在"当下做什么"，而在"做完之后留下什么"——用三档判定回答：外包只留给客户一个孤立系统；项目制带回一些无法复用的经验；真 FDE 则严格去掉客户信息，把行业通用经验沉淀为可复用的模板 / Skill / 平台能力，并显著降低下一个同类客户的交付成本。所以我们也反对按人头计费——我们卖的从来不是工时，而是被平台放大的能力。

问题二：你们为什么投入这么重？

  • 甲方这么问："为什么你们要派这么多顶尖工程师、做这么重的现场投入？成本是不是都摊到我头上了？"
  • 乙方这么答：重投入换来的是极高的切换成本——您的业务逻辑一旦固化进系统、工作流跑起来，就几乎无法迁移。这让 FDE 模式公司拥有了类似保险/公用事业的商业稳定性，又兼具软件公司的毛利。我们愿意重投入，是因为我们卖的不是一次性的人力，而是可持续的能力——您的系统落地生根、越用越离不开，我们也越做越省。这是双赢，不是把成本转嫁给您。

问题三：我怎么知道你们是真 FDE，不是换牌子的外包？

  • 甲方这么问："市面上一堆公司都自称 FDE，我怎么判断你们是真材实料，还是把外包换个 AI 的壳？"
  • 乙方这么答：请直接用鉴别清单逐项核验（8 条勾选项）：能力是否增长、是否有回注动作、是否按价值而非人头计费、汇报给产品线还是销售、定制代码是否抽象为可复用组件、是否沉淀 Playbook/SOP、离开现场后系统能否自运营、人才是否真工程师。同时您有权向我们要回注证据——即"这次交付之后，你们的平台新增了哪些可复用的组件 / Skill / 模板"，拿不出这些证据的"FDE"，请谨慎对待。

收尾悬念：识别"什么是 FDE"只是第一关。真正难的下一关是——一个项目到底算不算"做成了"，由谁来定义？甲方和乙方的答案往往不一致。 这个"结果定义权"的分歧，将作为流程篇（SOP 与验收）要正面解决的起点。