導讀：原標題為《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 的能力

• 最終以解決問題為目標

這正是我們持續探索和努力的方向。