5 月初，Anthropic 和 OpenAI 在同一天分別宣布成立了企業服務公司。Anthropic 聯手黑石、高盛等，成立了估值 15 億美元的企業服務合資公司；OpenAI 也被曝正在籌建一家名為 The Development Company 的新公司，計劃從 19 家投資者處籌集 40 億美元，估值 100 億美元。

兩家方向不同、出資方不重疊，但支撐它們的核心組織形式，都是 Palantir 推廣的 Forward-Deployed Engineer（前沿部署工程師，FDE）模式。

同樣，據 Business Insider 報道，FDE 相關崗位從 2025 年 4 月的 643 個，飆升到 2026 年 4 月的 5330 個，同比增長了近 729%。Anthropic、OpenAI、Palantir、Stripe、Google Cloud 都在搶人。

最近，FDE 幾乎成為了科技行業最搶手的工作，也是 AI 落地中最關鍵的角色。

為什么 agent 時代所有人都在搶 FDE？

因為客戶買的不是軟件，而是一個「能干活的 agent」。PMF 更多發生在客戶的真實業務現場，FDE 直接駐場，理解客戶的數據、流程、痛點，然后把通用模型打磨成能跑業務的具體方案。他們既是工程師，也是產品經理、解決方案架構師，甚至算是半個咨詢顧問。

FDE 這個崗位是怎么被設計出來的？Palantir 內部是如何選人、搭團隊、驅動產品的？

這篇文章，是前 Palantir 高管、前 OpenAI 首席研究官 Bob McGrew 關于 FDE 模式的一次深度復盤。作為 Palantir 的第二位工程師，Bob 完整經歷了 FDE 模式從 0 到 1 的誕生，也親手參與了產品構建、人才篩選和團隊搭建的每一步。

在這篇內容中，他系統拆解了 Palantir 的 FDE 模式到底是什么，以及為什么它會在今天這個 AI agent 時代，成為創業公司值得重新審視的組織樣本。

??關注 Founder Park，最及時最干貨的創業分享

Founder Park 正在持續尋找值得被看見的 AI 團隊與項目。

我們將通過「AI 產品市集」、內容報道、社群分發等方式，幫你觸達早期用戶、獲得真實反饋，以及建立關鍵連接。

如果你正在做 AI 相關的事，歡迎和我們聊聊。

01到底什么是 FDE？

Host：幾個月前 Bob 參加了 YC 組織的一個 AI 會議，一個有意思的現象是，他原本以為所有的創始人都會來找他談論 ChatGPT，但結果所有這些創始人都想和他談 Palantir 的 FDE。到底什么是 FDE，以及為什么今天 FDE 變得如此重要？

Bob:不只有那一次會議是這樣。在過去一年我為 AI 初創公司提供咨詢時，他們中的很多人幾乎只關心 FDE 策略是如何運作的。

FDE 通常是一位技術人員，他會駐扎在客戶現場，填補產品功能與客戶需求之間的差距。

作為創業公司，你首先會有一個產品，然后你去接觸一個新客戶，并與新客戶嘗試合作，他們希望你解決的問題是你以前從未解決過的問題。

在這個過程中，你相信只要通過努力就可以為這個特定客戶解決特定的問題，并且你會為他們提供一個非常有價值的成果（outcome）。

所以 FDE 是帶著現有的產品，并在產品團隊的幫助下，想辦法交付那個成果，構建對客戶有價值的用例（use case），以一種對客戶真正有效的方式交付你已經構建的軟件。

Host:復盤一下 Palantir 是如何發明 FDE 這個策略模式的？

Bob:Palantir 剛創立的時候，公司的重點是為情報部門搭建軟件系統。這件事的挑戰是，我們不認識任何情報工作人員，現實世界生活中幾乎沒人認識，并且即便我們找到這樣一個人，如果詢問對方：「你的工作內容具體是什么？」對方也不可能告訴你的。這倒逼我們必須采取一種在當時非常不尋常的方法來完成工作。

我們是從構建一個 demo 開始做這項任務的，先嘗試把那個 demo 展示給情報界的潛在客戶、收集反饋。

Palantir 的創始人之一 Stefan Cohen 就做過這件事，他給潛在客戶展示 demo，問他們：「你們覺得怎么樣？」對方說：「這個產品太糟糕了，和我們做的事情完全沒關系。」Cohen 就會繼續問：「那你們希望它有什么不同？」然后他們會說：「你能做這個改動和那個改動嗎？」于是 Cohen 就把所有這些都記下來。

理想狀態下，創業早期我們必須得大量做無法規模化的事，走出去拜訪客戶、研究用戶，等到找到 PMF 后，我們的策略就會改變，變成與用戶拉開距離、專注于規模化、并對所有客戶一視同仁。

如果某個創始人所處的行業能這樣順利實現規模化，那么他根本不需要 FDE。但對于當時的 Palantir 來說做不到。

FDE 的做法其實是 Shyam Sankar（Palantir 早期成員，現任總裁兼 CTO）提出的。

我們發現每家客戶要的東西都所有區別，與其給每一家單獨做一個版本，或者補一堆只適用于特定一家客戶的功能，不如把產品做成高度可定制的平臺，這樣一來，就必須把員工派駐到現場，深入理解用戶并做本地化改造。

按傳統觀念，這些都算服務（Services），在 PMF 范式的框架里最好少做。

但 Shyam 把這套邏輯倒過來：讓 FDE 充當產品探索（Product discovery）的過程。

FDE 帶著現有的產品進場，去填補產品能力與實際需求之間的 gap，把路線先鋪成一條「碎石路」（Gravel road）。總部的產品與工程團隊再把這些現場做法抽象、泛化，修成能服務接下來五到十個客戶的「高速公路」（Paved superhighway）。

Host：在 Palantir 是工程師們直接面向企業客戶而非專業銷售，這是怎么形成的？尤其當我們面對的客戶是政府和國防部門時，大多數人會傾向于去雇傭一批經驗豐富的、長期和政府官員打交道的銷售人員，但 Panaltir 并沒有這么做？

Bob:有兩個方面的原因：

一方面，我們早期和很多那樣的人接觸過，他們的反應是：「我為什么要去和一個硅谷公司合作，而不去和五大國防承包商之一合作？」

另一方面，這類人的背景看似可以勝任這個工作，但我們其實很清楚他們無法融入我們的文化，也無法真正成功。當我們嘗試那樣做時，幾乎從未成功過。

所以我們發現了一種非常不同的方式。我認為銷售主導的產品探索和 FDE 主導的產品探索之間的區別在于，銷售主導的產品探索是你從外部與人交談。而 FDE 主導的產品探索更有效，因為 FDE 是從內部解決這些問題。

要專注于解決領導層確定的關鍵問題。如果你解決的不是 CEO 的前五大 priority 之一，那可能就不會成功，他們沒有精力堅持走完這條更具挑戰性的路線，也就是把一個全新的產品能力按他們的場景真正落地。

一旦你解決了第一個關鍵問題，那么 FDE 就可以在企業中發現其他關鍵問題，有時可能是比你最初目標更有價值的問題。也許 Palantir 或你的公司能否解決這些問題并不明顯，但一旦你在那里，你就能通過產品洞察力看到你實際上可以做到這一點。然后再去解決那些問題。

所以，這就從「我如何向每個客戶銷售同樣的東西」轉變為「我如何落地并擴張」（land and expand）。

Host:進一步講講 Palantir 的 FDE 模式是如何運作的？

Bob:首先需要思考的第一個問題是 FDE 團隊是如何構建的，這里面有兩個關鍵角色，我們稱之為 Echo 團隊和 Delta 團隊。

Echo 團隊具體來講是 embedded analysts，他們會去客戶現場，與用戶交談，試圖找出什么樣的 demo 或 use case 對這個場景的用戶真正有價值，可以解決的關鍵問題是什么。與此同時他們也是客戶經理（account managers），所以他們也會是管理客戶關系的人。

Delta 團隊作為部署工程師，實際上就是軟件工程師，這些人通常非常擅長快速編寫代碼，是把那些想法帶入現實世界落地的人，他們構建解決方案、原型，然后落地為能實際運行的產品，最終為客戶進行部署。

所有這些都會在很短的時間內完成。FDE 團隊帶著一個要做的項目的想法進去，并設定好幾個月后要向領導層做一次 demo，展示他們的進展，如果那次演示順利，就會真正部署，走向客戶的全組織范圍。

02如何構建一個 FDE 團隊

Host:這兩個角色的有趣之處在于，他們是完全不同類型的人，有不同的背景。你如何找到合適的人來擔任這些角色，因為不是隨便一個普通工程師就能勝任 FDE，他們需要更多與用戶交談的能力，或者 Echo 團隊也需要更強的技術背景，而不僅僅是客戶經理。Palantir 是如何建立 FDE 團隊的？

Bob:Echo 團隊的理想人才畫像是某個領域的專家。比如可能是一位前陸軍軍官，或者是在醫療保健領域有深度工作經驗的人。他們有深厚的領域知識。除此之外，還有一點非常重要，Echo 團隊成員需要具備「反叛者（rebel）」的特質，，Sham 甚至會稱他們為「異端（heretics）」，這些人不僅了解現有的做事方式，而且能夠認識到這種方式不夠好的點在哪里。因為如果看不到問題，就永遠無法想出新軟件以及它們帶來的那種階躍式變化。

對于 Delta 團隊，我們需要的是非常擅長做原型（prototyping）的人。

Delta 的錯誤人選是那些有完美主義的工匠型人才，這種人很擅長寫代碼，喜歡抽象（abstractions）層面的絕對正確，希望他們構建的軟件在未來十幾年都能維護。

而我們真正想要的是那種能想辦法進行產品實現的人，即便他們寫的代碼很粗糙。有時候，如果找到了對的人，他們寫的代碼也很優美，但大部分情況下不是，并且這件事不是 Delta 團隊的核心，Delta 團隊是能在規定時間線內以軟件形式實際交付成果的人。即便他們寫的第一個版本質量并不高、要推倒重來，但他們很擅長做原型，這是這個團隊的關鍵技能。

Host:Echo 和 Delta 的人才畫像聽起來很像一個創業團隊。Palantir 會招聘一些前創業公司創始人，讓他們來擔任這些角色嗎？還是說情況大多是反過來的？

Bob:Palantir 孵化出了數量驚人的創業公司，這并非巧合，因為 FDE 培訓就是成為創業公司創始人的培訓，你其實正在學習所有創業公司創始人的技能。當年我們剛開始做這個的時候，并沒有大量的創始人可供我們選擇。

Palantir Mafia：Palantir 前員工、早期合作者與投資人已經形成了緊密的校友網絡。他們在私密群（如 Palantir Pals）里互通招聘與融資信息，還會組織線下活動（如索諾瑪俄羅斯河露營），形成了強大的人脈與資本圈。Palantir 前投關負責人 Luba Lesiva 還發起 Palumni VC 專投校友公司

Palantir 校友已創辦或掌管 350+ 家科技公司，其中至少十多家達獨角獸級別。代表公司和人物有：

?國防科技公司 Anduril（創始人 Trae Stephens、Matt Grimm、Brian Schimpf 均為 Palantir 校友），2025 年 6 月估值約 305 億美元

?數據分析協作平臺 Hex（創始人 Barry McCardel、Caitlin Colgrove、Glen Takahashi 均為 Palantir 校友）

?公共安全數據平臺 Peregrine（創始人 Nick Noone 曾領導 Palantir 的特種作戰業務，2025 年 3 月融資后估值約 25 億美元）

?醫保導航與經紀平臺 Chapter（創始人 Cobi Blumenfeld-Gantz 為 Palantir 校友）

?AI 語音公司 ElevenLabs（聯合創始人 Mati/Mateusz Staniszewski 為前 Palantir FDE）

?數字合約平臺 Ironclad（聯合創始人 Cai GoGwilt 為前 Palantir 工程師）

?數字化健康險 Angle Health（創始人 Ty Wang 與 CTO Anirban Gangopadhyay 均為 Palantir 工程師出身）

?金融科技 Blend（創始人 Nima Ghamsari 早年就職于 Palantir）

?開發者工具公司 Sourcegraph（CTO Beyang Liu 曾在 Palantir 任工程師）

?銷售智能公司 RelateIQ（聯合創始人 Adam Evans 曾在 Palantir 創建健康業務）

你說的很對，FDE 團隊在每個客戶現場所做的事情確實有點像是一個創始人，但 FDE 成員的區別是他們一個可以接觸到一些非常強大的產品杠桿（product leverage）的創始人，這讓你的工作更容易。我認為這是很好的培訓，這也可能是為什么市場上現在會看到這么多來自 Palantir 的創始人。

03FDE 不是咨詢，做通用產品同樣重要

Host:那些不太了解 FDE 的人經常會說：「這只是用花哨的營銷話術包裝起來的咨詢業務。」，為什么這種說法是錯的？

Bob:客觀來說 FDE 確實存在著成為那種情況的風險。如果在 2015 年和人們談論 Palantir，你可能會主要聽到兩件事：

?第一，Palantir 是邪惡的（Palantir is evil）（備注：Palantir 早期和情報部門合作，做的是間諜有關的業務），

?第二，這是一個永遠無法規模化的咨詢業務，它不是一個軟件公司，而是咨詢公司。

在過去我們其實花了很多時間試圖理解這種評價是否正確。

從商業模式上，我們會看到的一個關鍵趨勢是：當我們去一個新客戶那里做新項目部署時，在一開始我們可能實際上是在虧錢的，但隨著我們在客戶那里待的時間變長，我們的產品因為產品探索而變得更適合客戶的需求，從而我們不再需要一個龐大的團隊在客戶現場搞清楚客戶需要什么。同時會像 Sham 所說的那樣，我們會逐漸贏得接觸客戶現場的更重要問題的權利。

所以最后的結果是我們會看到交付成果的單位價值成本（cost per value）在下降。也就是說我們的利潤率（profit margins）開始時是負的，但最終在一段時間后，可能是一年，也可能是幾年后，會變成正的。

如果從這個角度看，我們就會發現我們實際上在交付真正可重復的價值。產品團隊是能讓這個模式運作起來并降低成本的一個關鍵。

Host:產品團隊是如何與 FDE 團隊合作的？

Bob:Palatir 有兩個核心團隊，一個是 FDE 團隊，另一個是產品管理（product management）團隊。

我們構建的產品不是高度垂直化的，不是 Airbnb 那樣可以同時支持數百萬人需求的標準流程。產品團隊的角色是去真正地把握產品愿景（product vision）。所以他們必須思考，在客戶現場看到一個新問題時，它的通用形態會是什么樣的，什么樣的版本可以應用于接下來的 10 個客戶。

一個典型的失敗例子就是，就是 FDE 為一個客戶實現了一些東西，然后就直接把它引入到所有產品中。結果是 FDE 構建的東西對于其他客戶來說過于特化了。這里的關鍵在于擁有能夠構建更通用產品的能力的產品人員。

Host:所以需要一些 know-how 來判斷它是只適用于這個垂直領域，還是可以推廣，給我們舉個具體例子？

Bob:可能最好的例子就是 Palantir Ontology 的發明。

當我們最初考慮與美國政府，尤其是情報機構合作時，本能的做法是：給「人」建一張表，給「資金」再建一張表……

但很快就發現，沿著這條路走，一旦要在不同機構和客戶間部署，就會遇到無法通用的問題。于是我們把抽象層級拉高，不再預設具體對象類型，而是讓 FDE 按每個客戶的語境去定義。底層只提供通用的對象、屬性等，Palantir Ontology 就是在這種思路下誕生的。

Host:現在 Ontoloy 是如何運作的？是有一個包含像人和錢這樣通用可復用對象的基礎數據庫模式（database schema），然后根據每個站點進行定制嗎？

Bob:數據庫模式本身極其通用，只保留：對象（objects）、屬性（properties）、媒體（media）以及對象之間的鏈接（links）。

我這里指的是 Palantir 的政府產品（也是我們的第一個產品）。至于每個客戶場景下的具體語義，則由 Ontology 來編碼，例如把某個實體標注為「人」、把某個實體標注為「船」、或把一組關系標注為「資金流」。

如果我們只面向某一家客戶構建功能，就會被這個客戶的表述方式綁架，比如就會去想「對于人我們就這樣做」。而正確做法是把抽象層級再往上提：思考「我們是否有一個對所有擁有某種屬性的對象都適用的通用操作？」，比如「人」和「船」也許都具備某種屬性，但付款記錄并不具備，那處理邏輯就不能一刀切。這要求你始終在更高的抽象層上思考。

我們很長時間都沒有招聘產品經理，等到需要招產品經理時，我面試過不少在其他公司非常優秀的人，但讓他們在這種抽象層級上思考并不容易。很多人會直接落到「給這個客戶設計一條具體流程」上，但這件事在 Palantir 的模式里是錯的。他們需要把視角抬到本體層，思考在本體框架下該如何調整建模，使某個專用功能能夠跨客戶復用。

04為什么 FDE 是 Agent 時代的 PMF？

Host:今天幾乎這些 AI 公司都在大規模招聘 FDE，你認為背后的原因是什么？為什么上一代 SaaS 公司們沒有這樣做？即使在 Palantir 成功并且 FDE 模式變得更加知名之后，FDE 仍然被視為一個特例，因為大家認為 Palantir 是一家獨特的公司，是向政府銷售的公司。

Bob:我也很驚訝于這個趨勢。但我對于那些在考慮嘗試 FDE 策略的人的建議是：如果不是一定需要 FDE，就不要真的親自嘗試這個，因為有可能會最終變成做服務（service）。如果經過一系列嘗試發現不做 FDE 就一定會失敗的話，那么 FDE 可能是你所在市場唯一可能行得通的方式，并且它可能對你來說就是一條護城河。

至于今天的 AI agent 市場中為什么會出現 FDE 這個趨勢，也許可以回到這個問題上進行討論，為什么 Palantir 必須采納這個模式。

Palantir 的市場不是一個單一連貫的市場，我們與國家情報機構、國家執法機構、軍方合作。盡管所有這些組織都有一些類似的項目，但即使是反擴散工作流程（counterproliferation workflow）和反恐工作流程（counterterrorism workflow）之間，也存在差異很大差異，一個是查明誰在制造核彈，一個是查明誰在制造簡易爆炸裝置，它們在運作方式上實際上有很大的不同。

所以這里存在著巨大的異質性（heterogeneity），我們應該把市場看作是不同的細分市場（segments），在每個細分市場內部，你可以構建一些東西，《跨越鴻溝》的故事在一定程度上可以適用。

開始時似乎什么都不起作用，突然間你在某個細分市場找到了 PMF，你可以部署給做這類工作流程的人。然后在下一個客戶那里，你發現同樣的人在做類似的工作流程，你可以用很少的定制化就完成部署。

所以現在你想去攻克一個不同的細分市場，你必須開發一項新技術，然后這項技術可以在其他細分市場中被引用。一個細分市場不一定等同于一個客戶，特別是在企業或像政府這樣非常大的企業中，一個客戶可能意味著數萬名用戶。在那種情況下，FDE 策略就很重要了，因為你在做無法規模化的事情，但你是可擴展地、一遍又一遍地為你進入的每個細分市場做這件事。

我認為 Palantir 的另一個獨特之處在于，我們正在構建一種全新類型的產品。

用戶習慣于用一種看起來像 PowerPoint 的工具來做分析和追蹤人員，他們通過互相來回發送這些文件進行協作。但我們構建的產品基本上是說：「當你在繪制那個鏈接圖時，你不僅僅是在編輯一個文件，你實際上是在改變一個數據庫，而且每個人都有同一個數據庫。」雖然對用戶來說，這看起來是在他們正在做的工作之上的一個小改動，但對于我們銷售的企業、組織來說，這是一個完全不同的市場類別。

我認為這就是 AI agent 正在發生的事情，這是一個全新的市場類別。

如果你在實施一個標準的 SaaS 產品，你用一種不同的支付賬單的方式取代了另一種支付賬單的方式，每個人都明白那個市場是什么。這樣的細分市場沒有那么多細小的劃分，也沒有那么多的同類項產品的探索，你嘗試做一個比現有產品更好的產品，并通過取代現有產品來做規模化。

當對于 AI agent，沒有現成的產品。構建 AI agent 實際上可能意味著很多不同的事情，而我們還不知道那些是什么，我們得去弄清楚。甚至可能五年后我們回過頭來看，會覺得 AI agent 根本就不是一回事，我們實際上在做所有這些不同的事情。

所以這就是我認為為什么你看到 FDE 模式正在興起，因為有太多的產品探索工作要做，而且你只能從企業內部去做。

Host:這和經典的 YC 建議「do things that don't scale」之間有什么關系？

Bob:那是 YC 給早期創始人的建議，而 FDE 模式實際上是在大規模地做那些不規模化的事情。

Host:現在很多人都在嘗試采用 FDE 模式，包括很多沒有在 Palantir 工作過的人，你有看到人們在哪些方面做錯了嗎？

Bob:我目前看到的最成功的做 FDE 模式的創業公司，都有來自 Palantir 的人去負責運營 FDE 模塊。

就像我說的，工程團隊通常非常相似，但實際的 FDE 運作機制：如何建立這些客戶，如何定義結果等等這些與標準軟件公司實際上有很大的不同。

其中一個關鍵的區別，也是我認為人們很難理解的一點是：如何選擇一個問題，然后如何為那個問題定價。從根本上說，用 FDE 模式銷售的不是具體某個軟件的安裝過程，你銷售的是一個成果。就像 Sham 會說的，你銷售的是你解決了一個問題。

Host:在 SaaS 時代，你會根據使用量、訂閱或席位來定價。而 FDE 完全不同，是基于成果，所有這些 AI 創始人應該如何為他們的解決方案定價？

Bob:是的。我認為 FDE 模式和標準 SaaS 模式之間一個非常重要的區別是，對于 SaaS 模式和 PMF，人們趨向于非常簡單、可重復的合同，非常簡單、可重復的定價，這在所有客戶中都說得通，而且通常 SaaS 團隊對小金額合同會很滿意，因為部署的邊際成本（marginal cost）非常低。

而在 FDE 模式下，業務交互則會被推向越來越大規模的合同。就像我們前面談到的，隨著時間推移，每個客戶的合同額都會增長。因為產品需求很復雜，合同也會很復雜，而且產品和合同也需要更靈活（flexible）和有彈性來適應復雜度。

Host:一些 YC 公司也開始這樣做了，比如 Kastle 是為銀行客戶提供抵押貸款服務的 AI 語音 agent，他們把成功處理所有這些抵押貸款請求的電話數量作為衡量成果，合同規模也在逐步增加。Happy Robot 主要是做物流領域的 AI 語音 agent，和 DHL 這樣的大公司合作，情況類似。

Bob:這里存在一種創業公司和銷售對象（通常是大企業）之間的不對稱性。

當 startups 向大型企業進行銷售時，首先企業客戶經常不相信自己真的能完成任何事情，那是因為他們經常有很多失敗的大型項目，并且他們也不相信創業團隊能完成任何事情，因為他們認為你這個創業公司和他們一樣。

而創業公司知道自己實際上能夠執行能夠落地，所以，在早期，創業公司承擔所有風險是合理的，然后提出，「我們就是相信我們自己的執行力，我們會承擔風險，如果成功了你再付錢給我們，或者當我們能夠擴張時你再付錢給我們。」

Host:這一點可能出錯的地方是，如果 startup 做的東西需要部署到企業內部，做 on-premise，甚至只要其中任何一部分需要在本地，就會出現需要和企業內部 IT 團隊之間的爭論和協調。

Bob:我們也在一些公司看到了這種情況。這個問題可能是，一個 FDE 項目的成功需要贏得組織內部的那些支持？因為那些人不像創業公司那樣思考，他們和終端用戶利益不一致。所以必須想辦法繞過他們。

這就是為什么創業公司要做 FDE 的話必須聚焦于解決 CEO 的前五大問題之一這點很重要，因為在遇到組織內阻礙時，需要能夠從高層引入某個人說：「是的，給他們操作的權限、他們需要使用這種特定類型的數據庫......」

Host:Palantir 是如何在合作中獲得對方企業高管支持（executive buy-in）的？

Bob：核心是需要在 FDE 團隊中有非常出色的領導力，才能有那種紀律，并且分享有效的方法，在一個客戶那里實踐這個紀律和方法。

我認為這并不是特別神奇而難以做到的事情。我看到的做得最好的公司，都是從那些以前做過的人那里借鑒來的，這是可以學會的，我們就是學會的。

Host:YC 有一個概念叫 Collison install，我們基本上把它歸結為，不要等著人們來你的網站，你要去找他們，讓他們安裝軟件，親自去他們那里，去他們的辦公室，坐在他們旁邊。我覺得這一直是一個很好的起步策略。

但大多數創業公司一開始并不能拿到大合同。所以實際上，他們不得不停止這種手動、高接觸度（high-touch）流程的原因是，如果沒有一個能夠規模化的產品，你根本無法維持增長率。這有點像我們之前談到的，在某個時候，你希望你構建的產品足夠好，人們可以自己搞定，然后你所有的問題就只是規模化的問題了。

而對于 AI，不同之處在于，因為這些合同現在非常大，你實際上可以通過做這種高接觸度的事情走得很遠。我經常被問到的一個問題是：「我能把這種方式推得多遠？」我的建議大體上是：「為每個客戶做定制工作是可以的，你只是希望每個客戶的定制化程度越來越低。」

對于這件事你是怎么看的？你怎么知道繼續以這種高接觸度的方式增加新客戶是可以的，還是說實際上我需要開始抽象化，構建一個真正的產品了，什么時候需要改變策略？

Bob:是的。我認為這其實概括了 PMF 策略和 FDE 策略之間的關鍵區別。

在 PMF 策略中，團隊會希望為每個客戶做的工作越來越少、降低成本，保持合同規模不變。

但在 FDE 策略中，預期會變成提高合同規模，提高合同規模意味著你為這個客戶以及未來的客戶做越來越有價值的工作。因為你正在做更有價值的工作，所以沒關系，你可以保持每個客戶的定制化程度不變。

Host:所以 KPI 是合同規模，而不一定是他們為每個客戶做了多少定制工作？

Bob:這里有兩件有用的事情。

第一，你能衡量的事情，是合同規模。我甚至會說得更通用一點，即你交付的成果的價值，因為那才是真正的東西。如果你能夠為客戶交付越來越有價值的成果，那么你就做對了。

第二部分是產品的價值。所以要衡量的另一件事是，你是否正在獲得越來越多的產品杠桿來放大那個成果。

當我們身處其中時，這一切都非常反直覺。

如果正在做 FDE 模式，或者領導了一個 FDE 團隊，有很多必須做的事情看起來非常反直覺，這非常困難，因為你必須為客戶構建他們沒有要求但實際上想要的東西。

而在產品方面，則需要去想，如何做一個對每個客戶都非常容易使用的產品。因為如果要關注用戶體驗，就必須這樣做，但與此同時也必須記住你的另一個關鍵客戶是 FDE。你的產品最終應該在 FDE 定制后為用戶提供好東西，產品應該為在客戶現場交付那個成果的 FDE 提供杠桿，而且產品杠桿的數量應該隨著時間的推移而增加。

Host：就像 FDE 應該能夠用你的產品為客戶交付更多價值，而不需要 FDE 去再拉三個工程師進來才能做到。

Bob:是的。如果你部署的第一個客戶需要大量工作，然后如果你想把同樣的成果賣給另一個客戶，那么應該會容易得多。當你一個客戶一個客戶地做下去時，應該會變得越來越容易。

但是記住 FDE 應該是去構建一個平臺，所以你做的不僅僅是一堆垂直用例的疊加。你需要去正確地抽象出了你真正在構建的核心概念，這樣你做事情也會更容易，你會有更多的產品杠桿，即使你不是在做那個用例，而是在做一些類似的事情。或者你會發現，如果你的產品真的很好，你的 FDE 們能想出一些新的方法來使用你構建的技術，去解決一些完全不同的問題。

Host:這幾乎像是一種內部市場動態在起作用。如果你構建得非常好，那么 FDE 應該會選擇使用它，你應該會看到 FDE 對使用你那種抽象產品的需求，而不是他們自己去做一個一次性的解決方案。

Bob:是的。不過我想指出，這對所有相關人員來說都是一個非常痛苦的過程。在 FDE 的世界里，我可能用再多痛苦這個詞都不夠。

有很多次，我構建了一些我認為很棒、很漂亮的東西，還沒到那一步，但我認為它真的能幫助 FDE 們，只要他們有能力看到它。我會說：「請用我的產品。」他們會說：「不，這工作量太大了，根本沒用。」

老實說，大多數時候可能是我錯了，我為他們構建了錯誤的產品，我應該看到這一點。但有時我也是在正確的軌道上，只是我做得還不夠，沒有讓 FDE 們更容易使用。所以，我會派開發人員到現場去部署那些早期的解決方案，幫助它們過關。

Host:FDE 是持續有效的嗎？還是說，創始人有時應該自上而下地決定，說：「我就是想讓你這樣做」？

Bob:這兩種做法在不同情境下都可能是對的。這里的正確答案在很大程度上是一個判斷問題。

回到這個關于產品愿景的問題，從一個客戶到接下來三個，再到接下來十個，什么樣的產品才是正確的通用產品？當你看到第一個客戶時，你真的沒有回答這個問題所需的信息。所以這純粹變成了一個判斷問題。

Host:在 SaaS 領域，工程師們很抵觸 demo 驅動的產品開發（demo driven product development），但在 FDE 語境中，demo-driven 是很重要的？

Bob:實際上，我認為如果你有正確的產品類型，demo 驅動的開發效果非常好。

在 Palantir 的早期，我們實際上只有一個 demo，是一個你正在阻止恐怖分子陰謀的流程。我們開始時只用了一個功能，每次我們集成一個新功能時，我們都要思考，我如何展示這個新功能，是對于正在經歷這個演示、正在阻止這個陰謀的分析師來說是真正有幫助的？當我們集成直方圖時，我們必須說，我們實際上如何使用它，它如何與我們已有的功能協同工作？我們集成地圖時，也有同樣的問題。

如果你從「我正在構建什么」的角度來看世界，那么你考慮的是你的能力，你可能會單獨考慮每個功能以及如何構建這些功能的最佳版本。但當你在構建一個 demo 時，你是從客戶的角度來思考的。

一個好的 demo 是，你展示給客戶，并且你在客戶心中創造了對你所做事情的渴望。他們必須看到你所做的，并且就是想要伸手去抓住它，把它帶入他們的生活。如果你看到這一點，那么你就知道你已經發現了客戶的一個真正痛點。通過這樣做，也迫使你開發更好的產品，因為你不僅在思考每個功能單獨來看是否有意義，而且還在思考它們如何協同工作。

如果我要一遍又一遍地展示這個 demo，即使只是從一個功能移動到另一個功能這樣簡單的事情，也必須非常直接。這些都是你經常會看到，但通常是在你真正部署給客戶之后才會看到的產品痛點。所以 demo 的作用是，它改變了你思考的焦點，從思考「我能構建什么」轉變為「客戶想要什么」，以及「我是否正在為客戶解決那個痛點？」

Host:聽起來這有點像，你必須在這個非常非常高維、多維的空間中持續進行梯度上升（gradient ascent），并且不斷改變變量（一個數學比喻）。

Bob:是的。也許這是一個非常關鍵的點，那就是你必須建立的公司類型是一家學習型公司（learning company），我想每個人都想建立一個學習型公司。

但如果你是像谷歌或 Meta 這樣的公司，不學習是很容易的，因為你現在做的事情正在奏效。如果你只是繼續做下去，市場在增長，每個人都想做你正在做的事情，你可以就這么靠著同樣的策略混下去（Coasting），而且它還在為你帶來回報。

我對那些考慮加入哪家公司的人的建議是，我告訴他們加入一家年輕的公司，不一定是小公司，而是一家年輕的公司。因為一家年輕的公司還在摸索，還在學習，它還沒有成功。如果你剛大學畢業，你應該加入一家成長非常快的年輕公司，然后你就會看到成功是什么樣子的，這正把你定位為以后自己公司的創始人。

這就是為什么 Palantir 孕育了那么多其他創業公司的原因，因為它即使作為一家非常大的公司，它仍然是一家每個人都在一直學習、專注于學習的公司，并且總是和創業公司一樣勤奮工作。

Host：你最近加入了另外一個超大組織，美國陸軍預備役。有哪些來自 Palantir 的經驗可以在這段經歷中得到應用？

Bob:陸軍領導層與我們在 Palantir 早期與他們合作時的感覺非常不同，在當時（2005 年或 2010 年左右），陸軍管理層已經闡明了陸軍轉型的計劃，他們明確知道軍隊需要從伊拉克、阿富汗的戰爭形態轉變為今天在烏克蘭的戰爭形態，或者說如果我們在太平洋面臨大規模作戰行動會是什么樣子。

當他們引入 Palantir 時，他們給我們指明了陸軍的優先事項，給我們每個人分配了一個我們應該運作的領域，但他們也給了我們自由，去四處尋找問題，直接與基層的軍官合作解決那些問題，或者如果需要，就上報給領導層并解決它。

所以我認為其中一件非常有趣的事情是，在很多方面，這確實很像在陸軍上運行 FDE 策略。我們得以看到，什么是領導層的五大優先事項？我們能否在這些方面取得進展？但同時，在一個你看到領導層想要的和 20 年來的實施方式之間存在脫節的世界里，改變需要很長時間。所以，我們正在幫助他們做出改變。我真的很渴望能有機會在那里做出貢獻。

Host：你認為現在對創業公司創始人來說最好的機會是什么？

Bob：我認為這真的回到了為什么 AI agent 正在采用 FDE 策略這個問題上。

今天我們看到的趨勢是 AI 能力提升實際上非常快。有觀點說人們在 GPT-5 之后覺得 AI 有些停滯不前了，但如果看 2024 年 4 月最好的模型，GPT-4o 的發布，到 2025 年 4 月 o3 的發布之間這段時間，其實是一個非常快的進步速度。我認為這個趨勢繼續下去，我們將看到 AI 模型能力繼續快速發展。

但真正令人震驚的是，但 AI 采用速度（adoption）遠沒有能力進展快。極大可能是，未來 5 年世界 AI 能力不斷飛速前進，但我們在現實世界卻感覺越來越平庸。這就現在我們坐在 Waymo 里不會想「天哪，無人駕駛已經實現了！」，而是「交通真堵，真慢」。

FDE 的機會在于當下一個很好的填補 AI 能力實際上能做什么和客戶能夠采納什么之間 gap 的 timing。AI 被大規模應用是需要方法論的，它不是自己就會發生的事情，這件事要求人類的創造力、探索，以及應對大量的問題才能實現。所以我認為，看看現在有哪些能力，但如何讓它們對人們真正有用，這方面有巨大的機會。

Host：我想到一個類比，可能有點牽強，但就好像 OpenAI 是本部產品團隊，而創業公司們是 FDE，在外面想辦法讓 OpenAI 在本部辦公室里研發出來的研究成果被采納。

Bob：我認為這個類比一點也不差。我認為，這也許是讓整個 FDE 策略再次變得熱門的原因。

轉載原創文章請添加微信：founderparker