FDE 該自建還是外包?企業導入 AI 前先算清楚的三筆帳

去年底,一家做智慧製造的中型企業找我們聊。他們的技術長開頭第一句話是:「我準備開三個 FDE 的缺,你們幫我看 JD 寫得對不對。」聊到第四十分鐘,我請他先把 JD 收起來,因為他要解決的問題,可能根本不需要自己養一支 FDE 團隊。

先把話說清楚。FDE(Forward-Deployed Engineer,前線部署工程師)不是傳統的內部 IT,也不是外包接案的工程師。他要能讀懂你的業務流程、進到現場改資料管線、把 AI 模型接上真正的生產系統,然後留下來,盯到有人每天在用。這種人稀缺、貴,而且愈懂業務就愈難招。所以「FDE 自建 vs 外包」這道題,不該用「自己人比較安心」這種直覺去回答,而該攤開三筆帳來算。

FDE 自建 vs 外包:先算招募這筆帳

自建的第一筆成本,不是薪水,是「找到人之前的時間與失敗率」。

一個合格的 FDE,市場上同時被 OpenAI、Palantir 那一掛公司、以及所有想做 AI 轉型的甲方在搶。在台灣,能同時具備工程實作、資料工程、又願意進客戶現場扛採用的人,我們的經驗是:平均要面 30 到 50 位候選人,才收得到一位真正能上場的。從開缺到報到,六到九個月是常態,而且第一年離職率不低,因為這個角色的挫折感很重——他不是寫完 code 就下班,他要對「有沒有人用」負責。

把這筆帳算完整:獵頭費、你自己主管的面試工時、offer 被拒的沉沒成本、報到後三個月的爬坡期。真正上工前,你已經燒掉半年和一筆六位數起跳的隱形費用。這還沒開始產出任何價值。

Time-to-value:你等得起幾個月?

第二筆帳是「從決定要做,到系統真的在線上被使用」之間的時間差。

自建團隊的 time-to-value,要把招募的六個月疊上團隊磨合、踩你們產業特有的雷、建立第一版可用工作流的時間。從零開始,一年能不能讓第一個 AI Copilot 真正上線且有採用,老實說要看運氣。

外包的價值,幾乎全押在這一格。一支成熟的 FDE 團隊,做過金融的權限控管、醫療的資料去識別化、製造的 MES 對接,他們帶著模式進場。我們自己接手的案子,通常四到八週會有第一個能用的東西上生產環境,不是 Demo,是有人在用的版本。差別在哪?他們不是在你的專案上「學會」怎麼做,而是把別處學會的東西,搬過來適配你。

當你的競爭對手已經在用 AI 壓成本、而你還在面試第七位候選人,這個時間差就是真金白銀。

專案結束後,那筆沒人談的閒置成本

第三筆帳最少人算,卻最容易反咬一口:導入完成後,這支團隊要做什麼?

AI 導入有很明顯的波峰。前六到十二個月工作量爆滿,上線穩定後,維運與迭代所需的人力可能只剩三分之一。自建團隊在波峰時人手不夠,在波谷時你養著一群昂貴的工程師卻沒有夠份量的專案餵他們——這就是閒置成本。而 FDE 這種人,一旦閒下來,通常半年內就會被挖走,你的知識也跟著走。

外包在這一格天然佔優:專案結束,人力歸還,你只在需要迭代時再啟動。取捨是,知識轉移做不好,團隊撤場後你會空。所以我們每個案子都堅持留下交付工作區、把決策脈絡和運維手冊交到客戶內部團隊手上——外包能不能用,關鍵就在收尾,不在開場。

三筆帳一起看

什麼情境該外包?如果你的 AI 需求是「一次性導入 + 低頻迭代」、你等不起一年、或你根本還沒驗證這個 AI 專案值不值得養人,那外包幾乎是唯一理性的選擇。反過來,如果 AI 是你的核心產品、需求高頻且長期,自建才划算——但通常也是先用外包跑通第一個案子、確認方向後,再回頭建隊。

這也是我們做事的方式:先用 FDE 幫你把第一條產線推上線、確認有人真的在用,同時把知識沉澱進你的團隊。等你確定要自建,我們反而樂見你把人接回去——因為到那時,你算的已經不是要不要投入,而是投入哪裡最值得。