我們目前有三分之二的部署工作，是由自家產品透過 Duet 自主完成的。
這篇文章要談的是為什麼會這樣、我們對「打造產品 + 部署模式」的理念，以及這件事隨著時間如何演進。
我們曾經看不起的事，如今成了預設答案
「Forward deployed engineer（前線部署工程師）」幾乎成了 AI 進入市場時所有疑難雜症的標準答案。部署很痛苦？找 FDE。客戶無法自助？FDE。產品還沒準備好？FDE。Anthropic 和 OpenAI 都成立了明確以 Palantir 為藍本的企業部署部門，而我聊過的每一家種子輪公司，現在都有 FDE 的職缺。據說這類職稱的職缺數量在過去一年增加了數倍。
奇怪的是，直到最近，這種做法還是件會讓你挨罵的事。把工程師派到客戶端，會被視為你沒有真正產品的跡象：你的營收品質較低，而且毛利在結構上被封頂。但底層的經濟邏輯其實一點都沒變。
FDE 的關鍵在於他們能交付成果。在 AI 時代這點非常棒，因為企業可能不確定通往成果的路徑是什麼，但很清楚 AI 能帶來極具說服力的成果。
但與此同時，這個角色也正被過度使用，不該成為掩蓋結構性問題的拐杖。
「FDE 吞下痛苦，排泄出產品」
Palantir（我的共同創辦人 @AshwinSreenivas 就是從那裡出來的）在 2000 年代中期把這個角色發揚光大，把 Gotham 賣進 CIA、NSA 和陸軍情報單位。而他們長期承受批評。共同創辦人之一 Joe Lonsdale 曾寫道，在將近二十年的時間裡，主流對 Palantir 的看法是：它是個被美化的顧問公司，而不是真正的科技公司；而這種看法其實是基於一個真實的觀察——他們有很多工程師花了大量時間坐在客戶旁邊。
但 Palantir 的技術長 Shyam Sankar 有一句他經常重複的話：FDE 吞下痛苦，排泄出產品。
Palantir 早期部署 Gotham 的方式深度客製化，是為了回答某個單位的某個情報問題而打造。Palantir 把這些問題編碼成平台的原生元件：本體論（ontology）、物件模型、權限管理、工作流程引擎、來源追蹤。這些元件後來變成了 Foundry。Foundry 變成了可以商業化銷售的東西。Apollo 和 AIP 也走了同樣的路。
如果沒有工程師先在第一線吞下痛苦，這一切都不會存在。痛苦是產品的輸入，而不是銷售成本。
隨著 Foundry 成熟，標準化部署大幅減少了客製化工作的需求，毛利率攀升到八成以上，Palantir 也從 FDE 主導的模式，轉向以客戶帳戶為基礎的銷售。許多 FDE 轉往核心工程部門。他們也以拒絕某些合約聞名——那些客戶只是想要一家軟體好一點的 Accenture。
FDE 團隊不是商業模式，而是打造出正確產品的方法。
為什麼有些 AI 新創現在確實需要 FDE
如果你在 2015 年要打造一套 SaaS CRM，你不需要摸索工作流程。過去二十年早就有人想清楚了什麼是 pipeline、什麼是 stage、lead 交接長什麼樣子。
但如果你在 2026 年要打造一個給會計用的 AI Agent，市場上根本沒有既定的工作流程，因為真的沒有人用過這種東西。沒有人知道使用者旅程長什麼樣——你不知道，更重要的是，你的客戶也不知道。他們無法告訴你他們想要什麼，因為他們想要的東西還沒有具體形狀。
這正是 Palantir 當初面對的情況。Lonsdale 的說法是，他們之所以採用前線部署是出於必要：他們有很強的技術，卻完全不知道早期國防與情報客戶實際上是怎麼運作的。
所以，沒錯，把工程師派出去。坐在會議室裡。看著你的產品以測試時從未想過的方式壞掉。在真正全新的類別裡，最後一哩路不是交付問題，而是探索問題，親臨現場是無可取代的。
陷阱不在於開始，而在於沒有停止
一旦你真正知道使用者的旅程是什麼，你就應該開始把 FDE 撤離現場。
你會不想這麼做。這不是因為誰做了壞決定，而是因為在每個 sprint 裡，留住他們都比較輕鬆。
FDE 讓你可以避開所有困難的產品取捨。你永遠不必決定產品該做什麼、兩份客戶需求哪個勝出、或設定介面的邊界到哪裡為止。這感覺很自由。沒有人需要對任何人說不。不需要做出任何痛苦的架構決策。客戶也很滿意。
而現在，你得到了這個模式的所有缺點，卻沒有任何探索的好處。你的服務成本不會下降。你的毛利仍然被封頂。你的成長受限於招聘速度。每一次在客戶現場的客製化修補，都是你選擇不去做的產品決策。每一次部署，都應該讓下一次更容易。
除此之外，很少有新創能像 Palantir 那樣一開始就拿下八位數的合約，這讓這種經濟模式更難維持。
還有一件別搞混的事
FDE 也不等同於實施（implementation）。「把這個整合做進他們的工單系統」是真實且必要的工作，但那是按照已知規格執行，而不是探索未知規格。把兩者放在同一個職稱底下，是公司說服自己「持續擴大的服務團隊其實是產品投資」的方式。
模型現在寫程式的能力已經夠好，以至於 2023 年實施團隊做的很多事情，如今正變成產品自己就能做的事。到了某個時間點，你將能夠打造一個能端到端完成所有最後一哩路工作的 Agent。它可以觀察工作流程，甚至可以訪談客戶。
我們的做法
就我們 @DecagonAI 的具體情況而言，我們從根本上相信產品驅動（product-driven）的做法才是答案，而不是服務驅動或 FDE 驅動。客服是大量、可重複、可拆解的工作，而當我們和企業客戶對談時，有兩件事始終一致：
- 迭代速度是關鍵。 推出 AI Agent 不是一次性的事，它需要隨著時間不斷調整和更新。如果每一次微調都要動用工程資源，規模化的速度就會太慢、成本也太高。
- 廠商鎖定與自主權。 鑑於企業過去使用 SaaS 的經驗，沒有人想被鎖定在單一廠商、依賴他們的資源。
在早期，Ashwin 和我會親手打造客戶要求的任何東西。隨著產品開始站穩腳步，我們做了一個明確的決定：我們的核心價值主張（value prop）就是擁有最好的產品。
要說清楚的是，我們仍然與客戶合作，端到端地交付成果。不過，即使在這個過程中，我們也負責主導建置，同時讓客戶團隊能上手我們的產品，並把鑰匙交給他們。隨著產品日益成熟，我們工程團隊做的客戶特定工作已經大幅減少。
這個決定並非沒有代價。它意味著，即使在第一線拼湊出臨時解法會更快，我們也不這麼做；也意味著，我們把升級上來的問題轉化為產品需求，而不是打補丁，這在短期內很花時間。
回報是：
- 目前有三分之二的部署工作是透過 Duet 自主完成的：包括設定、迭代，以及過去需要人介入的長尾調校。
- 現在平均只需要幾天就能推出第一個 AOP，即使是大型銀行、航空公司、電信商等也不例外。
還有很多工作要做，但我們正在這條路上。
所以，到底要不要用 FDE？
早期就要採行前線部署。獲取訊號。讓你的工程師永遠站在客戶面前。
然後問真正的問題：這些客製化需求，是來自客戶的環境，還是來自你自己產品的缺口？最後一哩路是真的無法再縮減，還是只是尚未被建置？你的 FDE 是在發現些什麼，還是在吸收些什麼？而上次他們其中一人回來時，有什麼被做進了產品裡？
用 FDE 來弄清楚產品裡需要存在什麼。FDE 吞下痛苦，排泄出產品。如果你的 FDE 吞下痛苦，卻排泄出更多痛苦，那你沒有一個 FDE 團隊，你有的是一門服務生意。
