企业 AI 采纳的瓶颈：业务生产力飞轮与两个飞轮之间的连接

本页整理一套「企业 AI 为什么没有按预期产生回报」的分析框架，唯一素材来源是公众号对 Palantir CTO Shyam Sankar × Ben Thompson（Stratechery）访谈的解读稿（2026-11-04 发布，2026-11-05 归档）。

来源与口径：全文四类标注——**（事实）为可核验元信息；（作者主张）为受访者观点或解读稿作者判断；（转引）为访谈提到的 Palantir 做法与案例；（判断）**为本库推论。本库未独立验证访谈观点与案例数据，auto-research、报价训练周期、幂律/高斯判据等均为访谈转述。这是一篇二手解读稿：Palantir 自身表述与解读者的转述、评价需分开看待，后者是第三方评论而非公司立场。

企业的原子单元是工作流，不是知识工作者

“What is the atomic unit of the enterprise?”

“The atomic unit of the enterprise is the workflow.”

（作者主张） 被访谈者指出，Frontier Lab（OpenAI、Anthropic）的产品策略隐含默认假设：企业的原子单元是知识工作者——让每位员工更高效，ROI 自然会来。他判定这一假设「并不成立」。

（转引） 你可以让单个供应链分析师效率翻倍，却产生不了任何增量 ROI；只有当整条供应链工作流整体实现可衡量的效能跃升，价值才会被沉淀与捕获。（作者主张） 机制是流水线原理：一条线的速度与产能取决于最慢、最低效的瓶颈点。分析师出报告从几小时缩到几分钟，只要采购审批、库存调配、生产排程、交付照旧，链路仍卡在原瓶颈上。

（作者主张） Coding 是例外场景，出现多个角色的基数坍缩（Cardinality Collapses）——一个工程师本身就是一条相对完整的工作流，个人产出与最终交付之间几乎没有距离。但 Coding 只是整个社会经济中很小的一部分；制造、供应链、金融的价值要跨越多个角色、系统和决策环节才能实现。（判断） 这也部分解释了为什么大规模 AI 采用至今只见于 Coding。

（作者主张） 三层不可混用；关键在于识别业务价值在哪里产生、真正瓶颈在哪、AI 能否改变这个瓶颈。

层次	问什么
Task Efficiency	单项任务是否完成得更快、更好
Workflow Productivity	完整流程的吞吐、周期、质量和成本是否改善
Business Outcomes	最终是否带来更多收入、利润、产能，或过去无法实现的业务能力

两个飞轮与真正的瓶颈

	模型能力飞轮	业务生产力飞轮
运转机制	研发与算力投入 → 更强模型 → 更多收入与投资 → 反哺研发	围绕 AI 重新设计工作流 → 真实业务执行、反馈、评估、改进 → 持续提升经营成果
决定什么	决定机器能做什么	决定企业能持续做成什么
学习机制	模型研发与后训练，规模化、通用	从真实业务反馈中学习，场景化、不可移植
能否外部购买	可以——通过 API 分发给所有人	不可以——嵌在每家企业具体的流程、系统、组织里

（作者主张） 今天企业 AI 渗透的真正瓶颈在第二个飞轮，以及两个飞轮之间如何连接。 相应地，业界过度关注智能供给（Intelligence Supply），却低估了智能扩散（Intelligence Diffusion）——让模型能力真正变成经济价值。

Top Line over Bottom Line：为什么裁员注定失败

（作者主张） 客户现场出现真实分化：想用 AI 裁员、削减成本的，几乎都没能实现预期目标；而 AI 采纳最成功的客户野心更大——「我要用 AI 主导我的市场」「我要做那些一直想做、却因为太贵始终没做的事」。

（作者主张） 技术原因是98% 铁律：目标若是裁员，AI 就必须能做人做的所有事，哪怕做到 98% 这个具体目标仍然失败，因为剩下 2% 始终无法解决。组织原因是裁员是短视目标，不足以驱动真正的改造。理性做法是借力 Model Capability Overhang（模型能力溢出），围绕 AI 能做的事构建工作流，而不是死磕人与 AI 二选一；并且以业务目标而非岗位为边界——以岗位为边界，系统会被长尾职责牵制。

（作者主张） 行业 AI Adoption 悬而未决，不是因为模型不够强，或许是因为企业对模型能力如何扩散想得太少，缺乏想象力和决心。时代特征也变了：过去追求增长更容易成功，做成本削减也有收获；AI 时代结果更加极端化，大得大失。

启动飞轮的三个连续问题与三种能力

企业要连续回答三个问题：要解决的到底是什么问题？ → 如何被表达成系统可操作的对象和动作？ → 这些动作如何被可靠地执行？

（转引） Palantir 的 FDE、Ontology、Systems Engineering 恰好对应三个环节：FDE 问题定义错了，后面架构再优雅也是在解决错误的问题；Ontology 业务状态和动作表达不清，模型再聪明也无从下手；Systems Engineering 执行不可靠，前面所有工作都无法让 AI 承担真实生产责任。 类比：电力普及之初生产力并未立刻跃升，直到企业围绕电力重新设计整座工厂。

FDE：先把问题找对

（转引） Forward-Deployed Engineering 如今是 AI 行业最热门职位之一。Sankar 自嘲：「过去 17 年他一直被看作毁掉 Palantir 的人，因为他发明了 FDE 这个可怕的概念，然后它忽然成了最酷的东西。」（作者主张） FDE 首先是一种产品战略，不是一个职位，且有适用前提：

需求分布	是否适合	理由
高斯分布（Gaussian）	不适合	可把成千上万客户的信号平均一下决定下一步
幂律分布（Power Law）	适合	少数客户面对某类问题最困难的版本，其他客户迟早也会遇到，只是还没意识到

（作者主张） 因为有些客户活在未来，才需深入现场、从 Specific 走向 General；要靠前几个客户积累接触面，才看清哪种通用形态能服务整个客户群。最大难点是判断抽象放在技术栈的哪一层——端到端方案会对单个客户过拟合。

（转引） 优秀 FDE 人才呈两端：MacGyver 式黑客（擅长判断哪些问题值得解决，负责问题前 80%）与艺术家（把东西造得优雅，负责后 80%）。两种人互相都看不起、都低估对方贡献，组织要在一种危险的不稳定平衡中维系他们。

（作者主张） 对今天许多所谓 FDE 的批评是：派聪明工程师去客户那里，却无机制把现场经历的痛苦沉淀成产品——这类形式就是「加了气泡的销售工程」（sparkling sales engineering）。因此 FDE 不属于 Go-to-Market 组织，而属于产品组织。大模型公司也大量组织 FDE，「对他们而言，真正的 FDE，难道不是模型本身吗？」FDE 的核心价值在问题分解：只做到「还行」就会把大量 Alpha 留在桌上。 金句：「软件实现越便宜，「做对的东西」就会越贵」——现实病灶是功能不断堆砌，但「为什么做、值不值得做、创造什么价值」想得更少了，甚至不判断。（判断） 更强的 Agent 未来可能接管更多需求分析与系统设计，FDE 模式的长期价值要用复用率、部署效率、新客户边际交付成本检验。

Ontology：把业务变成 AI 可操作的系统

（转引） Palantir 把企业视为一个复杂状态机：订单从创建到履约，库存从可用到占用，采购从申请到审批，每次状态转换背后都有业务规则、系统依赖和执行权限。所以 Ontology 从来不只是企业数据的语义表示，它还要建模 Verbs，即可执行的业务动作。 它让企业变得「可编程」——原本给人用的 harness，要变成模型也能使用的 harness。

（转引） 供应链 Agent 的例子：不只要知道哪些物料库存不足，还要知道能否调整采购订单、哪些操作需要审批、执行之后如何更新业务状态。关键设计约束是治理对称性：很多工作流会从人开始、交给 AI、再回到人手里，因此状态机必须与「这项工作由谁发起」无关——无论起点是人还是 AI，状态转换的治理规则和可执行动作都应一致。（判断） 若人路径的审批与容错更好而 AI 路径没有，企业其实是用「治理降级」换自动化率，故障时会集中暴露。

（作者主张） 企业 AI 架构重心从「让模型理解业务」延伸到「管理业务状态和执行过程」。AI Coding 让这一层更重要而非不重要：企业里冒出大量互不连通的应用，要么用完即弃，要么累积成债务。Ontology 提供一个可治理的约束点，让人可以自由 vibe-code，运行与丢弃成本都低，同时不失整体一致性——可某种程度防止「AI slop」堆积。演化方向是：上层应用越来越轻、越来越定制，底层的业务状态、执行接口与治理机制需要越来越一致。

Systems Engineering：让 AI 承担真实的工作

（作者主张） 当 Agent 开始修改业务状态、调用外部系统、影响真实经营结果，可靠性至关重要：「一个有能力的模型，并不一定是一个能工作的系统。」 大模型公司存在 Model Blindness，认为模型未来可解决一切；企业真正要考虑的，是在模型上面补齐什么。系统工程的理念很朴素：事故复盘不只记录发生了什么，还写清楚要建造、修复和改变什么，风险靠持续的工程改进一点点降下来。落到企业 AI 要区分三层：

层次	内容
Model Capability	模型是否具备完成任务的能力
System Reliability	完整系统能否稳定、正确地执行任务——工具调用失败、重复执行、状态冲突、异常恢复，都需确定性软件、权限控制和监控兜底
Operational Accountability	执行过程和结果能否被监督、审计和纠正，责任归属是否明确

（作者主张） 三者共同决定了企业到底能把多少真实工作交给 AI。三环节合起来飞轮才转得起来：FDE 把高价值问题找对、抽象对；Ontology 把业务状态和动作组织成 AI 可操作的系统；系统工程保证这些动作可靠、可控、可追责——最终模型智能进入真实业务，飞轮把每次业务执行转化为下一轮系统改进，形成企业自己的复利效应。

从一次性提效到持续增长：Alpha 与 Operational Learning

（作者主张） 今天大量 AI 应用仍是简单结构：输入任务、调用模型、返回结果。模型升级时应用随之变强，但若产品自身缺乏反馈、评估和改进机制，进步几乎完全依赖外部模型。企业真正需要一个能在自己业务里持续变好的系统。

（作者主张） Beta vs. Alpha：传统 SaaS 必须卖给尽可能多客户才能收回研发投入，于是定义了标准流程，大家最终用上同样的工作流——那是 Beta。AI 时代企业的差异化（Alpha）并不来自标准化：IT 部门天然倾向 Beta——模仿、贴近最佳实践、选大家都在用的东西；最渴望 Alpha 的往往是业务线上的人。只调用 OpenAI/Anthropic API 的代价是：把全世界的知识复利进自己无法控制的模型权重里，丢掉自己的 Alpha——「我公司的立足之本是什么？如果所有企业智能最终进入了我无法控制的模型权重里，我该怎么办？」Alpha 应该在哪里积累？就在真实的业务执行过程中——采购、生产、定价、客服中的决策与结果，沉淀着企业特有的约束和经验。

（转引） Operational Learning 的机制是：运营决策不断产生数据，让企业每个月训练一个新的 checkpoint，并与此前所有版本、与历史上的实际决策对照评估。Palantir 正在投入 auto-research 项目：不需要客户组建庞大后训练团队，就能用供应链或生产计划中的决策数据在后台自动训练模型，然后告诉客户「这里有一个比你现在做得更好的模型」。每次调用大模型都被当作一条 trace 收集，反哺系统本身。

（转引） 电子元器件报价案例：客户提交采购需求时附带相当专业的电气工程图纸，对前沿大模型明显属于没见过的数据；而企业手里有过去十到二十年由人完成的历史记录——输入规格是什么，最终报出的 BOM 是什么。在已有运营数据前提下训练这样一个模型大约只需几周，之后企业能比对手更快报价，因为对手要花几周啃完同样的规格。

（作者主张） 但原始运营数据并不天然等于学习信号。一笔报价成交可能因为价格优势，也可能因为客户关系、对手缺货或市场波动。若无法识别决策与结果的关系，系统就可能越学越偏，不断强化错误的经验。 业务数据成为真正学习资源需满足三个条件：

条件	要求
结果可观测	业务背景、关键决策、执行过程与实际结果能够关联起来
反馈可评估	能判断哪些结果代表真实改善，并尽量区分外部噪声与历史偏差
经验可复用	经验证的结论能进入知识、规则、工作流、工具或模型，并迁移到后续任务

bench-making：企业需要自己的评价体系

（作者主张） 这里的「可评估」指企业自己生产场景的评估，不是公开评测集上的刷榜式跑分。当前大模型能力仍是典型的锯齿状分布（Jagged Capabilities），公开榜单再高的得分不意味着企业自己场景上能力依然很好。重要的不是 bench-maxxing，而是 bench-making。 企业应尽早构建能刻画自己生产环境问题分布的真实生产评测系统，并把取舍显式化：你的评估标准是什么？在延迟、成本和性能之间如何取舍？ 这让企业从「最新最酷的模型是什么」转向「对我真正重要的是什么、改善了多少」。评估需覆盖三层：

层次	回答什么
Model Evaluation	模型是否正确理解任务、输出是否满足要求
Workflow Evaluation	Agent 是否正确调用工具、处理异常并完成流程
Business Outcome Evaluation	系统最终是否改善了效率、质量、收入或其他关键指标

（转引） 以供应链 Agent 为例，不能只看预测准确率，还要看采购建议是否可执行、库存周转是否改善、交付风险是否下降。只有把系统表现与真实业务结果连起来，改进才有方向。

（作者主张） 持续学习的完整链路是：Business Execution → Observable Outcomes → Evaluation → System Improvement → Better Execution。持续学习不必然意味着重新训练模型：有些问题通过更新知识、调整规则或改进工具接口就能解决；有些需要重新设计工作流；只有当任务、数据和经济性都合适时，才值得做专门的模型训练。

什么才算复利

（作者主张） 持续优化不等于复利增长。 系统不断修正错误可能只是局部优化；若每次改进都局限在单一场景，下一次仍要从头分析、开发和验证，就谈不上积累。 复利成立需三个条件：

1. 净收益为正——新增的业务收益必须超过数据治理、评估、训练和系统维护的成本
2. 跨场景复用——让下一次解决问题更便宜
3. 受控部署中被持续验证和监控——业务环境变化时识别失效的经验，并能及时回滚

（作者主张） 衡量指标是 Learning Efficiency：借鉴模型训练的学习率概念，衡量以多低的成本、多快的速度，把真实业务经验转化为下一轮可验证、可复用的系统改进。比起数据规模、模型参数和训练次数，它更接近企业持续学习能力的实质。

两个连接点：Capability Adoption 与 Operational Learning

方向一：从模型到业务 —— Capability Adoption。 （作者主张） 模型的每一次进步都会让一批新任务进入技术可行区间，但企业还要完成工作流设计、系统集成、权限验证和生产部署才能真正用上。一次模型升级的实际价值，取决于它能否以合理成本转化为可部署、可衡量的业务改善。 企业需要快速吸收模型进步的能力：用自己的任务评估新模型，再把新增能力安全接入业务流程。模型飞轮转得越快，Model Capability Overhang 的问题就越明显。 （判断） Overhang 是能力与采用之间的存量差，模型加速时扩大而非缩小——「等模型再强一点再采纳」有结构性成本。

方向二：从业务到学习 —— Operational Learning。 （作者主张） 真实业务不断产生新的问题、经验和反馈，推动企业改进知识、规则、工具、工作流和专用模型；在授权、数据质量和训练机制具备时，也可能为更通用的模型研究提供输入。创新是生产的结果：一旦不再亲手制造东西，也就失去了围绕它进行创新所需的刺激。是什么驱动 Google 做出「Attention Is All You Need」背后的研究？那个团队想要的，是 Google Translate 3% 的提升——很难想象如此平凡的起点带来如此深远的结果。真实部署既是生产力的来源，也是学习的来源；如果 AI 只停留在演示和实验里，就失去了来自真实生产环境的那种刺激。 但这种连接不会自动发生——业务数据质量、使用权限、反馈机制和评估能力决定经验能否真正变成下一轮改进。

（作者主张） 两者合看，比追踪模型能力增长更重要的，是新增的智能能多快、多有效地进入真实业务，以及企业能否把真实执行中的经验持续转化为经过验证的系统改进。前者是 Capability Adoption，后者是 Operational Learning，两者共同决定了模型进步与业务生产力之间的转化效率——即「如何以更快的速度、更好的投入产出比，把 token 变成经济价值？」分工不固化：模型公司可以深入应用层，企业也可以开发训练专用模型；随着 Agent 能力提升，今天由 FDE 和业务架构师承担的一部分工作可能逐渐由模型完成——两个飞轮的区别在于优化目标和学习机制，不在于某项工作必须永远由哪类公司负责。务实策略是：充分利用通用大模型能力，同时保留关键业务的执行控制、责任归属、模型选择、有效评估和持续学习能力——这正是 Own Your Intelligence 最有实际意义的部分。收尾三问：我们真正改善了哪一条高价值工作流？系统能否可靠执行并产生可衡量的业务结果？经验能否以合理成本转化为下一轮可验证、可复用的改进？

从方法论到资产：四层传导

把上述框架向资产与资本开支传导，可分三层（（判断），本库推论）：

层次	传导内容	观察什么
L4 资产配置	AI 需求是否真实，是否值得给相关资产更高风险预算	采用者的流程重构证据与产出可验证性；是否自建执行控制
L3 企业采纳	企业是否真的把 AI 变成经营成果	Workflow Productivity 与 Business Outcomes 的可测变化
L2 产业与资本开支	需求是否传导到硬件、数据中心、模型采购	订单与资本开支是否由可验证的业务需求支撑
L1 智能供给	模型能力本身	能力曲线斜率与成本曲线（供给侧，对企业采纳影响有限）

（判断） 核心含义是：L1 的强，不自动意味着 L3/L4 的强。 模型能力是全球共享的公共品，其改进会同时抬高全行业基线，而非只抬高某一家的护城河。

判断「AI 需求是真的还是被卖方叙事堆出来的」的三条标准

（判断） 基于本页框架可给出三条可操作标准：

1. 是否出现工作流重构——有没有可举证的流程、系统、组织层面的重新设计（状态与动作被显式建模、审批与权限被重写、瓶颈被重新识别），而不是在原流程上叠加一个 AI 助手。这是 Task Efficiency 与 Workflow Productivity 的分界线。
2. 是否有可验证的业务产出评估——是否有面向自己生产场景的评测体系（bench-making），且评估下沉到 Workflow 与 Business Outcome 层，而非只报模型指标或公开榜单分数。
3. 是否自建执行控制（Own Your Intelligence）——关键业务的执行控制、责任归属、模型选择、有效评估、持续学习能力是否留在企业内部，还是全部外包给模型供应商。

（判断） 三条都满足时需求更可能是真的；只满足第一条（会演示、会重构局部流程）时属于典型的试点繁荣；一条都不满足时，需求更可能是被卖方叙事堆出来的。

（判断） 与本站其他页面的分工：本页提供企业侧采纳机制（为什么企业没拿到 ROI、什么算真采纳），属方法论层；AI 价值链提供产业侧分配结构；AI 算力周期与AI 资本开支与利率提供宏观与资本开支节奏；AI 对经济增长与生产率影响的三种观点提供宏观情景。宏观生产率争议的落地条件，取决于工作流重构能否真实发生。

常见误读

• 「让每个员工效率翻倍就有 ROI」 —— 错。企业原子单元是工作流，不是人。 单点提效不改变瓶颈。
• 「裁员是 AI 落地的正确目标」 —— 错。98% 也失败，剩下 2% 始终无解。应以业务目标而非岗位为边界重构工作流。
• 「用 OpenAI API 就等于获得了 AI 能力，不用担心」 —— 错。只调用 API 意味着把全世界的知识复利进自己无法控制的模型权重里，丢掉自己的 Alpha。
• 「公开榜单第一就能证明适合自己业务」 —— 错。模型能力是锯齿状分布，企业需要的是 bench-making。
• 「Ontology 就是给企业数据做语义标注」 —— 错。Ontology 不只建模数据（nouns），还要建模 Verbs（可执行业务动作），并治理状态、权限与执行，且规则与工作由谁发起无关。
• 「有能力的模型 = 能工作的系统」 —— 错。必须区分 Model Capability / System Reliability / Operational Accountability 三层，异常处理要靠确定性软件与监控兜底。
• 「持续优化就是复利」 —— 错。持续优化 ≠ 复利增长，复利需净收益为正、跨场景复用、受控部署可验证可回滚。
• 「模型能力提升会自动带来企业生产率提升」 —— 错。模型飞轮决定机器能做什么，业务飞轮决定企业能持续做成什么。 电力革命中，跃升发生在企业围绕电力重新设计工厂之后。

相关条目

• AI 价值链：产业侧分配结构——谁在链条上捕获 AI 价值，与本页互补。
• AI 资本开支与利率：资本开支与利率环境的交叉，对应本页 L2 传导层。
• AI 算力周期：供给侧算力周期，与本页「模型能力飞轮」互为背景。
• 新结构经济学与 AI：范式批判视角，与本页实操框架互补。
• AI 与资产定价：AI 叙事如何进入定价，对应本页 L4 资产配置层。
• AI 对经济增长与生产率影响的三种观点：宏观情景，本页讨论其企业侧落地条件。
• Anthropic IPO 事实：模型侧供给格局的事实底稿。
• 科技板块估值：板块层面的估值方法，对应本页 L4 推论。