领导力支柱 · 部署经济学

为什么 AI 部署这条线的成本比许可证更高

作者：Roman Magdalenko · 2026 年 7 月 30 日 · 阅读时长 11 分钟

标准的批评认为，嵌入式工程师会摧毁软件毛利率。Palantir 的毛利率却从 78% 升至 84%。这对买家意味着什么。

TL;DR 在客户现场派驻工程师，按理说会把软件毛利率压缩成服务毛利率。而在整整五年做这件事之后，Palantir 的毛利率从 78% 上升到 84.1%，净收入留存率达到 150%。解释在于时序安排和会计处理：一个低成本的价值验证阶段与一个高成本的扩展阶段被分离开来，而工程师的时间更像客户获取和研发投入，而不是销货成本。对买家而言，这重新定义了报价的含义。部署这条线的定价是针对 95% 的试点失败率而设的，而有四个问题可以告诉你，你究竟是在为一件产品买单，还是在为一家代理机构买单。

2021

78.0%

训练营拆分之前

2023

80.6%

部署模式规模化

2025

82.4%

价值验证阶段分离

2026 年 3 月

84.1%

150% 净收入留存率

五年间把工程师派驻到客户现场，毛利率提升了六个百分点。这些工程师从来不是服务客户的成本，而是获取客户的成本。

每一场企业级 AI 谈判都会遇到同样尴尬的时刻。许可证的价格买家还能接受，而旁边的部署那条线却是它的三到七倍，供应商的解释无非是“我们的产品很复杂”之类的说法。没有人对这个答案满意，也没有人应该满意。

我之前写过这项工作本身的样子，见 前沿部署工程师才是 B2B 收入 AI 的真正学科。本文要谈的是账单。这种交付形态的成本是多少，为什么对它的标准批评在数字上是错的，买家实际购买的是什么，以及这种模式会让你在依赖性上付出什么代价。

本文基于我发起或挽救过的 200 多个 B2B AI 试点项目的数据，以及公开财务披露。所有客户案例均按行业和规模匿名处理。

在你的组织中，赞助支持会在哪里失败？

这份 12 分钟的收入架构审计专门对领导力层面进行评分。无需注册。最后提供同期群报告。

反直觉之处：毛利率反而上升了

标准的投资者批评是这样的，而且它有其合理性。在客户现场配备资深工程师是一项服务业务。服务业务毛利率低，且难以规模化。因此，任何进行前沿部署的供应商都是一家披着软件估值外衣的咨询公司，而你报价单上的部署那条线就是证据。

数据并不配合。企业软件中服务占比最高的厂商，其毛利率在五年内提升了六个百分点，从2021年的78.0%提升至2026年3月的84.1%，同时净收入留存率在2026年第一季度达到150%。无论嵌入式工程师对损益表做了什么，压缩它绝不是其中之一。

有两个因素可以解释这个数字，而这两点对买家都很重要。

第一个是顺序安排。 过去一个昂贵的动作被拆分成了两个。一个简短的训练营在一到五天内就能在客户的真实数据上证明价值，而传统的试点需要一到三个月。随后昂贵的嵌入式工作是在一个已经有人验证过的基础上展开的，而不是试图去建立一个基础。廉价的阶段淘汰掉那些注定行不通的项目。昂贵的阶段只在效果已经显现的地方运行。如果你的供应商在你的数据上还没有证明任何东西之前就想要六位数的费用，那他们跳过了让这个模式得以成立的关键阶段。

第二个是会计处理。 把工程师的时间记为销货成本，你得到的就是一家低利润率的服务公司。把它记为客户获取成本——这正是把一个概念验证转化为多年合同的过程——再加上研发费用——这正是把一个客户的定制化构建转化为产品能力的过程——同样的活动读起来就完全不同了。这两种处理方式在算术上都是站得住脚的。关于这个模式的大部分公开争论，实际上是在争论损益表中的某一行。

买家真正付费购买的是什么

不是工程师工时。而是风险消除，其定价参照的是一个对于新兴品类而言记录异常完善的失败率。

MIT 发现中的细节是值得带进供应商会议的那一条。这些失败并非模型质量问题。通用工具之所以对个人效果极佳，恰恰是因为它们灵活；而它们在企业内部停滞不前，是因为它们无法学习组织的工作流程。这个差距正是嵌入式团队所弥合的，这也与我在客户知识架构中从知识角度提出的论点相同。

四个风险就此消除，而一个称职的供应商应该能指出报价中哪一行对应覆盖哪一个。集成风险，因为数据存在于封闭且无文档的系统中，任何问卷都无法揭示。数据质量风险，即上文提到的 85%。采纳风险，即系统已建成、已上线却无人使用的状态。授权风险，缺少授权会让一个能正常运行的系统永远停留在部门实验阶段。

这说明“为什么部署成本比许可证还高”是个错误的问题。正确的问题是：进入那 95% 需要花多少钱。

团队是双人组合，而不是单打独斗的英雄

从 Palantir 的组织方式中，最可迁移的经验不是该招什么人，而是基本单位是两个人，而不是一个人。该公司以北约音标字母为团队命名，其中与此相关的两个是 Delta 和 Echo。

这两个角色缺一不可。工程师需要客户背景才能构建正确的东西。策略师需要足够的技术素养才能承诺可构建的东西。搭建这一模式的创始人几乎总是只先招 Delta，因为这一半看起来像工程，而另一半看起来像管理开销。

结果是可以预见的，我在这一类别中见过最多的失败就是它：一个技术上完全正确却没有用户的系统。它表现为产品问题，实际上是组织问题，这与为什么 93% 的销售领域 AI 实施会失败背后的机制相同，也是自中间向外销售 B2B AI，而非自上而下中的购买顺序之所以有效的原因。在买方一侧，同样的逻辑反过来也成立：如果供应商的部署报价中没有覆盖采纳那一半的条目，你就是在为一个半支团队买单。

想知道这些如何映射到你的业务？

收入架构审计会围绕四个层面提出 20 个问题，并给出你在同类群体中的定位：你的最大差距在哪里、应该先修复什么、以及应该向供应商要求哪些证明材料。

供应商不会放进演示文稿里的内容

一篇诚实的文章必须包含账单，而其中最犀利的版本来自一个有动机这么说的竞争对手，但这并不代表它说错了。

Anaplan 的 CEO Charlie Gottdiener 认为，前沿部署工程很擅长做出漂亮好看的仪表盘，但交付的持久能力有限，并且制造依赖。他的表述值得在谈判时记在心里：“如果我想做一处改动，我就得付钱让他们来做。”他称这是一种有效的销售策略，却是运营软件的糟糕模式。

领导 Kinaxis、此前在 Palantir 负责供应链解决方案的 Manik Sharma，从模型内部而非对立面提出了一个反对意见：把 25 岁的工程师放到客户身边是个问题，因为他们往往缺乏所解决问题领域的专业知识。技术上的娴熟不等于了解客户的行业是如何运转失灵的。

而这种依赖风险有一个国家级规模的公开例子。NHS 联邦数据平台合同为期七年、涉及多达 240 个组织，金额高达 3.3 亿英镑。到 2026 年 4 月，英国议会已将对单一外国供应商的国家卫生基础设施依赖描述为一个弱点，并正在讨论退出条款。这与私人买家承担的风险敞口相同，只是规模大到人人可见。

实际的应对之道不是回避这种模式，而是在签约之前而非之后提出能力转移的问题。哪些成果物归我们所有：模型、配置、文档、受过培训的内部人员。哪些改动我们无需开具采购订单即可自行完成。如果团队离开，正在运行的系统会怎样。

如何区分一支真正的前沿部署团队和一个着陆页更漂亮的代理商

a16z 对这一模式的剖析阐明了该模式何时是合理的、何时会沦为服务陷阱。它可以干净利落地转化为一份买方清单。

• 部署有明确的时间限制，以冲刺方式推进到生产环境，而非无休止的合作。
• 每单位账面收入对应的工程师人数有明确上限。没有这一上限，供应商的经济激励会促使他们拉长工期。
• 定制代码按既定节奏被系统性地重构为可复用的产品配置。
• 工程师隶属于产品团队，而不是身处一个与产品路线图隔绝、没有回归路径的封闭服务部门。
• 供应商坦率地说明其利润率结构，而不是把服务模式包装成纯订阅。

还有四个问题要在会议本身上提出。通用产品到哪里结束，为我们做的定制从哪里开始。在可比的客户案例中，从签约到生产需要多长时间。你们的成熟客户是否明显比新客户需要更少的介入。如果我们分道扬镳，究竟哪些东西仍归我们所有。

第三个问题是区分这两类供应商的关键。在真正的平台模式中，随着定制工作被产品化，客户依赖会逐渐衰减。而在披着软件外衣的服务模式中，这种依赖无法衰减，因为依赖本身就是收入来源。第一类供应商会立即回答这个问题并给出实例；第二类供应商则会搬出“合作伙伴关系”这个词。

给欧洲买家提一个结构性提示，因为它会改变可谈判的范围。CISPE 的调查数据显示，72% 的欧洲企业 IT 决策者将数据主权列为选择供应商的考量因素，而监管压力也在持续推动部署走向本地化或完全物理隔离。SaaS 模式无法触及物理隔离环境，但嵌入式工程师可以。在数据主权构成约束的地方，前沿部署就不再是市场推广偏好，而成为结构性要求，这意味着部署这条费用线不会谈到 SaaS 的水平。剩下可谈判的是移交条款，注意力应该放在那里。

最后一点。这种模式并不适合所有人。只有当问题事关重大、数据封闭或碎片化、且边界不可妥协时，它才配得上它的价格。对于标准用例，请自助使用，在自己的数据上衡量效果，等你能够精确说出嵌入式团队的用途时再购买。为 SaaS 形态的工作购买 FDE 形态的交付，其代价与反过来的错误一样高昂，而且要常见得多。

核心要点

01 为部署定价时，参照的是失败率，而不是许可证。

把部署报价与许可费相比较是一个范畴错误。前者按软件经济学定价，后者按落入那 95% 不影响任何损益指标的试点的概率定价。问供应商每一项费用分别消除了哪种风险。

02 如果你要建立这种模式，请在招聘工程师的同时招聘负责采纳的那一半。

创始人招聘 Delta 是因为它看起来像工程，而跳过 Echo 是因为它看起来像管理开销。可预见的结果是一个技术上正确却无人使用的系统，而在仪表盘上，这看起来与产品问题一模一样。

03 询问供应商的成熟客户是否每年都明显减少对他们的依赖。

在真正的平台模式中，随着定制工作被产品化，客户依赖会逐渐衰减。而在打着产品旗号的咨询业务中，这种依赖无法衰减，因为依赖本身就是收入来源。仅这一个问题，就比任何背景调查电话都更快地区分出这两类供应商。

常见问题

为什么企业 AI 部署的成本比软件许可证更高？+

因为许可证按软件经济学定价，而部署按风险定价。MIT 发现 95% 的企业级 GenAI 试点没有产生可衡量的损益影响，Gartner 报告 89% 的 AI Agent 试点从未进入生产环境。部署这条线买的是对接无文档系统、数据质量工作、用户采纳以及高管授权——而这些恰恰是此类项目真正失败的地方。它在结构上也成本高昂：资深工程师、驻场时间，以及一个团队服务一到三个客户，而不是成千上万的订阅用户。

前沿部署工程会摧毁软件毛利率吗？+

证据表明不会，前提是各阶段排序正确。Palantir 的毛利率从 2021 年的 78% 上升到 2026 年 3 月的 84.1%，2026 年第一季度净收入留存率达 150%，而这正是它以在客户现场驻派工程师而闻名的时期。其机制在于将一个低价值验证阶段——在真实客户数据上运行一到五天的训练营——与一个高成本的扩展阶段分开，后者只有在效果显现后才会启动。

前沿部署只是贴着软件价签的咨询吗？+

有时确实是，而且有一些检验方法可以区分二者。a16z 的判断标准是：部署是否有时间限制并指向生产环境、每单位客户收入是否有工程师人数上限、定制代码是否被系统性地重构为可复用的产品配置、工程师是否隶属于产品团队而非一个封闭的服务部门。如果这四条都成立，该模式会复利式地沉淀为产品；如果不成立，你买到的只是一个着陆页更漂亮的代理公司。

买方应如何核算前沿部署工程的成本？+

询问供应商这项工作在他们那边记在哪条账目上。如果记入销货成本，那是服务你的价格，应随供应商成熟而下降。如果记入客户获取和研发，那是证明价值并将你的部署沉淀进产品的价格，这意味着你出资的一部分会让下一位客户受益。两种处理方式都站得住脚。答案会告诉你，你的部署是被期望让产品变得更好，还是仅仅让你维持运转。

使用前沿部署团队的供应商锁定风险是什么？+

由供应商工程师在你的环境内定制构建的系统，通常只能由同一批工程师按他们的费率来修改。Anaplan 的 CEO Charlie Gottdiener 总结道：如果我想做改动，就得付钱给他们。公开的大规模案例是 NHS 联邦数据平台，这是一份 3.3 亿英镑的七年合同，英国议会将单一供应商对国家医疗基础设施的依赖描述为一个弱点。应在合同中加以缓解：明确哪些模型、配置和文档会移交给你，以及哪些改动你可以自行完成。

为什么数据主权正在推动欧洲买方转向这种模式？+

因为主权要求使得纯云交付对越来越多的买方来说变得不可行。CISPE 的调查数据显示，72% 的欧洲企业 IT 决策者将数据主权列为选择供应商的考量因素，而监管压力则推动部署走向本地化或完全物理隔离。SaaS 模式无法触达物理隔离环境，但嵌入式工程师可以。对于这类买方，前沿部署不再是市场推广偏好，而成为结构性要求，这也意味着其成本无法被压低到 SaaS 水平。

每家公司都需要前沿部署团队吗？+

不需要，而持相反说法的供应商只是在推销。这种模式只有在以下情况下才物有所值：问题至关重要、数据封闭或分散在缺乏文档的系统中，且环境必须留在边界之内。对于标准用例，先运行自助服务，用自己的数据衡量效果，等你确切知道部署团队的用途后再引入。为 SaaS 型工作购买 FDE 型交付，与反过来做一样，都是代价高昂的错误。

在供应商替你发现问题之前，先找到你的差距

营收架构审计与我在每次合作开始时运行的诊断完全相同。压缩为 12 分钟。读者免费。

• 四层评分（领导力 / 流程 / 知识 / 技术）
• 12 个群组之一，与你的阶段和领域相匹配
• 一个具体的推荐下一步（而非销售电话）
• 如果你的群组适合预约，则提供直接预约链接

关于作者

Roman Magdalenko 是一位营收架构师。他已启动或挽救过 200 多个 B2B AI 试点。现居西班牙瓦伦西亚。预约 30 分钟架构通话。