軟體工程師是全世界最不該站到客戶面前的一群人。Kevin Bai 自己也是軟體工程師，這句話他說得沒有一點猶豫。但他接下來要講的，正是把工程師直接送到客戶面前的一種商業模式：forward deployed engineering，簡稱 FDE。
他現在在 Anthropic 的 applied AI 團隊，掛的是 member of technical staff，他說公司技術上不太有職稱這回事。再往前，他去 Rippling 幫忙建立 FDE 團隊，是第一個加入的人，一年內把團隊帶到約 25 人。更早之前，他在 Palantir 待過一段時間。他把公司名單擱在一邊，因為這場演講談的是一個職能，不是一份履歷。
賣的是成果，不是軟體，也不是工時
Palantir 是一家技術公司，做的平台叫 Foundry。Foundry 讓各種規模的組織把資料集中到一個地方，建立一套 ontology。用他的話說，就是把資料變成「專有名詞」：不要 table 1、table 2、table 3，而要有一張「倉庫」表，當作倉庫這件事唯一的真實來源。蓋在這一層之上，Foundry 讓公司自己蓋應用。
問題就在這裡。拿這套說法去跟一位產業領導人解釋，對方的反應大概是：「很好，你把我的資料整理好了，但那對我的生意到底有什麼用？」只賣技術，話就講到這裡。
還有第二層麻煩。Foundry 是蓋應用的平台，這類平台的成敗，取決於客戶有多會用你的軟體。客戶付錢買平台只是第一筆，接下來還要花力氣把員工訓練到能用，然後才蓋得出東西。他說，這是一種很糟的做生意方式。
所以他們換了一個結論：不要只賣服務，也不要只賣產品，兩者綁成同一個東西來賣。客戶買的既不是一套軟體，也不是某個人的時間；他們要的是成果。你派幾個很聰明的人過去，搞懂客戶的生意，在 Foundry 上把解法蓋出來，最後交到對方手上的是那個成果。
如果客戶是消費品（CPG）公司的領導人，他在意的是貨架上的位置更好，或是銷售通路的吞吐量更高。資料怎麼被整理，他不在乎，也不該在乎，那是實作細節。
一張二乘二的表，只有一格需要 FDE
把工程師送到前線，這個念頭聽起來很怪。Kevin 用一張 Punnett square 解釋：一邊是你賣的東西，一邊是買的人是誰。
第一種，你賣的是很技術的產品。GitHub、Datadog 都算，軟體本身極其複雜，但理想客戶是 CTO、CIO，使用者是軟體工程師；這些人有能力吸收複雜度，因為那是他們工作的一部分。不需要 FDE。
第二種，你賣的東西沒那麼複雜，買的人也不技術。Rippling、Jira、Slack 大概是這樣，工具本身可能很複雜，但它是可以設定的，不是拿來在上面開發的。賣給不技術的買家，沒有問題。
還有一種，才是 FDE 的地盤：你賣的東西非常技術，買的人非常不技術。Palantir 就落在這裡。
石油公司的 pipeline 不是資料管線
為什麼會落在這裡？因為 Foundry 是蓋應用的平台，這件事對 Google、Meta 這類大型科技公司本來就沒什麼意思。Kevin 說，現在這些 lab 裡有很好的軟體工程師，組織需要什麼應用，他們自己蓋就好。
但當你賣給《財星》500 大裡一家做石油天然氣的客戶，情況完全不同。他們不會有那種工程深度。他的講法是，他們的 pipeline 不是資料管線，是碳氟化合物。
要讓這種客戶拿到平台的完整價值，有兩條路。一條是相信他們會自己花時間，把平台買回去、也用得起來。另一條是直接跟對方說：我們借你幾個很好的工程師，你不用自己招募、管理、留人。這些人受過平台訓練，會貼著客戶工作，像在高級餐廳裡一樣，服務生隨侍在側，先搞清楚你的問題在哪，再把軟體蓋給你。
Palantir 就是用這條路走進全球《財星》500 大。
ACV：第一名四百萬美元，第二名一百二十萬
他也給了數字。把《財星》500 大裡的公開 SaaS 公司排開，用 ACV 來比。ACV 是 average contract value，指的是單一客戶平均付給這家廠商多少錢。
Palantir 排第一，四百萬美元。他上次查的時候，第二名是 ServiceNow，一百二十萬美元；再下來他印象中是 Workday，六十萬美元。然後就斷了：沒有一家公開 SaaS 公司的 ACV 摸到五十萬美元。
他補了一句，Palantir 現在估值高得離譜，員工卻只有幾千人。
設計夥伴不只屬於新創早期
FDE 不是憑空冒出來的東西。新創早期有一種做法叫 design partnership：你還不知道自己產品是什麼，客戶也不知道自己買了什麼，於是雙方靠得很近。新創會跟客戶說：讓我貼著你工作，你只要把問題的脈絡給我，時間、精力、技術、資源由我出，我幫你蓋一個好解法。多數 B2B 新創就是這樣找到 product market fit 的。
Palantir 的核心主張，Kevin 把它講成一個反問：誰說設計夥伴只能用在公司的早期階段？為什麼不能把它放大到企業規模來做？
沒有平台，你開的是一家 dev shop
把設計夥伴放大，馬上會撞到一個很具體的反對意見：維護不了。如果每個客戶都客製一套，你會有一堆很爛的程式碼，工程師不想來上班，因為沒人想學 55 個 repo；公司的損益表也會被維護成本吃光。
Kevin 說這個反對意見完全正確，前提是你把 FDE 做成「每一個工程師都從零開始蓋」。如果是那樣，你有的不是 FDE 團隊，是一家 dev shop。
接案公司沒什麼不好，那是很賺錢的生意。FDE 之所以是另一件事，差別在平台：他們永遠不從零寫軟體，平台上已經有一組共用的基本元件（primitives），FDE 的工作是把這些元件組成一個應用、一套流程，或一個對客戶有價值的解法。少了這一層，你就是一次又一次重新發明輪子，維護成本會先把你壓垮，工程師可能還更早跑光。
先問需不需要，再問有沒有平台
想把 FDE 搬回自己公司的人，Kevin 建議先問兩個問題。
第一個是：我需要嗎？他強調的是「需要」，不是「想要」。想做的事很多，因為它正流行；想做 AI，因為別人都在做。但你的生意裡有沒有一個角落，是你非得把一個技術上很複雜的東西，賣給一個很不技術的買家？如果沒有，FDE 大概不適合你。如果賣的東西偏技術，可以好好經營 DevRel 和開發者關係；如果是比較傳統的 SaaS，可以走銷售驅動（sales-led）的路線。只有在那個特定的情況下，你才需要 FDE。
第二個是：我有平台嗎？或者換個問法，我願不願意投資蓋一個？他講得很重：不管這些工程師看起來多能幫你賺錢，只要他們不是蓋在一個有若干共用元件的平台上，你之後的日子會很難過。就算平台很強，維護負擔都已經重到很難形容，更不用說沒有平台。
2026 年的版本
演講後段轉到 AI。從 Palantir 進市場（他印象中是 2004、2005 年左右）到現在，最大的變化是 AI 讓寫程式變得很容易，讓替客戶做複雜、可客製的軟體也變得容易。他問台下有多少人在做「agent for X」，保險、法務，什麼領域都有；他說這題連舉手都不用看。
他的個人假設是：改變的不是大家終於發現 Palantir 的 FDE 路線是好主意，而是軟體業做生意的本質變了。現在幾乎每個平台都是 agentic，也就幾乎每個平台都可以客製；再往下推，幾乎每一個賣軟體的人都會遇到一種客戶：客戶根本不知道你到底在做什麼。如果你把產品的成敗交到客戶手上，交給他們的實作能力，那麼不管你是要往更大型的客戶賣，還是想橫向、縱向擴張，都不會是好走的路。
提問補上的實作細節
演講最後開放提問，幾個問題剛好問到實作上最容易卡住的地方。
共用的基本元件要切得多細？他說這取決於你的使用者是誰。有些產業和情境裡，元件可以很粗，應用本身已經完成六成，客戶只是改剩下四成；但也有些地方不合適，你需要非常細的設定和工具。他拿 AWS 當例子：你有本事自己買機櫃、弄上線、自己維護，但 1990 年代之後還有誰真的這樣做？AWS 給你一組共用的基本元件，例如 DynamoDB，你就不必從零發明一個資料庫。AWS 能這樣給，是因為它要服務的客戶分佈極廣。所以答案取決於你的使用者基礎。
一個案子派多個 FDE 好嗎？他說這很值得鼓勵。替客戶做客製工作時，最不想要的就是單點故障：只有一個人知道所有事情，他一放假，你就完了。
如果客戶同一個案子找兩家公司來做呢？可能是比稿，也可能是合作。他說這種模式存在，本質上跟請承包商沒兩樣，重點是要先分清楚在這種關係裡誰是承包商。
什麼東西該留在前線，什麼東西該進平台？他的分法很簡單：任何只屬於某一個客戶、獨一無二的東西，就只該存在於那個客戶那裡；任何可以一般化的東西，長期來說就該被一般化。他也提醒，剛開始做 FDE 的時候，你大概不會有太多共用元件，這沒關係，因為 FDE 本身就是很好的探路方式，幫你找出下一個能讓生意更好的產品能力。
FDE 就是一個會面對客戶的軟體工程師
有人問最理想的 FDE 該長什麼樣。Kevin 留給台下的是這句話：FDE 就只是會面對客戶的軟體工程師，沒有更多。你會用軟體工程師的標準錄取他，同時你又敢把他放到客戶面前；剩下的只能邊做邊摸，因為這是一門手藝。
要動手之前，先回答他開的那兩題：你的生意裡有沒有那個非賣不可的角落，以及你願不願意為它蓋一座平台。