Palantir不就是个低代码么？FDE模式颠覆咨询？

导读：原标题为《Palantir不就是个低代码么？》。文章为一篇旧文，觉得仍然很有穿透性，推荐之。

最近各种平台都在向我推 Palantir 的文章，我也看了看官网的介绍和官方视频。看完之后，心里第一反应是：

“这不就是蹭 Agent 热度的低代码平台么？”

但多年的经验立刻提醒我：“这不就是……”句式的背后，往往藏着自己的无知和一次错失思考的机会。

这篇文章，我就来系统地讲讲自己的理解。

01

什么是低代码？

很多人一提低代码，就想到“拖拉拽”。

从 CS 时代的 VB 拖控件，到 BS 时代的“流程 + 表单”，再到近两年的 LLM 节点编排。

但“拖拉拽”只是表现形式，真正值得讨论的是：

为什么有些业务能被拖拉拽？为什么大多数复杂业务无法被拖拉拽快速实现？

我个人认为，低代码的本质有两个核心：

1. 通过 DSL/Schema，对特定业务场景做语法抽象

2. 基于抽象构建可视化设计器，让非技术人员能直接构建系统

比如“流程 + 表单”的典型低代码：

• 用 BPMN/BPML 抽象业务流程

• 用可组合表单控件抽象各种输入

• 最终构建出“流程设计器 + 表单设计器”

而现在的各种 LLM 编排工具，只是把“表单控件”升级成了“模型调用节点”。

02

低代码的优点与局限

低代码确实提高了构建业务系统的效率，但也有两个限制：

场景适配受限

它能覆盖的，只是那些能被“流程化、表单化、结构化”描述的场景。

业务贴合度有限

复杂逻辑要么扩展 DSL（平台复杂度爆炸），要么强行降级需求（客户满意度下降）。

这些限制不是工程问题，而是 抽象方式本身的限制。

03

软件产品的“不可能三角形”

四十二章经19年的一篇文章中提到过一个 “B2B 电商的不可能三角”，我在软件领域也总结了一个类似的“不可能三角形”：

“全场景”，“高定制”，“高毛利”，三者不可兼得

全场景：客户不管什么行业什么场景，产品都能匹配，决定了市场范围大小。

高定制：客户的个性化需求，产品都能满足，决定了客户满意度。

高毛利：更低的成本，代表更低的报价或是更大的盈利空间，决定商业效率与竞争力。

如果都做到了，就是：“物美价廉市场广”，当然这并不容易。

如果我们对比市场上的主流的三类软件交付模式：定制化开发，垂类SaaS标品，低代码平台：

如果说：

• 定制化开发：满足所有需求，但成本高

• 垂类 SaaS：规模化，成本低、但只聚焦特定场景

• 低代码：两边都想兼顾，却都不够极致

所以低代码常年处于两边夹击的状态，在夹缝中找场景求生长。

04

要么上篮，要么三分，不要中投！

这让我想起 NBA 的一个故事。

火箭总经理 Daryl Morey 用大量数据计算三种出手方式的期望得分 EPPS（Expected Points Per Shot, EPPS）：

• 中距离两分：命中率约40%，EPPS 0.8 分

• 上篮/拦下：命中率约65%，EPPS 1.3 分

• 三分远投：命中率约35%，EPPS 1.05 分

上篮命中率高，三分收益大，中投优雅（想想乔丹和科比的中投）但性价比其实最低。

于是得出震撼联盟的反直觉结论：

要么上篮，要么三分，不要中投！

低代码的处境，很像“中投”：

• 没有上篮的必然命中（定制化）

• 也没有三分的溢价空间（垂类 SaaS）。

看似优雅，却不够“性价比”。

05

那Palantir是低代码平台么？

按我对低代码的定义：

1. DSL 抽象某类业务

2. 可视化设计器让非技术人员搭建软件

而 Palantir 的做法是：

1. 用 Ontology（对象、关系、动作）来抽象整个业务世界

2. 让专业 FDE（Forward Deployed Engineer）团队建模与实施

它不是用更贴近业务的 “流程 DSL”，而是把抽象层拉高到 接近面向对象世界观的 Ontology。

抽象能力更强，但建模要求更高，已经超出了非技术人员的认知范围，所以必须由 FDE 团队来完成。

所以，我的回答：

• 如果低代码=业务人员拖拉拽，那 Palantir 不是低代码。

• 如果低代码=用 DSL 快速构建定制软件，那 Palantir 算某种“超低代码”。

但总的来讲，我认为它本质上走的是另一条自己的路，而AI 则是这条路的一个极其关键的要素。

06

AI 打破了软件的不可能三角形

从产品形态上，与其说 Palantir 是一个Agent 版本的低代码平台，我觉得更贴切的更像是在开发领域红极一时的模型驱动开发（MDD：Model Driven Development）。

只不过如果没有 AI，大部分 MDD（模型驱动开发）都会卡死在“模型 → 代码”这一环。

也可以说， AI 让 Palantir 跨越了从“模型 → 代码 → 产品”这一鸿沟，直接进入了“模型 = 产品”（模型即产品）的新的阶段，

于是它看似获得了过去不可能成立的组合：

• 适配场景广（因为 Ontology 可以抽象一切）

• 定制能力强（因为是专业建模）

• 成本又低（因为 AI 直接执行模型，不需要开发）

曾经不可能的三角，被 AI 撕开了一道缝，让我们窥探到了B 端软件的未来。

听起来很梦幻？

确实如此，但新的问题也随之而来。

07

当技术不是问题，瓶颈回到了“人”

就像跷跷板的两侧：一边被按下，另外一边就会翘起。

随着技术门槛下降，真正的稀缺资源变成了：

既懂业务，又能抽象建模，还能落地价值的“复合型人才”。

Palantir 的 FDE 模式，本质上是：

业务架构师 + 解决方案架构师 + 数据工程师 + 技术产品经理 + 快速原型工程师 的结合体。

这种人需要同时具备：

• 行业理解，商业思维

• 业务洞察，需求识别

• 业务建模，数据治理

• 产品思维，沟通协同

• 方案落地，解决问题

这显然不是“培训两周”能搞出来的，而是长期积累的复合能力。

FDE 的高门槛和稀缺性，可能才是 Palantir 的真正护城河。

08

写在最后：另一股正在跃跃欲试的力量

既然未来的瓶颈在“人”，稀缺的是“能力”，那另一股力量也在悄悄酝酿：

咨询师 + 新技术 → 完全可以构建自己的“能力即产品”体系。

特别是那些深度理解行业、流程、价值链、数据的人。

随着 vibe coding、AI 低代码、数据自动化的发展，软件开发成本大幅下降，真正的核心竞争力回到了：

• 能否洞察客户真正的需求和问题

• 能否构建高质量领域模型

• 能否打造跨业务的行业 Ontology

• 是否能把业务语义与 AI 对齐

• 能否充分发挥 AI 的能力

• 最终以解决问题为目标

这正是我们持续探索和努力的方向。